初心者用MySQLのインデクスの付け方講座。ハンズオン含める

1. DBチューニング
∼MySQL編∼
by poll seed

2. まずは、テーブルを作る
商品テーブル
都道府県
商品
分類

3. インデックスなし
1. 商品全体テーブルを作成
CREATE TABLE `item` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`pref_code` int(11) NOT NULL,
`items_code` int(11) NOT NULL,
`classify_code` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=22 DEFAULT CHARSET=utf8
2. 各々のcodeに対して正規化しテーブルを生成→比較のためキーなどは設けない

4. クエリの実行計画
1. Explainにより実行計画を調べる
explain
SELECT *
FROM item i
inner join pref p on i.pref_code = p.pref_code
WHERE p.pref_code = 1
;
2. 実行計画結果
# id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra
1, SIMPLE, p, const, PRIMARY, PRIMARY, 4, const, 1,
1, SIMPLE, i, ALL, , , , , 21, Using where
※「i」テーブルのtypeが「ALL」となっている

5. ALLとは
そもそもtypeとはなんだろうか
結論から言えば、「結合型」
さらに言えば、ALLと言うのは「フルテーブルス
キャン」のALLである。ただの爆遅結合というこ
と
要は、ALLなんて出してはいけない

6. 改善しよう
typeで爆速なのがsystem, constである。
systemというのは1レコードのみなので「const」,
次に早い「eq_ref」を目指すというのがエンジニ
アの必須事項

7. 手を加える1
1. indexの追加
ALTER TABLE `test`.`item`
ADD INDEX `idx_item1` USING BTREE (`pref_code` ASC);
2. 実行計画
# id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra
1, SIMPLE, p, const, PRIMARY, PRIMARY, 4, const, 1,
1, SIMPLE, i, ALL, idx_item1, , , , 21, Using where
※idx_item1がキーの候補として出てきた。ただし、まだALLである。

8. pref_codeにインデックスをつ
けることについて考える1
通常、B木インデックスをつける時は、カーディナ
リティの高い列を選ぶことが前提としてある
なぜならば、B木をより平坦にする必要があるから
である。平坦というのはリーフが多い状態
具体的にはレコード全体の5%以下に抑えることがで
きる場合、インデックスを張るのは有効と言われる

9. pref_codeにインデックスをつ
けることについて考える2
pref_codeというのは都道府県である。よって、47
件のデータが存在する。1件につき全体のデータを
大体2.1%程度に絞る事が可能
先の前提を元にすれば充分インデックスを張るの
が有効だと言えよう

10. 手を加える2
1. 外部キーを付ける
ALTER TABLE `test`.`item`
ADD CONSTRAINT `fk_item1`
FOREIGN KEY (`pref_code`)
REFERENCES `test`.`pref` (`pref_code`)
ON DELETE NO ACTION
ON UPDATE NO ACTION;
2. 実行計画
# id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra
1, SIMPLE, p, const, PRIMARY, PRIMARY, 4, const, 1,
1, SIMPLE, i, ALL, idx_item1, , , , 21, Using where

11. 変わっていない？

12. もう一度先ほどの話を見て
みよう

13. pref_codeにインデックスをつ
けることについて考える1
通常、B木インデックスをつける時は、カーディナ
リティの高い列を選ぶことが前提としてある
なぜならば、B木をより平坦にする必要があるから
である。平坦というのはリーフが多い状態
具体的にはレコード全体の5%以下に抑えることがで
きる場合、インデックスを張るのは有効と言われる

14. どういうことか
言うなれば、概算としてレコードを2.1%におさえ
れるという想定で先のインデックスを張り、外部
キーまで加えたのにALLのまま
現場では得てしてこういうことが起こる。
それでは、このカラクリを紐解いてみよう。

15. 件数ベースで確認
1. 件数を見てみよう
SELECT
COUNT(*), COUNT(IF(pref_code = 1, 1, NULL))
FROM
test.item;
2. 件数の結果
# count(*), count(if(pref_code=1,1,null))
21, 16
※全体の76%以上がpref_code=1となっている。
想定では高いと思っていたが、データ的にはカーディナリティが低いのである。

16. データ確認1
select * from item where pref_code <> 1;
# id, pref_code, items_code, classify_code
1, 3, 1, 1
18, 2, 1, 1
19, 2, 2, 1
20, 2, 3, 1
21, 2, 4, 1
※3のカーディナリティは4.7%と高いため、こいつで条件を見てみる

17. データ確認2
1. 実行計画をpref_code=3で見てみる
explain
SELECT *
FROM item i
inner join pref p on i.pref_code = p.pref_code where p.pref_code = 3;
2. 結果
# id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra
1, SIMPLE, p, const, PRIMARY, PRIMARY, 4, const, 1,
1, SIMPLE, i, ref, idx_item1, idx_item1, 4, const, 1,
※問題なくインデックスが使われている

18. まとめ
B木インデックスをつける時は、カーディナリ
ティの高い列を選ぶ
レコード全体の5%以下に抑えることができる場
合、インデックスを張るのは有効
ただし、データ件数によっては、インデックスが
有効でない場合も実際の現場では多い

19. 発展として
複合インデックスについてはどうか？
カーディナリティの高い順に貼っていくのが妥
当と思われる
現場でデータ件数を元に決めるのがよい
検索するときも、インデックスが効くように
Where文で検索する順序に注意

20. 余力があればハンズオン
以下のURLにアクセス
https://raw.githubusercontent.com/pollseed/
linux_setup/master/src/hackathon/db/
tuning_before.sql
Q1∼Q3をできるところまで

21. 資料
以下のドキュメントも参考にして下さい
https://raw.githubusercontent.com/pollseed/
linux_setup/master/src/hackathon/db/doc.md

22. Fin