• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• MySQL/パフォーマンスチューニング へ行く。
  • 1 (2010-12-07 (火) 02:37:13)
  • 2 (2010-12-07 (火) 06:25:20)
  • 3 (2010-12-07 (火) 14:49:16)
  • 4 (2010-12-08 (水) 10:18:30)
  • 5 (2010-12-09 (木) 07:07:30)
  • 6 (2010-12-09 (木) 11:24:25)
  • 7 (2010-12-10 (金) 00:56:12)
  • 8 (2010-12-10 (金) 03:49:12)
  • 9 (2010-12-10 (金) 07:08:33)
  • 10 (2011-07-06 (水) 08:36:01)
  • 11 (2011-07-06 (水) 11:04:23)
  • 12 (2011-07-07 (木) 02:12:08)
  • 13 (2011-07-08 (金) 05:19:12)
  • 14 (2012-01-10 (火) 14:02:50)

参考†

• EXPLAIN
  • http://nippondanji.blogspot.com/2009/03/mysqlexplain.html
• インデックス
  • http://dev.mysql.com/doc/refman/4.1/ja/mysql-indexes.html
    • 左端プリフィックス
  • http://hamamuratakuo.blog61.fc2.com/blog-entry-407.html
    • インデックスの長さ
  • http://dev.mysql.com/doc/refman/4.1/ja/create-index.html
    • インデックスの長さを指定する
  • http://www.mysqlperformanceblog.com/2006/08/10/using-union-to-implement-loose-index-scan-to-mysql/
    • INをUNION ALLで代替
  • http://ameblo.jp/udzura/entry-10122301087.html
    • UNION ALLしてCOUNTするときの注意
• 全文検索
  • http://www.tatamilab.jp/rnd/archives/000389.html
    • マルチバイト文字対応（4.1.1以降）
• JOIN+ソート
  • http://nippondanji.blogspot.com/2009/03/using-filesort.html
  • http://dev.mysql.com/doc/refman/5.1/ja/order-by-optimization.html
    • ORDER BYについてMySQL公式
• カウント
  • http://dev.mysql.com/doc/refman/5.1/ja/information-functions.html
    • FOUND_ROWS()
  • http://nippondanji.blogspot.com/2010/03/innodbcount.html
    • Covering Index
• なんかいろいろ
  • http://pagerank.cocolog-nifty.com/blog/mysql/index.html
  • http://txqz.net/blog/2006/12/13/0943
  • http://hain.jp/index.php/tech-j/2006/12/18/p106

まとめ†

• IN句でインデックスを使わないのは複合インデックスのうち先頭のみ
• 複合インデックスの順とWHERE句で出現する順は同じでなくてよい
• ファイルソートは一番まずい
• 時間はchar型で保存するのがいい

MySQLのコメント†

MySQL では利用可能な場合でもインデックスが使用されない場合が
あることに注意してください。この一例として、インデックスの使
用によって、MySQL がテーブルの 30% を超えるレコードにアクセス
する必要が生じる場合が挙げられます（この場合は、必要なシーク
が大幅に減少するため、テーブルスキャンのほうが高速になる可能
性が高くなります）。 ただしこのクエリに、レコードの一部のみを
取り出す LIMITが使用されている場合、結果で返される少数のレコー
ドを迅速に検索できるため、MySQL はインデックスを使用します。

• WHERE句で絞り込んだ結果がテーブルの30%を超えるとサーチしてフェッチするコストのが大きい