![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2023-02-07T06:32:18+00:00","default:admin","admin") #author("2023-02-07T06:36:10+00:00","default:admin","admin") -[[MySQL データベースの負荷対策/パフォーマンスチューニング備忘録 インデックスの基礎〜実践:https://qiita.com/marnie_ms4/items/576055abc355184c51a1]] -[[Performance Insights を使用して Amazon Aurora の MySQL のワークロードを分析する:https://aws.amazon.com/jp/blogs/news/analyze-amazon-aurora-mysql-workloads-with-performance-insights/]] *クエリ [#kdda7ed6] -[[すぐに実践できる！ SQLパフォーマンスチューニング5選:https://www.w2solution.co.jp/tech/2021/11/26/eg_ti_ti_sql5/]] **スロークエリログ [#sc834482] -[[スロークエリログに出力される項目とlog_slow_extra:https://gihyo.jp/dev/serial/01/mysql-road-construction-news/0154]] **EXPLAIN [#y2a69a72] -[[EXPLAIN 出力フォーマット:https://dev.mysql.com/doc/refman/5.6/ja/explain-output.html]] -[[条件フィルタ:https://docs.oracle.com/cd/E17952_01/mysql-8.0-ja/condition-filtering.html]] -[[あなたの知らない(かもしれない)EXPLAIN文のこんな使い方:https://rkajiyama.hatenablog.com/entry/20131218/p1]] -[[MySQLのEXPLAINが直感とは異なっていた事例:https://blog.utgw.net/entry/2020/10/23/205131]] -[[MySQLのEXPLAIN解説:https://qiita.com/chii-08/items/e6a3ff51129ef1167ab6]] -[[最低限押さえておきたい EXPLAIN の見かた:https://qiita.com/aidy91614/items/f17ab862986e9e5cdea6]] -[[MySQL の EXPLAIN を試してみる:https://qiita.com/Ping/items/0521468ac9a64a03cf66]] -[[MySQLのEXPLAIN（実行プラン）まとめ:https://qiita.com/tsurumiii/items/0b70f1a1ee0499be2002]] -[[MySQLのEXPLAINを徹底解説!!:http://nippondanji.blogspot.com/2009/03/mysqlexplain.html]] **JOIN [#ac0f1e85] -[[LEFT JOIN および RIGHT JOIN の最適化:https://dev.mysql.com/doc/refman/5.6/ja/left-join-optimization.html]] 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との違い:https://oshiete.goo.ne.jp/qa/8090979.html]] -[[[SQL]JOINの3種類のアルゴリズムについて:https://zenn.dev/captain_blue/articles/three-types-of-join-algorithms]] -[[【SQL】JOIN(Nested loop join)の仕組みを理解し、インデックスで高速化する:https://nishinatoshiharu.com/overview-nested-loopjoin/]] -[[MySQLで業務アプリを作る際に気を付けたいJOINの話:https://qiita.com/Flipper0407/items/c92a00627df9230f8aa2]] -[[SQL Joinサンプル集 Joinで遅いSQLの原因を調べる方法:https://style.potepan.com/articles/14926.html#SQL]] -[[MySQLにおけるJOINのチューニングの定石:https://enterprisezine.jp/article/detail/3520]] -MySQLがサポートするJOINアルゴリズムはネステッド・ループ結合のみ -インデックスが貼られている結合条件キーに対して駆動表ではフルテーブルスキャン、内部表ではインデックスが使われる -駆動表は行数が少ないものを選ぶ ・駆動表と内部表の結合キーにindexが適用されるようにする -JOINのパフォーマンス劣化においては、外部結合が問題となることが多い -外部結合ではLEFT JOINであれば左辺のテーブルが駆動表に固定されるため、駆動表に件数が多く増える速度も早いテーブルを指定してしまうと、前述のt1 × t2の処理コストが時間とともに増えることになる -ただそれでも、結合がひとつで、内部表の参照にインデックスが使われている限りは、問題が表面化しにくい -多段結合でインデックスも使われない場合は、LEFT JOINでは結合ごとの走査行数が絞り込まれないため、非常にコストがかかるようになる *テーブル状況確認 [#p0db85cc] -[[MySQL でテーブルやカラムの情報を確認する方法まとめ:https://yulii.github.io/mysql-schema-information-20150901.html]] -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」の付け方:https://qiita.com/qyuser/items/2c535888b6a899685821]] --[[MySQL で MUL と PRI と UNI の比較:https://www.delftstack.com/ja/howto/mysql/mul-vs-pri-vs-uni-in-mysql/]] --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 ;
