MySQL 5.6のインストール後にチューニングすべき項目 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
データベースのモダンな使い方を知りたい人のための「Webエンジニアのためのデータベース技術[実践]入門」 - stanaka's blog
「Webエンジニアのためのデータベース技術実践入門」を献本いただきました。著者の松信さんはMySQLの専門家で、これまでも数々の良書を執筆されています。ここ1,2年でデータベースの設計や運用の考え方は大きく進化したのですが、そのあたりが分かり易く解説されており、期待を裏切らない良本でした。 Webエンジニアのための データベース技術[実践]入門 (Software Design plus) 作者: 松信嘉範出版社/メーカー: 技術評論社発売日: 2012/03/09メディア: 単行本（ソフトカバー）購入: 20人 クリック: 480回この商品を含むブログを見る 目次は松信さんのブログエントリにありますが、データベース技術の背景にある考え方から、具体的な概念、MySQLでの実践的な運用、データベースに適したハードウェアの特性まで記述されており、Webアプリケーションエンジニアはこの一冊を読ん
![データベースのモダンな使い方を知りたい人のための「Webエンジニアのためのデータベース技術[実践]入門」 - stanaka's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/469076ea7b5754a845ca1102c949e0c343c3dfc5/height=288;version=1;width=512/http%3A%2F%2Fecx.images-amazon.com%2Fimages%2FI%2F515Ne-1HtqL.jpg)
jdb.js - Indexed Database APIを使いやすくするフレームワーク - IT-Walker on hatena
jdb.jsというフレームワークを作りました。まだ開発に2日もかけてない（ドキュメント書くほうが大変だった(^^; ）ので、荒っぽいところも、機能が不足しているところもありますが、試しに実装してみたらかなり便利なものができたと思っているので、フライング気味に公開します。Indexed Database APIの使いにくさを知っている人なら、結構興味を持っていただけるんじゃないかと。 GitHubのリポジトリはこちらです。 以下、README_ja.mdから引用します。 jdb.jsは、W3C Indexed Database APIをより直感的に扱いやすくすることを目指したライブラリです。 名前の由来は、「IDB」(Indexed DB)をより使いやすく、ということで「JDB」(Jはアルファベット順でIの次の文字です）としました。 Indexed Database APIをそのまま利用する
データベースの内部動作を知る
SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基本的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの？ Part 1：SQL文はどのように実行されるのか SQL実行までの
第3回 テーブル設計のグレーゾーン～毒と薬は紙一重 （1）単一参照テーブル～テーブルにポリモフィズムは必要か | gihyo.jp
SQLアタマアカデミー 第3回テーブル設計のグレーゾーン～毒と薬は紙一重 （1）単一参照テーブル～テーブルにポリモフィズムは必要か はじめに リレーショナルデータベースが関わる案件において、その開発効率と品質を最も大きく決定する要因は、テーブル設計です。テーブル設計は、工程のかなり初期の段階でなされますが、ここがまずいと、その後の開発全体を無駄に不効率で混乱したものにしてしまい、かつ容易に後戻りがきかないという重要なステップです。したがって、「はじめにテーブルありき」は何にもまして重要な合言葉です。 しかし、この工程の難しいところは、往々にして一義的な正解を定められないことです。常に「これが正解」と呼べるような決まったアルゴリズムが存在しないのです。もちろん、数十年にわたる多くの人々の努力によって、いくつかの効果的な設計技法や、原則として踏み外してはいけない最低限のルール（可能な限り正規
DB設計の神ツール「ERMaster」なら、ここまでできる
DB設計の神ツール「ERMaster」なら、ここまでできる：ユカイ、ツーカイ、カイハツ環境！（11）（1/3 ページ） 無料のEclipseプラグイン「ERMaster」とは データベースのテーブル設計を行うときに皆さんは、どのようにしているでしょうか？ いくつかの無料で利用できるツールが提供されているので、筆者はそれらを利用していましたが、最近「ERMaster」と呼ばれるEclipseプラグインの存在を知りました。 ERMasterは、ほかのツールに比べ、直感的で分かりやすいUI（ユーザーインターフェイス）に、カスタマイズ可能な、Excelで出力できるテーブル定義書、辞書機能など痒いところに手が届くERモデリングのツールです。本稿では、このERMasterについてご紹介します。 ERMasterの主な特徴、8つ ERMasterには、主に次のような特徴があります。 【1】直感的で使いや
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リレーショナル・データベースの世界