もしOracleDBAがMySQLを管理することになったときの注意点など
1 like1,428 views
もしOracleDBAがMySQL:dolphin:を管理することになったときの注意点など
もしOracleDBAがMySQLを管理することになったときの注意点など
- 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 テーブルなどと呼びます。 “ “
- 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
- 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カラムにインデ ックスがない場合、フルスキャンになる。そのときにすべての行でロッ クがとられる
- 17. ギャップロックとネクストキーロック トランザクション分離レベル Oracle - READ_COMMITED (Default) MySQL - REPEATABLE_READ (Default) MySQLのトランザクション分離レベルを READ_COMMITED に変更すると、Oracleと同等の行ロ ックになる。ギャップロックとネクストキーロッ クが無効化される。 Oracle開発者がMySQLを使用するときは READ_COMMITED に変更すれば、これらのロックを気 にする必要はない
- 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でもロック取得
- 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+) ロックを取得されているテーブルを表示
- 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脳で考え ると危険