MySQl 5.6新機能解説＠第一回中国地方DB勉強会

MySQL 5.6MySQL 5.6 新機能解説新機能解説
奥野幹也
@nippondanji
mikiya (dot) okuno (at) gmail (dot) com
＠第一回　中国地方 DB 勉強会

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

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

自己紹介（つづき）
●
ライフワーク
– 自由なソフトウェアの普及
●
オープンソースではない
– GNU 大好き
– KDE 大好き
●
ブログ
– 漢のコンピュータ道
– http://nippondanji.blogspot.com/

MySQL の構造的特徴
●
モノリシックカーネル
●
シングルプロセス・マルチスレッド
●
1 セッション＝ 1 スレッド
●
ストレージエンジン API によるデータストアの仮想化
●
プラグイン API
●
GNU Bison による Lexical Scanner
●
コストベースのオプティマイザ
●
全ての更新を保存するバイナリログ
●
2 種類のスレッドで実装された非同期型レプリケーション
●
ソースコードは C/C++ 混在（ 100 万行以上）

MySQL の仕組み
MySQL サーバ
ストレージエンジン API
コネクション
スレッド
クライアント
Java
MyISAM
table_name.MYI
table_name.MYD
InnoDB MySQL
Cluster
パーサー・オプティマイザ・アクセス管理等
テーブル
スペース
ログファイル
コネクション
スレッド
コネクション
スレッド
NDB
API
クライアント
PHP
クライアント
ODBC
SQL の解析と最
適化は共通
データノードデータノードデータノードデータノード
データの格納や
アクセス方法は
ストレージエン
ジンごとに違う

最新の正式版 MySQL 5.6!!
●
2013 年 2 月リリース
●
数々の新機能を搭載！！
●
MySQL 5.5GA （２０１０年 12 月）以来のメジャー
アップデート
– マイナーバージョンではありません。
– 過去の正式版
●
3.23 、 4.0 、 4.1 、 5.0 、 5.1 、 5.5

創世記
●
1979: MySQL の原形となるレポーティングツールが BASIC で書かれた
– 後に C で書き直されることになる
●
1985: Michael Widenius が TCX DataKonsult という会社をおこす。
– データウェアハウスの会社
●
1990 年代 : SQL インターフェイスを望む声
●
1995: 最初のバージョンとして MySQL 1.0 がリリース
– 一部のユーザーに向けた限定的なリリース
– SQL のサブセットをサポート
– Solaris 向け
– オープンソースではなかった。
●
1996: バージョン 3.11
– Linux 向け
– オープンソースに！
●
2000: バージョン 3.23β 版が登場
参照
Understanding
MySQL
Internals

古代文明
●
MySQL 3.23 （ 2000 年）
– 数多くのプラットフォームへ移植が進む
– シングルスレッド版レプリケーション
– ISAM MyISAM→
– Berkeley DB への接続にチャレンジ

ルネッサンス
●
MySQL 4.0 （ 2003 年）
– InnoDB
– UNION
– スレーブのマルチスレッド化
– SSL
●
MySQL 4.1 （ 2004 年）
– Unicode
– プリペアドステートメント
– サブクエリ

大航海時代
●
MySQL 5.0 （ 2005 年）
– ストアドプロシージャ
– ストアドファンクション
– トリガ
– ビュー
– XA トランザクション
– Information schema

開国
●
MySQL 5.1 （ 2008 年）
– パーティショニング
– 行ベースレプリケーション
– XML 関数
– イベントスケジューラー
– ログテーブル

産業革命
●
MySQL 5.5 （ 2010 年）
– 準同期レプリケーション
– InnoDB Plugin がデフォルトに！！
– ロックの改善
– 4 バイト UTF-8 対応
– FLUSH LOGS の改善
– COLUMNS パーティショニングの追加
– DTrace サポート
– Performance schema

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

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

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

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

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

MySQL 5.6 新機能総評
●
RDBMS としての根幹に関わるような機能追加はない
– 過去のバージョンで対応済み！！
●
トランザクション対応
●
プリペアドステートメント
●
ビュー
●
サブクエリ
●
ストアドプロシージャ
●
パーティショニング
●
製品としては成熟期に入っている。
– 安定
– 簡単
– 高性能
●
ただし改良のペースはマックス。

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

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

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

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

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

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'
〜省略〜

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)

マスター昇格時の操作 - ビフォー
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;

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

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

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 |
+------------+--------+---------+--------+------------+---------+

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

フェイルオーバーのための
スレーブ用オプション
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
relay_log_recovery=1
report_host=hostname
report_port=3306

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

クラッシュセーフな
スレーブ用オプション
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
relay_log_recovery=1
report_host=hostname
report_port=3306

バイナリログの信頼性向上
●
マスター、スレーブ双方で壊れていないことをチェッ
ク
– CRC32 によるチェックサム
●
チェックサムの有効化
– binlog_checksum=CRC32
●
マスター側での確認の有効化
– master_verify_checksum=1
●
スレーブ側での確認の有効化
– slave_sql_verify_checksum=1

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

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

テーブルスペースの
エクスポート / インポート手順
●
移行元
– 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;

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

デッドロックのログサンプル
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

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

フラッシュのアルゴリズム改善
●
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 でスレッドが検査するサイズを指
定可能

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

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

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

MRR がある場合
MRR
レコードの ROWID を
バッファに格納し、
ROWID でソート。
ROWID 順でアクセス。

〜 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
}
}

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

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

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

ICP がない場合
col1 col2 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
col1=1 のすべての
レコードをフェッチ。
col3 の条件は使われない。

ICP がある場合
col1 col2 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
フェッチされずに
済んだレコード
col1=1 かつ col3<10
の条件に合うレコード
だけをフェッチ。

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

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

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

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
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 |

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>
・・・つづく

つづき
*************************** 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)

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
+-----------------------+-------+
+-----------------------+-------+
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 4080 |

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

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 |
+----------+
+-----------------------+-------+
+-----------------------+-------+

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 |
+----------+
+-----------------------+-------+
+-----------------------+-------+

まとめ
●
MySQL 5.6 には大幅な新機能が追加された。
– 本日紹介したもの
●
レプリケーション
● InnoDB
●
オプティマイザ
●
MySQL は急速に進化中！！
ぜひ使ってみてください！

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

MySQl 5.6新機能解説＠第一回中国地方DB勉強会

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à MySQl 5.6新機能解説＠第一回中国地方DB勉強会

Similaire à MySQl 5.6新機能解説＠第一回中国地方DB勉強会 (20)

Plus de Mikiya Okuno

Plus de Mikiya Okuno (19)