漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
MySQL Clusterが苦手とするJOINを如何にして克服するべきか。
シェアードナッシング型の負荷分散機能を持ち、なおかつ同期レプリケーションによるHA機能まで備えたMySQL Cluster最大の弱点といえば、JOINの遅さであろう。MySQL ClusterのJOINは偽りなく遅い。JOINを多用するアプリケーションでMySQL Clusterを利用するのはある意味マゾヒスティックな行為であると言えよう。何故MySQL ClusterはJOINが遅いのか？それはMySQL Clusterが分散データベースだからである。 ご存じの通り、MySQLにおけるJOINのアルゴリズムにはNested Loopしかない。他のストレージエンジンを利用していればそれでも十分実用に耐えうるぐらい高速なのだが、MySQL Clusterの場合はそうはいかない。JOINでは自ずとストレージエンジンからデータをフェッチする回数が増えるが、MySQL Clusterの場合レコード
カカクコム社内勉強会に参加 - mir the developer
id:kiskeさんにお誘いいただいて先週金曜日にカカクコムさんの社内勉強会でお話させていただきました。貴重な機会をいただきありがとうございました。 自由に話してOKですよとのことだったので、何にしようかなと少し考えた結果、こんなスライドができあがりました。 MySQLのパフォーマンスの話View more presentations from ikdttr. MySQLも今となってはかなり広く使われていて、パラメータチューニングとかも一通りのことは皆さんご存知だろうと思ったので「チューニングをする際にソースを読んで調べたいと思ったらどうしたらいいか」といったようなテーマに対する答えの一例見たいな感じの内容になりました。 普段使っている/参照しているサーバ変数やステータス変数がどのように実装されていて、それらをソース上で追いかけるにはどうしたらいいか、みたいな感じですね。 勉強会ではgdb
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
目覚ましい進化を見せるストレージエンジン - PBXT改善の軌跡
PBXTというストレージエンジンがある。これは、PrimeBase社によるストレージエンジンで、トランザクションをサポートした本格的なものである。（つまり、InnoDBやFalconの代替として使うことを目指したエンジンなのである。）PBXTは次のページからダウンロード可能だ。 http://www.primebase.org/ 上記のページにも書いてあるが、PBXTの特徴は次の通り。 MVCC（Multi Version Concurrency Control）トランザクションのサポートACID準拠行レベルのロックデッドロック検知外部キーのサポートWrite Once（追記型アーキテクチャ）BLOBストリーミング 最後の2つ以外はInnoDBと同じである。Write Onceとは追記型のアーキテクチャで、InnoDBのように独立したログが存在しないという意味である。（PostgreSQL
MySQL Conference & Expo 2007 - とあるはてな社員の日記
一昨日から今日まで3日間の日程で開催されていた、MySQL Conference & Expo 2007に行ってきました。日帰り圏内どころか、自転車圏内で、こういうカンファレンスがあるのは、素晴しいです。 詳細は、随時アップされるであろうプレゼン資料と、Planet MySQLに大量の報告があります(全部英語ですけど)。 個人的に注目していたのは、Digg.com、Flickr.comとYoutube.comのDB周りアーキテクチャのセッションでした。あとは、http://www.mysqlperformaceblog.com/の人のセッションは、細かいTipsが多く、具体的にだいぶ役に立ちそうです。 というわけで、簡単に注目したセッションの内容を紹介してみます。ちなみに、内容の正確さは無保証です:P 気が向けば、もっといろいろ考察してみるかもしれません。 Technology at Di
mixi Engineers’ Blog » Introducing the Drizzle Project
ここしばらく、水面下でBrian Akerを代表とするMySQL/SUNのエンジニアたちや、業界のオープンソースハッカーたちとMySQLをスリムダウンさせたマイクロカーネルRDBMSを開発していたのですが、本日アナウンスされたので、日本語でご紹介させていただきたいと思います。 Drizzleとは？ Drizzleとは必要のないものは一切存在しない、最低限でパフォーマンス重視な「MySQLよりシンプルで、軽く、安定して、高速な」 MySQLのforkです。マイクロカーネルアーキテクチャを採用したので、必要のないものは後付けできる構成です。こういった目標もあり、現在、Drizzleの開発チームはMySQLをドラスティックにリファクタリングしています。 コミュニティベースのプロジェクト Drizzleで大事な事は、Drizzleはコミュニティベースのプロジェクトであるという事です。Montyのブ
ちょっと上級チューニング - スマートスタイル
動作状況の検証方法 時間のかかるSQLコマンドを特定したい場合、どうすればいいですか？ （MySQL4.0、4.1、5.0共通） my.cnfファイルに「log_slow_queries=ログファイル名」と記述します。デフォルトでは、実行に10秒以上かかった操作がこのログファイルに記録されます。実行時間を変更したい場合は、my.cnfファイルに「long_query_time=秒数」を追加すれば、記述した秒数を超えた操作がログファイルに記録されます。 実行時間のかかるクエリを改善するためにはどうすればいいですか？ （MySQL4.0、4.1、5.0共通） EXPLAINコマンドを使用します。Keyフィールドにコマンド実行時に使用されるインデックス、rowsフィールドにコマンド実行時に読み取ったデータ数が出力されます。作成インデックスがkeyフィールドに表示され、インデックスを使用しない
MySQLのチューニング [データベース] All About
MySQLのチューニング MySQLはスケーラブルなアルゴリズムを使用し、通常の実行時のメモリ消費を小さくしていますが、メモリを多く割り当てると、パフォーマンスが向上します。 mysqld サーバで使用されるデフォルトのバッファサイズは次のコマンドで確認できます。 innodb_force_recovery 0 interactive_timeout 28800 join_buffer_size 131072 key_buffer_size 8388572 long_query_time 10 lower_case_table_names TRUE max_allowed_packet 1048576 max_binlog_cache_size 4294967295 max_binlog_size 1073741824 max_connections 100 max_connect_err
![MySQLのチューニング [データベース] All About](https://cdn-ak-scissors.b.st-hatena.com/image/square/8f530daf3cb408d6b6a0ba6f38ed7ccece36cffc/height=288;version=1;width=512/https%3A%2F%2Fimg.aacdn.jp%2Faa%2Fcommon%2Fogp300_300.png)
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
[ThinkIT] はじめてのMySQLチューニング 第3回：max_connectionsとthread_cacheのチューニングを行う (1/3)