#author("2023-02-07T00:02:49+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]
-[[[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アルゴリズムはネステッド・ループ結合のみ
-インデックスが貼られている結合条件キーに対して駆動表ではフルテーブルスキャン、内部表ではインデックスが使われる
-駆動表は行数が少ないものを選ぶ
・駆動表と内部表の結合キーに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
 ;
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS