もしOracleDBAがMySQL:dolphin:を管理することになったときの注意点など

1. もしOracleDBAがMySQL を管理
することになったときの注意点など
2019/12/04
JPOUG in 15 minutes #9
Kentaro Kitagawa(@keny_lala)

2. 自己紹介
名前: Kentaro Kitagawa
仕事: とある会社de DBA
担当: MySQL,Oracle,Redis
twitter: @keny_lala

3. １年ほど前

4. 前提
資料の中のMySQLはInnoDB ストレージエンジン
とします
ストレージエンジン
出典: https://dev.mysql.com/doc/refman/5.6/ja/glossary.html
MySQL データベースのコンポーネントの1 つ。データの格納、更
新、および照会という低レベル作業を実行します。MySQL 5.5 以降で
は、InnoDB が新しいテーブルのデフォルトストレージエンジンであ
り、MyISAM の代替となるものです。メモリー使用とディスク使用、
読み取り速度と書き込み速度、速度と堅牢性など、異なる要因間トレ
ードオフのために異なるストレージエンジンが設計されています。各
ストレージエンジンが特定のテーブルを管理するので、InnoDB テー
ブル、MyISAM テーブルなどと呼びます。
“
“

5. アジェンダ
フルスキャンの注意点
ロックの注意点
メタデータロック
ReadCommitedでの行ロック

6. フルスキャンでの注意点

7. Oracleのフルスキャン
TABLE ACCESS FULL
INDEX FAST FULL SCAN
マルチブロックリード(db_ le_multiblock_read_count)
ダイレクトパスリード
Parallel Query(EE)

8. MySQLのフルスキャン
Type: ALL ・・テーブルフルスキャン
Type: INDEX ・・インデックスフルスキャン
シングルページリード

9. JOINアルゴリズム
Oracle
Nested Loop Join
Hash Join
Merge Join
MySQL
Nested Loop Join

10. フルスキャンのJOIN
Oracle
HASH JOINでマルチブロックリード

11. MySQL
Nested Loop JOINでシングルページリード

12. フルスキャンのJOIN
Oracleはフルスキャンを最適化する機能がある
OracleとMySQLでは、速度にかなりの違いが出る
部分
MySQLのクエリチューニングするときは、Nested
Loop Joinしかないこととシングルページリードし
かないことを意識して、フェッチする行やページ
へのアクセス量を減らすこと。インデックス設計
も必須。
(そもそもフルスキャンはだめ絶対。)

13. MySQL 8.0+
Hash Join (MySQL8.0.18+)
Indexのないカラムの等価結合に動作する
InnoDB table Non locking parallel reads
CHECK TABLE or SELECT COUNT(*) FROM tbl
がパラレルで実行可能
@atsuizoさんのブログ
MySQL 8.0.14でSELECT COUNT(*)が加速する！-
「innodb_parallel_read_threads」検証その１

14. ロックでの注意点

15. MySQLのロックといえば、、
クラスタインデックス(Oracleでいう索引構成表)で管理されていて、走
査したレコード全てにロックをとる。
MySQLはレコードロックだが、それ以外に特殊なロックがある。
ギャップロック・・インデックスレコード間にあるギャップのロック
ネクストキーロック・・インデックスレコードに対するレコードロック
と、そのインデックスレコードの前にあるギャップに対するギャップロ
ックとを組み合わせたもの
たとえば、SELECT * FROM t0 WHERE col=2 FOR UPDATE; でcolカラムにインデ
ックスがない場合、フルスキャンになる。そのときにすべての行でロッ
クがとられる

16. 今回はこの話ではないので、詳しくは@sh2さんと
@yyamasaki1さんの資料をご確認ください。
https://sh2.hatenablog.jp/entry/20140914
https://speakerdeck.com/yoshiakiyamasaki/lt-
mysqlfalsegiyatupurotukutonekusutokirotukunituite

17. ギャップロックとネクストキーロック
トランザクション分離レベル
Oracle - READ_COMMITED (Default)
MySQL - REPEATABLE_READ (Default)
MySQLのトランザクション分離レベルを
READ_COMMITED に変更すると、Oracleと同等の行ロ
ックになる。ギャップロックとネクストキーロッ
クが無効化される。
Oracle開発者がMySQLを使用するときは
READ_COMMITED に変更すれば、これらのロックを気
にする必要はない

18. しかし！！
READ_COMMITED にしても、OracleDBAであれば注意
しなくてはいけないロックがある。

19. メタデータロック
OracleでいうTMロックに似たもの
別のトランザクションによって同時に使用されているテーブルでの
DDL 操作を防止するタイプのロック。
“
“
オンライン操作への拡張機能は(特にMySQL 5.6 以降)、メタデータ
ロックの量を減らすことに注力しています。その目標は、ほかのトラ
ンザクションによってテーブルに照会や更新などが行われている間
に、テーブル構造を変更しないDDL 操作(InnoDB テーブルに対する
CREATE INDEX やDROP INDEX など) を進行できるようにすること
です。
出典: https://dev.mysql.com/doc/refman/5.6/ja/glossary.html
“
“

20. Oracle
Tx1 Tx2
Transaction Start.
INSERT t0;
TRUNCATE t0; <- Waiting
Commit;
Done
Tx2のTruncateは待たされる
(DDL_LOCK_TIMEOUT)。Tx1のcommit後、
Truncateが実行される。

21. Oracle
Tx1 Tx2
Transaction Start.
SELECT t0;
TRUNCATE t0; <- NoWait
Commit;
Tx2のTruncateは待たされない。

22. MySQL
Tx1 Tx2
BEGIN;
INSERT t0;
TRUNCATE t0; <- Waiting
Commit;
Done
Tx2のTruncateは待たされる。Tx1のcommit後実行
される。

23. MySQL
Tx1 Tx2
BEGIN;
SELECT t0;
TRUNCATE t0; <- Waiting
Commit;
Done
Tx2のTruncateは待たされる。Tx1のcommit後実行
される。
Non BlockingなSELECTでもロック取得

24. メタデータロック
トランザクション中にSELECTしたテーブル(Non
Blocking Read)は、トランザクション中は共有メタ
データロックを取得する。
トランザクション終了後、その共有メタデータロ
ックは開放される
共有メタデータロックは競合しないが、DDLなど
では排他メタデータロックを取得するために待機
する。
よって、ロングトランザクションがある場合の
DDLは注意するべき。

25. さらに注意してほしいこと。。

26. MySQL
Tx1 Tx2 Tx3 Tx4
BEGIN; - BEGIN; -
SELECT t0; - - -
- TRUNCATE t0;-Waiting - -
- - SELECT t0;-Waiting -
- - BEGIN;
- - SELECT t0;-Waiting
排他メタデータロック取得するために待機した以
降のSELECTがすべて待機される(共有メタデータロ
ックが取得できないため)

27. (；´艸｀)ぁぁぁ

28. ロックの待機時間はlock_wait_timeoutオプション
で管理。
デフォルト31536000秒(１年)
セッション単位で小さな値にして、DDLするこ
とを推奨。
今回はTRUNCATEでしたが、複数テーブルに跨る
FunctionやTriggerなど作成するときはより注意。
OracleはデフォルトでNOWAIT句が裏でつくよう
なので、ロック取得できないと即時エラー
SQL> TRUNCATE TABLE t0;
TRUNCATE TABLE t0
*
行1でエラーが発生しました。:
ORA-00054: リソース・ビジー。NOWAITが指定されているか、タイムアウトしました

29. メタデータロックを確認する方法
show processlistのState
ロック待ちしているスレッドを確認できる
mysql> show processlist;
(中略)
+-----+---------+--------+----------------------------------+--------------------+
| Id | Command | Time | State | Info |
+-----+---------+--------+----------------------------------+--------------------+
| 1962| Query | 5 | Waiting for table metadata lock | TRUNCATE TABLE t0 |
Performance Schema のmetadata_locksテーブル
(MySQL5.7+)
ロックを取得されているテーブルを表示

30. Read Commitedの行ロックの注意点

31. tx_isolation=READ-COMMITTED だとGap Lock
とNext Key Lockは無効化
DELETE WHERE col=1 → Type: ALL だと、col=1 だけ
をロックする
しかし、MySQLはステートメント実行時に全行ロ
ック（走査した行をロック）して、最後にa=1に一
致しない行のロックを開放する動きとなる
Oracleはステートメント実行中もa=1に一致した行
のみをロックする
よって、REPEATABLE READと同様にINDEXを貼
のが得策である

32. Oracle（フルスキャンのDELETE）
Tx1 Tx2
Transaction Start. Transaction Start.
DELETE t0 WHERE col=1;
DELETE t0 WHERE col=2; <- NoWait
MySQL（フルスキャンのDELETE）
Tx1 Tx2
Transaction Start. Transaction Start.
DELETE t0 WHERE col=1;
DELETE t0 WHERE col=2; <- Waiting

33. まとめ
MySQLはフルスキャンは遅い。
シングルページリードしかないことを意識して、必ずインデ
ックスをつかって、フェッチする行やページへのアクセス量
を減らすこと。
Nested Loop Joinしかないことを前提にインデックス設計す
る。
MySQL 8.0+ は速くなりつつある
メタデータロック
オンラインで日時TRUNCATEする処理がある時、ロングト
ランザクションと重ならないことを注意。スレッドが大幅に
詰まる可能性がある。
tx_isolation=ReadCommitedでも適切なインデックスが必要
Oracle的なロックのとり方ではないので、Oracle脳で考え
ると危険