1. MySQL 5.6 新機能解説
＠ db tech showcase 2012
奥野 幹也
@nippondanji
mikiya (dot) okuno (at) gmail (dot) com

2. 免責事項
● 本プレゼンテーションにおいて示されている見解は、私自身
の見解であって、オラクル・コーポレーションの見解を必ず
しも反映したものではありません。ご了承ください。

3. 自己紹介
● MySQL サポートエンジニア
– 2000 年にサン・マイクロシステムズ入社
● 主にハードウェアのサポートを担当
– 2007 年に MySQL KK へ転職
● 気付くとまたサン・マイクロシステムズに・・・
– 現在は日本オラクルに在席。
– サポート一筋 12 年
● 日々のしごと
– MySQL トラブルシューティング全般
– Q&A 回答
など
● ブログ
– 漢のコンピュータ道
– http://nippondanji.blogspot.com/

4. MySQL 5.6
新機能ダイジェスト

5. MySQL 5.6 リリース候補版登場！
● MySQL Connect 2012 において MySQL 5.6 リリース候
補版（ RC ＝ Release Candidate ）が発表された。
– MySQL Connect は Oracle OpenWorld と並んで US で
開催されたイベント
● リリース候補版≒ Feature Fix!!
– 約 200 の Worklog に対応
– 機能は開発版（ DRM ＝ Development Milestone
Release ）で徐々に追加するという開発モデル
● MySQL 5.5GA （２０１０年 12 月）以来のメジャーアップ
デート
– マイナーバージョンではありません。
– 正式版（ GA ＝ General Availability ）までしばらくお待ち
を！！

6. レプリケーション
● GTID – Global Transaction ID
– スレーブの自動的な昇格が可能に！！
● クラッシュセーフなスレーブ
● 遅延レプリケーション
● mysqlbinlog コマンドによるバイナリログのバックアップ
● スレーブが使用する NIC の指定
● マルチスレッドスレーブ
– スレーブ SQL スレッドが複数のスレッドで実行可能に！！
– DB 単位での並列処理

7. InnoDB
● インデックスの追加と削除がオンラインで可能に！！
● FULLTEXT インデックスのサポート
● .ibd ファイル（テーブル単位のデータファイル）のエクス
ポートとインポート
– ファイルのコピー＋ α の操作他のサーバーへ移行可能！！
● ページサイズの指定（ 16KB→4KB/8KB/16KB ）
● インデックス統計情報の改善
● START TRANSACTION READ ONLY
● ログサイズの上限が増加（ 4GB→512GB ）
● デッドロック検出機能の改善
● CPU スケーラビリティの向上
● バッファプールの内容を保存、再起動時に暖機運転
● memcached インターフェイス

8. オプティマイザ
● サブクエリの高速化
– semi-join 最適化
– FROM 句のサブクエリの評価遅延
● EXPLAIN の改善
– SELECT 以外の DML へ対応
● 各種アルゴリズムの改善
– ORDER BY ... LIMIT の効率化
– Batched Key Access Join
– Index Condition Pushdown
– Multi Range Read
● オプティマイザトレース

9. パーティショニング
● パーティションをテーブル同士で交換可能に
● パーティション数の上限増加（ 1024→8192 ）
● 明示的なパーティションの指定
● テーブルロックの改善
– テーブルロックの対象がテーブル全体からパーティション
単位に

10. その他
● セキュリティ関係
● ジャイアントロックの解消
● ホストキャッシュの参照
● OpenGIS 対応
● 小数点以下の秒への対応
● ストアドルーチンにおけるエラーハンドリングの改善
– Diagnostic Area
参考：開発スピードアクセル全開ぶっちぎり！日本よ、これが MySQL 5.6 だッ！！
http://nippondanji.blogspot.com/2012/10/mysql-56.html

11. 時間の都合上
すべてをお見せすることが
できません。

12. あまりにもたくさん
目覚しい新機能が
あるからです！

13. レプリケーション

14. MySQL のレプリケーション
アプリケーション
1. COMMIT 4-1. send_ok
接続 スレーブ接続 I/O SQL
スレッド 2.
スレッド スレッド スレッド
バ
イ
更 ナリ 5. リレーログ更新
3. テーブル 新 ロ 4-2. バイナリログ
更新 グ 送信 6. 更新の適用
ストレージ バイナリログ リレーログ ストレージ
エンジン エンジン
マスター スレーブ

15. MySQL のレプリケーション（つづき）
マスター / スレーブ マルチマスター
Master Slave Master Master
+ Slave + Slave
カスケード
Master Slave Slave
循環型
1:N
Master
Slave + Slave
Master
Master
+ Slave
Slave
Slave Master
+ Slave

16. MySQL 5.5 のおさらい
準同期レプリケーション
COMMIT 完了時にはスレーブへ更新が到達している
ることが保証されている。
アプリケーション
→ HA （高可用性）として利用可能か！？
1. COMMIT 7. send_ok
6-1-2. ack 6-1-1. ack
接続 スレーブ接続 I/O SQL
スレッド 2.
スレッド スレッド スレッド
バ
イ
更 ナリ 5. リレーログ更新
3. テーブル 新 ロ 4. バイナリログ
更新 グ 送信 6-2. 更新の適用
ストレージ バイナリログ リレーログ ストレージ
エンジン エンジン
マスター スレーブ

17. 準同期レプリケーションによる HA
● できるようになったこと ● できなかったこと
– マスタークラッシュ時に – スレーブの昇格
スレーブにデータが残 ● 1:N 構成
る – スレーブのクラッシュへ
– 1:1 構成 の対応
● クラッシュ時は再
セットアップ

18. Global Transaction ID
● トランザクションを一意に識別することができる ID
– UUID: トランザクション ID の形式で表現される
– 例） 095E0FF8-18AF-11E2-9E7C-5C260A2AA986:123456
● トランザクション ID はシーケンス
– 1:N 環境で、どのスレーブが最も進んでいるか一目瞭然！
● MASTER_AUTO_POSITION = 1

19. Global Transaction ID （つづき）
mysql> show binlog events in 'mysql-bin.000002'G
〜 省略 〜
*************************** 3. row ***************************
Log_name: mysql-bin.000002
Pos: 151
Event_type: Gtid
Server_id: 1
End_log_pos: 199
Info: SET @@SESSION.GTID_NEXT= '095E0FF8-18AF-11E2-9E7C-
5C260A2AA986:1'
〜 省略 〜

20. Global Transaction ID （つづき）
mysql> SHOW SLAVE STATUSG
*************************** 1. row ***************************
〜略〜
Master_UUID: 095e0ff8-18af-11e2-9e7c-5c260a2aa986
Master_Info_File: /path/to/datadir/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the
slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 095E0FF8-18AF-11E2-9E7C-5C260A2AA986:1
Executed_Gtid_Set: 095E0FF8-18AF-11E2-9E7C-5C260A2AA986:1
1 row in set (0.00 sec)

21. マスター昇格時の操作 - ビフォー
SHOW BINLOG EVENTS 等でそれぞれのサーバーのバイナリログの内容を比較するなど
によって昇格するサーバーの対応するバイナリログポジションを調べて・・・
mysql> change master to master_host='127.0.0.1',
-> master_port=13032,
-> master_user = 'rsandbox',
-> master_password = 'rsandbox',
-> master_log_file = 'mysql-bin.123456' ,
-> master_log_pos = 123456 ;
Query OK, 0 rows affected (0.00 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

22. マスター昇格時の操作 - アフター
mysql> change master to master_host='127.0.0.1',
-> master_port=13032,
-> master_auto_position = 1 ;
Query OK, 0 rows affected (0.03 sec)
mysql> start slave user='rsandbox' password='rsandbox';
Query OK, 0 rows affected, 1 warning (0.00 sec)

23. mysqlfailover
● マスターの自動的なフェイルオーバーを実行するツール
● MySQL Workbench に付属
– MySQL Utilities の一部
● 他にも便利なツールが！！
– Python 製

24. mysqlfailover サンプル
shell> mysqlfailover --master=root:msandbox@127.0.0.1:13032
--slaves=root:msandbox@127.0.0.1:13033,root:msandbox@127.0.0.1:13034
MySQL Replication Failover Utility
Failover Mode = auto Next Interval = Thu Oct 18 22:42:14 2012
Master Information
------------------
Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB
mysql-bin.000006 191
Replication Health Status
+------------+--------+---------+--------+------------+---------+
| host | port | role | state | gtid_mode | health |
+------------+--------+---------+--------+------------+---------+
| 127.0.0.1 | 13032 | MASTER | UP | ON | OK |
| 127.0.0.1 | 13033 | SLAVE | UP | ON | OK |
| 127.0.0.1 | 13034 | SLAVE | UP | ON | OK |
+------------+--------+---------+--------+------------+---------+
Q-quit R-refresh H-health G-GTID Lists U-UUIDs

25. mysqlfailover フェイルオーバー
MySQL Replication Failover Utility
Failover Mode = auto Next Interval = Thu Oct 18 22:43:31 2012
Master Information
------------------
Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB
mysql-bin.000003 621
Replication Health Status
+------------+--------+---------+--------+------------+---------+
| host | port | role | state | gtid_mode | health |
+------------+--------+---------+--------+------------+---------+
| 127.0.0.1 | 13033 | MASTER | UP | ON | OK |
| 127.0.0.1 | 13034 | SLAVE | UP | ON | OK |
+------------+--------+---------+--------+------------+---------+
Q-quit R-refresh H-health G-GTID Lists U-UUIDs

26. クラッシュセーフなスレーブ
● 以前のバージョン ● MySQL 5.6
InnoDB
クラッシュセーフ
InnoDB
レプリケーション情報
＝
レプリケーション情報 mysql.slave_relay_log_info
＝ テーブル
relay_log_info ファイル
InnoDB の更新とは非同期

27. フェイルオーバーのための
スレーブ用オプション
server_id=1
log_bin=mysql-bin
gtid_mode=on
log_slave_updates
disable_gtid_unsafe_statements
master_info_repository=TABLE
relay_log_info_repository=TABLE
report_host=hostname
report_port=3306

28. InnoDB

29. オンライン DDL
● MySQL 5.1 ビルトインまで
– 新しい定義のテーブルを作成してすべてのデータをコピー
– ALTER TABLE 中はテーブルの参照のみ可能
– 更新は ALTER が終わるまでブロックされる
● MySQL 5.1 InnoDB Plugin 〜 5.5
– セカンダリインデックス追加時はデータのコピーをせずイン
デックスだけを構築
– インデックス構築中は参照のみ可能
● MySQL 5.6
– インデックス構築中の更新が可能に！ New
– 特殊なオプション等は特に必要なし

30. テーブルスペースの
エクスポート / インポート
● テーブルを .ibd ファイルのコピーで他のマシンへ移行可能
– innodb_file_per_table
– MySQL 5.5 まではよくある間違いで、その操作はできな
かった。
● MySQL 5.6 で実施可能に！
– FLUSH TABLES t FOR EXPORT

31. テーブルスペースの
エクスポート / インポート手順
● 移行元
– FLUSH TABLES t FOR EXPORT;
– .ibd ファイルと .cfg ファイルをコピー
– UNLOCK TABLES;
● 移行先
– テーブルの入れ物を作っておく
● CREATE TABLE t (…) ENGINE INNODB;
● ALTER TABLE t DISCARD TABLESPACE;
– .ibd ファイルと .cfg ファイルをデータベースディレクトリ内
にコピー
– ALTER TABLE t IMPORT TABLESPACE;

32. デッドロック検出機能
● 検出ロジックが高速に
● エラーログに情報を出力
– innodb_print_all_deadlocks

33. デッドロックのログサンプル
InnoDB: transactions deadlock detected, dumping detailed information.
121018 2:28:28
*** (1) TRANSACTION:
TRANSACTION 6426, ACTIVE 16 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 1
MySQL thread id 1, OS thread handle 0x7f126453c700, query id 53 localhost msandbox
updating
update t set b='sss' where a=1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 6 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` trx id
6426 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 00000001; asc ;;
1: len 6; hex 000000001917; asc ;;
2: len 7; hex 13000001890110; asc ;;
3: len 3; hex 747474; asc ttt;;
*** (2) TRANSACTION:
TRANSACTION 6423, ACTIVE 65 sec starting index read
〜略〜
*** WE ROLL BACK TRANSACTION (2)

34. CPU スケーラビリティの向上
● MySQL Connect のキーノートスピーチで言及された数値
– R/W sysbench … MySQL 5.5 比で 151% 改善！
– Read Only sysbench … MySQL 5.5 比で 234% 改善！
– http://medianetwork.oracle.com/video/player/1873154739001
● kernel_mutex における処理の分散
● リードオンリートランザクション
– 更新の準備が不要なためオーバーヘッドが小さい
● START TRANACTION READ ONLY
● autocommit=1 における SELECT

35. フラッシュのアルゴリズム改善
● Adaptive Flushing の細かなチューニング
– リソースが不足しそうになるとよりアグレッシブなフラッシュ
を開始する low water mark を指定可能に
● innodb_adaptive_flushing_lwm
● innodb_max_dirty_pages_pct_lwm
– リソースが逼迫した時の I/O の量を指定可能に
● innodb_io_capacity_max
– フラッシュ動作変更の間隔を指定可能
● innodb_flushing_avg_loops
● フラッシュ専用のバックグラウンドスレッド pager_cleaner
– 毎秒起動
– innodb_lru_scan_depth でスレッドが検査するサイズを
指定可能
● ストレージに合わせたフラッシュ動作
– innodb_flush_neighbors

36. memcached プラグイン
MySQL MySQL MySQL memcached memcached
クライアント クライアント クライアント クライアント クライアント
ポート 3306 ポート 11211
接続スレッド
接続スレッド
SQL パーサ 接続スレッド memcached
オプティマイザ等 プラグイン
InnoDB
MySQL サーバー

37. オプティマイザ

38. 〜 MySQL 5.5
Nested Loop Join
SELECT … FROM t1 JOIN t2 ON … WHERE ...
for each row in t1 matching where condition {
for each row in t2 matching join and where condition {
send joined row to client
}
}

39. 〜 MySQL 5.5
Block Nested Loop Join
t1 t2
スキャン
1. WHERE 句の条件に沿って
t1 からレコードをフェッチし
バッファに格納
2. バッファが満タンに
なったら t2 を
スキャンして JOIN
3. t1 のすべての
レコードについて
くりかえし JOIN Buffer
Using Join Buffer...

40. MySQL 5.6 における
オプティマイザ改善点
● Disk Sweep Multi Range Read (MRR)
● Batched Key Access Join (BKA)
● Index Condition Pushdown (ICP)
● ORDER BY … LIMIT の効率化
● サブクエリのアルゴリズム改善
– Semi-Join
– FROM 句のサブクエリの改善

41. MRR がない場合
セカンダリインデックス レコード
レコードに
ランダムアクセス

42. MRR がある場合
セカンダリインデックス レコード
MRR
レコードの ROWID を
バッファに格納し、
ROWID でソート。
ROWID 順でアクセス。

43. Batched Key Access Join
t1 t2
1. WHERE 句の条件に沿って
t1 からレコードをフェッチし
バッファに格納
2. バッファが満タンに
なったら MRR で t2 から
レコードをフェッチして
JOIN
MRR
Scan
4. t1 のすべての 3. ROWID の順で
レコードについて t2 からレコードをフェッチ
くりかえし JOIN Buffer

44. Index Condition Pushdown
● 複合インデックスを用いたアクセスの効率化
● (col1, col2, col3) というインデックスがある場合、これまで
は WHERE col1=1 AND col3<10 というような条件では
col3 はテーブルからレコードをフェッチする際に評価され
なかった。

45. ICP がない場合
セカンダリインデックス レコード
col1 col2 col3
col1=1 のすべての
レコードをフェッチ。
: col3 の条件は使われない。
0 20 10
1 3 4
1 3 10
1 3 20
1 8 2
1 9 9
1 9 11
1 9 15
1 11 5
1 11 13
2 1 2
:

46. ICP がある場合
セカンダリインデックス レコード
col1 col2 col3
col1=1 かつ col3<10
の条件に合うレコード
: だけをフェッチ。
0 20 10
1 3 4
1 3 10
1 3 20 フェッチされずに
1 8 2 済んだレコード
1 9 9
1 9 11
1 9 15
1 11 5
1 11 13
2 1 2
:

47. ORDER BY … LIMIT の効率化
● SELECT column_list FROM single_table ORDER BY
non_indexed_colum LIMIT n
– というような構造のクエリが速くなる。
– Using sort buffer...
● 従来のアルゴリズム
– すべての結果をソートしてから上位の n 個を返す
● MySQL 5.6 のアルゴリズム
– ソートバッファに n 個のレコードが確実に格納出来るとわ
かっている場合、上位の結果だけをソートバッファに格納
する
– ソートバッファに収まらない場合は従来のアルゴリズム

48. Semi Join
● 相関サブクエリの効率を改善
– 従来のアルゴリズム＝外部クエリから１行フェッチするごと
に、サブクエリを実行
– 相関のないサブクエリは最初に１度だけ実行されるので遅
くはない
● 従来は開発者が JOIN に書き換える必要があった。
– 多くの場合は SELECT DISTINCT で対応可能
● Semi Join とは、重複を含まないサブクエリのこと。外部ク
エリ１行に対して最大で１行だけマッチする Join のこと。
– SQL には Semi Join に該当する Join はない。

49. MySQL 5.5 の例 - EXPLAIN
EXPLAIN SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT City.CountryCode FROM
City WHERE Name LIKE 'A%')G
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: Country
type: index
possible_keys: NULL
key: PRIMARY
key_len: 3
ref: NULL
rows: 247
Extra: Using where; Using index
*************************** 2. row ***************************
id: 2
select_type: DEPENDENT SUBQUERY
table: City
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4037
Extra: Using where
2 rows in set (0.00 sec)

50. MySQL 5.5 の例 - SELECT
mysql> SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT
City.CountryCode FROM City WHERE Name LIKE 'A%')G
*************************** 1. row ***************************
COUNT(1): 71
1 row in set (0.26 sec)
mysql> SHOW STATUS LIKE 'handler_read%';
+-----------------------+--------+
| Variable_name | Value |
+-----------------------+--------+
| Handler_read_first | 240 |
| Handler_read_key | 240 |
| Handler_read_last | 0 |
| Handler_read_next | 239 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 824291 |
+-----------------------+--------+
7 rows in set (0.00 sec)

51. MySQL 5.6 の例 - EXPLAIN
EXPLAIN SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT
City.CountryCode FROM City WHERE Name LIKE 'A%')G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: Country
type: index
possible_keys: PRIMARY
key: PRIMARY
key_len: 3
ref: NULL
rows: 239
Extra: Using where; Using index
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: <subquery2>
type: eq_ref
possible_keys: <auto_key>
key: <auto_key>
key_len: 3
ref: world.Country.Code
rows: 1
Extra: NULL ・・・つづく

52. MySQL 5.6 の例 - EXPLAIN
つづき
*************************** 3. row ***************************
id: 2
select_type: MATERIALIZED
table: City
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4188
Extra: Using where
3 rows in set (0.00 sec)

53. MySQL 5.6 の例 - SELECT
mysql> SELECT COUNT(1) FROM Country WHERE Country.Code IN (SELECT
City.CountryCode FROM City WHERE Name LIKE 'A%')G
*************************** 1. row ***************************
COUNT(1): 71
1 row in set (0.00 sec)
mysql> SHOW STATUS LIKE 'handler_read%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Handler_read_first | 2 |
| Handler_read_key | 241 |
| Handler_read_last | 0 |
| Handler_read_next | 239 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 4080 |
+-----------------------+-------+
7 rows in set (0.00 sec)

54. FROM 句のサブクエリ
● 評価の遅延
– マテリアライゼーションが実際にレコードが必要な場合だけ
行われるように。
– EXPLAIN が高速化。
– WHERE 句の条件次第ではマテリアライゼーションが不要
に。
● マテリアライゼーションによって作成されたテンポラリテー
ブルにインデックスを作成。

55. MySQL 5.5 の例
mysql> SELECT COUNT(1) FROM Country C1 JOIN (SELECT * FROM City) AS C2
ON (C1.Capital = C2.ID) WHERE C1.Name LIKE 'X%';
+----------+
| COUNT(1) |
+----------+
| 0 |
+----------+
1 row in set (0.00 sec)
mysql> SHOW STATUS LIKE 'handler_read%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Handler_read_first | 2 |
| Handler_read_key | 2 |
| Handler_read_last | 0 |
| Handler_read_next | 0 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 4320 |
+-----------------------+-------+
7 rows in set (0.00 sec)

56. MySQL 5.6 の例
mysql> SELECT COUNT(1) FROM Country C1 JOIN (SELECT * FROM City) AS C2
ON (C1.Capital = C2.ID) WHERE C1.Name LIKE 'X%';
+----------+
| COUNT(1) |
+----------+
| 0 |
+----------+
1 row in set (0.00 sec)
mysql> SHOW STATUS LIKE 'handler_read%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Handler_read_first | 1 |
| Handler_read_key | 1 |
| Handler_read_last | 0 |
| Handler_read_next | 0 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 240 |
+-----------------------+-------+
7 rows in set (0.00 sec)

57. まとめ
● MySQL 5.6 には大幅な新機能が追加された。
– 本日紹介したもの
● レプリケーション
● InnoDB
● オプティマイザ
● MySQL は急速に進化中！！
● GA （正式版）リリースをお楽しみに。

58. ご静聴ありがとうございました。