MySQL/チューニング

• MySQL データベースの負荷対策/パフォーマンスチューニング備忘録 インデックスの基礎〜実践

• Performance Insights を使用して Amazon Aurora の MySQL のワークロードを分析する

クエリ †

• すぐに実践できる！　SQLパフォーマンスチューニング5選

スロークエリログ †

• スロークエリログに出力される項目とlog_slow_extra

EXPLAIN †

• EXPLAIN 出力フォーマット
• 条件フィルタ

• あなたの知らない(かもしれない)EXPLAIN文のこんな使い方
• MySQLのEXPLAINが直感とは異なっていた事例

• MySQLのEXPLAIN解説
• 最低限押さえておきたい EXPLAIN の見かた
• MySQL の EXPLAIN を試してみる
• MySQLのEXPLAIN（実行プラン）まとめ
• MySQLのEXPLAINを徹底解説!!

JOIN †

• LEFT JOIN および RIGHT JOIN の最適化

  A LEFT JOIN B join_condition

  • テーブル B は、テーブル A と A が依存するすべてのテーブルに依存して設定されます。
  • テーブル A は、LEFT JOIN 条件で使用されるすべてのテーブル (B を除く) に依存して設定されます。
  • LEFT JOIN 条件（join_condition）は、テーブル B からの行の取得方法を決定するために使用されます。(言い換えると、WHERE 句内のすべての条件が使用されません)。
  • テーブルは常にそれが依存するすべてのテーブルのあとに読み取られることを除き、すべての標準の結合最適化が実行されます。循環依存関係がある場合、MySQL はエラーを発行します。
  • すべての標準 WHERE 最適化が実行されます。
  • A に WHERE 句に一致する行があるが、B に ON 条件に一致する行がない場合、すべてのカラムが NULL に設定された追加の B 行が生成されます。
  • LEFT JOIN を使用して、一部のテーブルに存在しない行を検索し、WHERE 部分の col_name IS NULL のテストを実行した場合 (ここで col_name は NOT NULL と宣言されているカラム)、MySQL は LEFT JOIN 条件に一致する 1 つの行が見つかったあとに、それ以上の行 (の特定のキーの組み合わせ) の検索を停止します。

• WHERE句で結合。INNER JOINとの違い

• [SQL]JOINの3種類のアルゴリズムについて
• 【SQL】JOIN(Nested loop join)の仕組みを理解し、インデックスで高速化する

• MySQLで業務アプリを作る際に気を付けたいJOINの話
• SQL Joinサンプル集　Joinで遅いSQLの原因を調べる方法
• MySQLにおけるJOINのチューニングの定石

• MySQLがサポートするJOINアルゴリズムはネステッド・ループ結合のみ
• インデックスが貼られている結合条件キーに対して駆動表ではフルテーブルスキャン、内部表ではインデックスが使われる
• 駆動表は行数が少ないものを選ぶ ・駆動表と内部表の結合キーにindexが適用されるようにする

• JOINのパフォーマンス劣化においては、外部結合が問題となることが多い
• 外部結合ではLEFT JOINであれば左辺のテーブルが駆動表に固定されるため、駆動表に件数が多く増える速度も早いテーブルを指定してしまうと、前述のt1 × t2の処理コストが時間とともに増えることになる
• ただそれでも、結合がひとつで、内部表の参照にインデックスが使われている限りは、問題が表面化しにくい
• 多段結合でインデックスも使われない場合は、LEFT JOINでは結合ごとの走査行数が絞り込まれないため、非常にコストがかかるようになる

テーブル状況確認 †

• MySQL でテーブルやカラムの情報を確認する方法まとめ

• DBのテーブルのカラム情報を取得

  SELECT
   TABLE_NAME
  , COLUMN_NAME
  , COLUMN_TYPE
  , IS_NULLABLE
  , COLUMN_KEY
  , COLUMN_DEFAULT
  , EXTRA
  FROM
    INFORMATION_SCHEMA.COLUMNS
  WHERE
    TABLE_SCHEMA = 'DB_NAME'
  ;

• 【MySQL】Keyのところに出る「MUL」の付け方
• MySQL で MUL と PRI と UNI の比較

• PRI はプライマリキーを意味し、テーブル内のレコードの一意性を強制します。NULL 値は許可されません。単一の列または複数の列を主キーとして使用できます。
• UNI キーは一意キーを表し、主キーのようにテーブル（関係）内の行（レコード）の一意性を強制し、NULL 値を持ちます。1つまたは複数の列を使用して、一意のキーを作成できます。
• MUL キーはそれらのいずれでもありません。つまり、MUL キーは主キーでも一意キーでもないインデックスです。NULL 値を許可し、その名前 MUL と同じ値が複数回出現することを許可します。

• テーブル単位のデータサイズを確認

  SELECT
    TABLE_NAME
  , ENGINE
  , TABLE_ROWS               -- レコード数
  , AVG_ROW_LENGTH    -- 平均レコード容量
  , FLOOR((DATA_LENGTH + INDEX_LENGTH) / 1024) AS SIZE    -- 合計容量
  , FLOOR((DATA_LENGTH) / 1024) AS DATA_SIZE    -- データ容量
  , FLOOR((INDEX_LENGTH) / 1024) AS INDEX_SIZE    -- インデックス容量
  FROM
    INFORMATION_SCHEMA.TABLES
  WHERE
    TABLE_SCHEMA = DATABASE()
  ORDER BY
    (DATA_LENGTH + INDEX_LENGTH) DESC
  ;