MySQLのココにギョッとした！ - オラクルエンジニアがMySQLを触って感じたこと

Copyright © 2016 CO-Sol Inc. All Rights Reserved. 1Copyright © 2016 CO-Sol Inc. All Rights Reserved.Copyright © 2016 CO-Sol Inc. All Rights Reserved.
MySQLのココにギョッとした！
オラクルエンジニアがMySQLを
触って感じたこと
2016年12月13日
株式会社コーソル渡部亮太

Copyright © 2016 CO-Sol Inc. All Rights Reserved. 2
今日の発表について
• コーソルは東京・福岡・豊田を拠点にOracle Database
を中心にしたプロフェッショナルサービスを提供してい
ますが、MySQLなどのOracle Database以外のデータ
ベースについても対応しています
• Oracle Databaseを中心にデータベースエンジニアとし
て経験を積んできたエンジニア（＝私）が
初めてMySQLを使った時(主にver5.6/5.5だった)に驚いたこ
とについて発表させていただきます
• InnoDB、Community Editionを前提とします
• 日々の業務に直接役に立つ内容ではありませんが・・・
皆さんが当たり前と思っているMySQLの特徴をあらため
て振り返る機会になれば幸いです 

自己紹介+所属会社紹介
渡部亮太（わたべりょうた）
– 著書「プロとしてのOracleアーキテクチャ入門
[第2版]」「プロとしてのOracle運用管理入門」
– 講演実績多数
– ブログ「コーソルDatabaseエンジニアのBlog」
http://cosol.jp/techdb/
– JPOUG 共同創設者、ボードメンバー
– Oracle ACE (Oracle Database)
– 2016年9月より東京から福岡に移住
株式会社コーソル
– 「CO-Solutions＝共に解決する」の理念のもと、Oracle技術に特化
した事業を展開中。心あるサービスの提供とデータベースエンジニア
の育成に注力している
– 社員数: 133名 (2016年12月時点)
– ORACLE MASTER Platinum 11g 取得者数 47名
ORACLE MASTER Platinum 12c 取得者数 32名
取得者数日本 No.1 （日本オラクル様Webページより）
http://www.oracle.com/jp/education/omdata-171891-ja.html
NEW!

MySQLのココにギョッとした！ - Agenda
• テーブル内部の物理構造が違う
• ユーザー関連の概念が特徴的
• 領域管理の考え方が違う
• 恐怖の「SQLモード」
• トランザクションログが2つある？
• ナイーブなレプリケーション

テーブル内部の物理構造が違う

xxx-
nnn
InnoDBテーブルの物理構造
• このテーブル構造をRDBMS一般の用語では、「クラスタ化インデックス」と呼ぶ
– 名称はインデックスですが、テーブルとインデックスが一体化したものと理解してください
– 主キーがない場合など例外的な状況におけるルールについてはマニュアルを参照してください
http://dev.mysql.com/doc/refman/5.6/ja/innodb-index-types.html
• 主キー経由のアクセスが高速
主キー
001-nnn
001-
500
001-
275
275-
500
501-
630
631-
759
760-
800
801-
949
950-
xxx
501-
800
801-
nnn
• リーフブロックに行全体のデータが格納される
• 一連のリーフブロック内のデータはソートされている

InnoDBのインデックス
• セカンダリインデックス
– 主キー用以外のインデック
ス
– 1つのテーブルに対して複
数作成可能
• セカンダリインデックスを
使用したアクセスはあまり
効率的でない
– 2回インデックスをたどる
キー
• リーフブロックに
主キー値が格納される
セカンダリインデックス
主キー
テーブル
（クラスタ化
インデックス）

Oracleのテーブル構造（ヒープ構造）
• ヒープ構造
– ブロック内の行データは特定の順序で並べられて
いない
• rowid
– それぞれの行データにはrowidという位置情報
（アドレス）を持つ
– rowidは内部的に管理される値であり、永続性が
ない
• 例えば、テーブルのデータ再編成を実行すると、
データに変化がなくてもrowidは変わりうる
hoge
foo
baz
fuga
bar
xxx
yyy
zzz
1
108
4
5
102
3
105
2
3 abc
…
(rowid)
(rowid)
(rowid)
(rowid)
(rowid)
(rowid)
(rowid)
(rowid)
(rowid)

Oracleのインデックス
hoge
foo
baz
fuga
bar
xxx
yyy
zzz
1
108
4
5
102
3
105
2
3 abc
…
キー
• リーフブロックに
キー値とrowidが格納される
インデックス
(rowid)
(rowid)
(rowid)
(rowid)
(rowid)
(rowid)
(rowid)
(rowid)
(rowid)• インデックスの構造の観点では、主キーのインデック
スと、主キー以外のインデックスは原則的に同等

ユーザー関連の概念が
特徴的（すぎる）

MySQLにおけるユーザー
• ユーザーIDが<username>@<hostname>
– 同一ユーザー名を指定して接続しても、異なるユーザーとして扱われる場合があ
る
– [経験談] ユーザー名を指定して接続に成功したが、意図せず匿名ユーザーとして
接続しておりビックリ
• オブジェクトの所有者という概念がない
– Oracleを含めた多くのRDBMSでは、オブジェクトの所有者という権限があり、権
限の扱いが自分のオブジェクト、他人のオブジェクトで異なる
• 例) 自分のオブジェクトは全操作OK、他人のオブジェクトは権限がないと操作NGなど
• ユーザーをグループ化した「ロール」という概念がない
– MySQLで複数ユーザーに同一の権限セットを割り当てたい場合は、複数ユーザー
にGRANT文を同じように実行する必要がある
– MySQL 8.0からロールができる模様
https://yoku0825.blogspot.jp/2016/09/mysql-800role.html
• （Oracleでいうところの）スキーマという概念がない
– Oracleのスキーマ：あるユーザーが所有するすべてのオブジェクトを格納する論
理的な箱
– MySQLではデータベースをスキーマと呼ぶ場合もあるようだ

MySQLのアーキテクチャ
• スキーマやオブジェクトの所有者という概念はない
• データベースに接続する＝デフォルトの名前空間の選択
テーブル
データベース
ユーザー
接続
データディレクトリ
（datadir）
テーブル
ユーザー定義
mysqlデータベース

Oracle Databaseのアーキテクチャ
• ユーザーと同名のスキーマ名が必ず存在し、そのスキーマに接続する
• オブジェクトは所有者ユーザーのスキーマに存在
データベース
ユーザー
接続
スキーマ
（接続ユーザーが所有する）テーブル
1対1で対応
スキーマ
（接続ユーザー以外のユーザーが所有する）テーブル

(参考)PostgreSQLのアーキテクチャ
• オブジェクトはある特定のスキーマに格納する
• オブジェクトの所有者とスキーマは独立した概念
– SCOTTユーザーのテーブルをHRスキーマに格納できる
スキーマ
テーブル
スキーマ
テーブル
データベース
ユーザー
接続
データベース
クラスタ
スキーマ
テーブル
スキーマ
テーブル
ユーザー定義

領域管理の考え方が違う

MySQLの領域管理
• datadir → ディレクトリ(データベース) → ファイル(テーブル)
データディレクトリ
(datadir)
<データベース名>
[テーブル名].ibd
表領域
データファイル
テーブルサイズの増加に応じて
ファイルサイズが増加
テーブルサイズの増加に応じて
ファイル内の占有領域サイズが増加
初期構成時点で事前に領域割り当て
表領域の空き領域不足時に拡張
• Oracleの領域管理
– 表領域（複数のデータファイルから構成） → セグメント（≒テーブル）
テーブルとファイルが1対1で対応

I/O負荷の分散
考え方 Oracle Database MySQL
ファイルを別々の
ディスクに配置して
I/O負荷の分散を図
る
表領域を複数のデータファイルか
ら構成するようにして、
それぞれのデータファイルを別々
のディスクに配置する
データベースのディレクトリを別
ディスクに配置し、
デフォルトの場所からシンボリッ
クリンクを張る
CREATE TABLEにDATA
DIRECTORY句を指定して、デ
フォルトとは異なるディスクに保
管する (MySQL 5.6以降)
ファイルシステム以
下のレイヤーで複数
ディスクを束ねるこ
とでI/O負荷の分散
を図る
ASM（Oracleに同梱されるボ
リュームマネージャ相当のソフト
ウェア）を使用する
OS標準およびサードパーティの
ボリュームマネージャなどを使用
する

恐怖の「SQLモード」

SQLモード
• SQLモード(SQL_MODE)とは
– SQL処理における以下の振る舞いを調整するシステム変数
– 1. サポートするSQL文法を調整
– 2. データチェック機構の動作を調整
• 自動調整 + OK
• 自動調整 + 警告
• エラー
• SQLモードの意義？
– 過去バージョンのMySQL独自文法に従って記述されたSQLを実行可能に
しつつ、標準ベースのSQLも実行可能にすること？
– Oracle Databaseには類似のパラメータは存在しない
（おそらく他のRDBMSも）

1. サポートするSQL文法を調整する例
• '||'で文字列連結できない → '||' は論理和演算（OR演算）
– SQL_MODE='PIPES_AS_CONCAT'を設定すれば、文字列連結できる
• 引用符(クォート文字)の扱いが違う
mysql> SELECT 'A' || 'B';
+------------+
| 'A' || 'B' |
+------------+
| 0 |
+------------+
1 row in set, 2 warnings (0.00 sec)
mysql> show warnings;
+---------+------+---------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'A' |
| Warning | 1292 | Truncated incorrect DOUBLE value: 'B' |
+---------+------+---------------------------------------+
引用符
（クォート文字）
MySQL Oracle Database
MySQL (SQL_MODE=ANSI_QUOTE)
シングルクォート(') 文字列リテラル文字列リテラル
ダブルクォート(") 文字列リテラル識別子
バッククォート(`) 識別子 -

2. データチェック機構の動作を調整する例
mysql> SET SQL_MODE='STRICT_ALL_TABLES';
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO testaid VALUES('2013-02-30');
ERROR 1292 (22007): Incorrect date value: '2013-02-30' for column 'd' at row 1
mysql> SHOW ERRORS;
+-------+------+------------------------------------------------------------+
+-------+------+------------------------------------------------------------+
| Error | 1292 | Incorrect date value: '2013-02-30' for column 'd' at row 1 |
+-------+------+------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> SET SQL_MODE='';
mysql> INSERT INTO testaid VALUES('2013-02-30');
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> SHOW WARNINGS;
+---------+------+----------------------------------------+
+---------+------+----------------------------------------+
| Warning | 1265 | Data truncated for column 'd' at row 1 |
+---------+------+----------------------------------------+
mysql> SELECT * FROM testaid;
+------------+
| d |
+------------+
| 0000-00-00 |
+------------+
SQL_MODE 不正な日付の扱い（例: 2013-02-30)
STRICT_ALL_TABLES エラー
指定なし(デフォルト) 警告
0000-00-00にデータを変更
エラー
警告

SQLモードの恐怖
• 正確には「SQLモードのデフォルト値の恐怖」
• 現場的にはデータチェック機構が緩いことに起因する不
正データ混入が怖い
– ゼロの月やゼロの日
– など
• とうとうMySQL 5.7GAでデフォルト値が大きく「改善」
– すみません、発表準備のときまでこのことを知りませんでし
た・・・

SQLモードの分類
C) Strict Mode
B) Combination Mode
SQLモード設定値説明 ORACLE TRADITIONAL 他
ALLOW_INVALID_DATES 日付の完全チェックを行わないようにする
(例：'2004-04-31'を許す）
NO_ZERO_IN_DATE 月または日が'0'の日付を警告扱いにする(*1) o
NO_ZERO_DATE 日付'0000-00-00'を警告扱いにする(*1) o
ERROR_FOR_DIVISION_BY_ZERO '0'の割り算を警告扱いにする(*1) o
ANSI_QUOTES 引用符の扱いをANSI準拠にする o
PIPES_AS_CONCAT '||'を論理和演算子(OR)ではなく、文字列連
結として扱う
o
IGNORE_SPACE 関数名と'('の間の空白を許す o
NO_AUTO_CREATE_USER GRANT文実行時に該当ユーザーが存在しな
い場合、自動的にユーザーを作成しない
o o
NO_ENGINE_SUBSTITUTION 使用するストレージエンジンをMyISAMに自
動的に置換しない
o
他
SQLモード設定値をセットにして名前をつけたもの
構成するSQLモード設定値を列挙するのと同じ効果
データのチェック動作を強化し、警告をエラーにする
A) 通常のSQLモード設定値
それぞれの設定項目に対応して、サポートするSQL文法と、データ
チェック動作を変更する
SQLモード設定値説明
STRICT_ALL_TABLES Strict Modeを全テーブルに適用
STRICT_TRANS_TABLES Strict Modeをトランザクション対応テーブルにのみ適用
太字はMySQL 5.7GAでデフォルト採用
(*1) Strict Modeだとエラーとなるデータチェック動作

トランザクションログが2つある？

トランザクションログが2種類ある
• トランザクションログとは？
– データベースに適用された更新処理を記録しておくファ
イル
– プロセス障害からの復旧、ファイル消失・破損からの復
旧に使用される
• バイナリログ
– データベース更新時、DMLまたは行データが記録される
– 基本的にステートメントベースのロギング
(binlog_formatで変更可能)
– レプリケーションと復旧時のロールフォワードに使用さ
れる
– ファイル順次生成
• InnoDBログ
– InnoDBテーブル更新時、物理的な更新情報が記録され
る
– フィジオロジカルロギング
– インスタンスクラッシュ時のクラッシュリカバリに使用
される
– ローテーション書き込み
mysqld
<hostname>-bin.
000099
<hostname>-bin.
000001
ib_logfile0 ib_logfile1
:

トランザクションログの役割と、担うファイル
役割説明 MySQL Oracle
クラッシュ
リカバリ
インスタンスが異常終了した際に、次回起動時
にデータベースの整合性を回復する
InnoDB
ログファイル
REDOログファイル
(オンライン)
メディア
リカバリ
ファイル消失・破損後によってバックアップを
戻す必要がでた場合に、
バックアップに適用されていない更新処理を(再
度)適用する（ロールフォワード）
バイナリログ
ファイル
REDOログファイル
(オンライン＋
アーカイブ)
障害
00:00相当
の状態
更新
12:00相当
の状態
バイナリログ
ファイル
00:00 12:0012:00
バイナリログファイル
に記録された
更新系SQLを再実行
00:00
データの
エクスポート
00:00時点の
エクスポート
データ
データを
インポート
1. バックアップ 2. 障害発生 3. リストア 4. リカバリ
更
新
mysqldump
mysqlbinlog
メディアリカバリによるファイル破損への対処

ナイーブなレプリケーション

レプリケーション
mysqld（プライマリ）
バイナリログ
データ
ファイル
データ
ファイル
リレーログ
mysqld（スレーブ）
更新系SQLを記録
更新系SQLを
読み取り、実行
Oracleインスタンス
（プライマリ）
オンライン
REDOログ
データ
ファイル
データ
ファイル
スタンバイ
REDOログ
Oracleインスタンス
（フィジカルスタンバイ）
ブロックへの更新
内容を記録
ブロックへの更新内容
を読み取り、適用
pull型
push型
MySQLのレプリケーション
Oracleのレプリケーション(Data Guardフィジカルスタンバイ)
SQL

レプリケーションの比較
項目 Oracle Database
(Data Guardフィジカルスタンバイ)
MySQL
更新同期の考え方データブロックの更新内容を転送
し、プライマリDBと同じように
データブロックを物理的に更新す
る
更新系SQLそのもの（または列
データの変更）を転送し、スタン
バイDBでSQLを再実行する
同期性
（プライマリDBのコ
ミットと更新データ転
送の関係）
スタンバイDBへの更新データ転
送が完了するまでコミットできな
い構成（同期モード）で使用され
るケースが多い。
（データの保護を重視することが多い
ため。データ転送完了前にコミットで
きる構成も可能）
プライマリDBでのコミット可否
とスタンバイDBへのデータ転送
は非同期
（準同期レプリケーションではスタン
バイDBへのデータ転送を待機）
待機系DBにおける
更新適用処理の
パラレル化
自動的に有効 5.5以前パラレル不可
5.6 限定的に可能
5.7 可能
使用可能なEdition Enterprise Edition 全Edition
※：MySQLレプリケーション類似の機能としてGolden Gateという別売製品もあります

MySQLレプリケーションの仕組みからくる特性
• 利用者が実行SQLがunsafeかsafeどうかに留意する必要がある
– SQLベースのレプリケーション故の制限
– 意味的にunsafeであるにも関わらず、MySQL内部のチェックに引っかからない
ケースもある筈で、データ保護の観点からはちょっと怖い気もする
• プライマリDBはスタンバイDBのことをあまり気にしない
– プライマリDBのコミット完了と更新データ転送に関係性がないため
– データ保護をレプリケーションの第一目的と考えるOracle Databaseの感覚とは
かなり異なる
• 大量トランザクション実行時にスレーブの更新が遅れがち
– パラレルで実行している更新処理を、スレーブでシリアル実行しているため
• 大量更新はOracle Databaseでも辛い部分がありますが
– MySQL 5.6から、スレーブでパラレル更新が実行可能に
– MySQL 5.7では、パラレル更新がより効率的に
• バイナリログにパラレル更新用お制御情報を追加することで実現(Thanks 山崎さん！)
• 柔軟な構成が可能
– 一部のテーブルのみを同期する、一部のデータベースのみを同期するなど
– (意味があるかどうかは別にして)稼働系と待機系で異なるストレージエンジンを使
用することすら可能！
– Oracle DatabaseのDataGuardフィジカルスタンバイでは
原則的に稼働系と待機系で実行される更新処理および物理構造は同一
• データファイルにおけるブロック単位の変更を同期しているため
• 反面、一部のテーブルのみを同期するなんてことはできない

[驚いたこと] replicate_do_dbの罠
• replicate_do_db: レプリケーション対象のデータベース
を限定するパラメータ
• 個人的に2つの罠にハマったので共有しておきます
mysqld（プライマリ） mysqld（スレーブ）
db1
db2
replicate_do_db=db1
db1
db2

[驚いたこと] replicate_do_dbの罠1
• 罠1 （初級編）
– binlog_mode=statement、replicate_do_db=db1
– db1以外のデータベースの更新が同期される・・・
db1
db2
replicate_do_db=db1
db1
db2
INSERT INTO
db2.tbl1 ...

• 期待通り動作しない理由
– binlog_mode=statementでは、SQL文実行時のカレントデータ
ベースで同期対象かどうかが判断されるため
• SQL文で指定したオブジェクトのデータベース名ではない
• binlog_mode=rowとすると、 SQL文で指定したオブジェクトの
データベース名で同期対象かどうかが判断されるため、この問題を一
応回避できる（他にいろいろ面倒なルールはありますが・・・）
db1
db2
replicate_do_db=db1
db1
db2
use db1;
INSERT INTO
db2.tbl1 ...
use db1;
INSERT INTO
tbl1 ...
binlog_mode
=statement

• 罠2 （上級編？）
– binlog_mode=row、replicate_do_db=db1で、DDLが伝搬され
たりされなかったりする
db1
db2
replicate_do_db=db1
CREATE
TABLE ...
CREATE
TABLE ...
db1
db2
binlog_mode
= row

• 期待通り動作しない理由
– DDLはbinlog_mode=rowでもステートメントベースで実行
＝「binlog_mode=statement相当」
→ DDL実行時のカレントデータベースで同期対象かどうか判断
– カレントデータベースがdb1 → DDLが伝搬
カレントデータベースがdb1以外 → DDLが伝搬されず
db1
replicate_do_db=db1
use db1;
CREATE
TABLE db1.t1
use db2;
CREATE
TABLE db1.t2
binlog_mode
= row
db1

(参考) Oracle Databaseとの対照表 1/2
# Oracle Database MySQL 説明
1 スキーマデータベース MySQLにおけるデータベースは、Oracleにおける永続表領域とス
キーマをあわせたような特性を持つ。すなわち、セグメント（オブ
ジェクト）と物理ファイルとの対応関係を規定する物理的な役割と、
オブジェクトのコンテナという論理的な役割を併せ持つ
2 表領域
3 オブジェクト所有者 N/A MySQLのオブジェクトには所有者という概念はない
4 制御ファイル N/A 該当するファイルはない
5 SYSTEM表領域 mysql
データベース
ディクショナリ相当の情報（の一部）を表として格納するデータベー
ス。SYSTEM表領域に似ている
ユーザー情報を格納するmysql.userテーブルなどの権限関係のテーブ
ルが格納される
Oracle Databaseでディクショナリ表として管理される情報が、全て
mysqlデータベース内の表で管理されるわけではない。たとえば、
テーブル定義は、*.FRMファイルで保持される
6 SYSTEM表領域
+UNDO表領域+永
続表領域
InnoDB
テーブル
スペース
（InnoDBテーブルに関連する） Oracle Databaseでいうテーブルセ
グメント、インデックスセグメント、テーブルに関連するディクショ
ナリ情報、ロールバックセグメントが格納されるデータ領域
MySQLではSYSTEM表領域、UNDO表領域は独立した記憶領域として
存在しない
ユーザー指定の永続表領域（USERSなど）を明示的に作成することは
できない

(参考) Oracle Databaseとの対照表 2/2
# Oracle Database MySQL 説明
1 一時表領域 tmpdir tmpdirシステム変数で指定されたディレクトリに作業ファイルが
作成される
2 オンラインREDOロ
グ
バイナリログ
InnoDBログ
バイナリログがメディアリカバリ（バックアップリストア後のリ
カバリ）におけるロールフォワード、レプリケーションに使用さ
れる
InnoDBログがクラッシュリカバリに使用される
3 アーカイブREDOロ
グ
バイナリログ古いバイナリログがアーカイブREDOログに相当する
バイナリログはファイルを順次生成する（ローテーションしな
い）
3 環境変数
ORACLE_SID
--socketオプション（--socketオプションが事実上インスタンスの識別子になるが、
明示的に示されるものではないので、取扱いにくい印象）
4 V$ビュー
DBA_ビュー
INFORMATION_SC
HEMA
いくつかの診断情報が確認できるが、情報量は限定される
5 初期化パラメータシステム変数
（オプション）
mysqldの動作を制御する。オプションファイル(my.cnf)や、
mysqld起動時のコマンドラインオプションなどで指定できる
初期化パラメータと同様、動的変更可否とスコープ（グローバル、
セッション）という概念が存在する
6 pfile my.cnf MySQLサーバ以外の製品の設定も記載できる
優先度の異なる複数my.cnfの設定がマージされる場合がある
7 spfile N/A 該当なし

MySQLのココにギョッとした！ - オラクルエンジニアがMySQLを触って感じたこと

Recommended

Recommended

More Related Content

More from Ryota Watabe

More from Ryota Watabe (9)

MySQLのココにギョッとした！ - オラクルエンジニアがMySQLを触って感じたこと