今後どんどんOSS-DBとして主流になっていくと思われる。
MariaDBついてまとめる。
■MySQLとの比較
MariaDB10.0からは、MySQL5.6の機能を取り込む形となった。（それまではMySQLをベースとして開発していたが、MySQL5.6が大きくリファクタされ困難となったため）
今後は、今までのようにMySQLのスーパーセットとしてDBから、少しずつ独自拡張の進化を遂げていくのではないか。オプティマイザが賢い、スレッドプール、Role、マルチソースレプリケーションの機能がある。
通信プロトコルが同じなのでクライアントツールとしてはそのまま使える。
ダブルライトバッファ→テーブルデータの書き込み方法をダブルライトバッファという。デフォでは無効。(innodb_doublewrite)。通常はバッファプールから書き込む。
ダイナミックカラムを利用すると１項目に複数の値がセット出来る。実態はBLOB型として格納。
データファイルはテーブルごとに保存させることが出来る。
■超図解
・１クライアントに対して１接続スレッドが割り当てられる
・パースして一字一句同じSQLなら、クエリキャッシュにある同じクエリ結果を返却。
・バッファプールはメモリ上のデータ保存場所。ここに無ければディスクIOが発生。
■クエリキャッシュとは
SELECTステートメントのテキスト（つまりSQL）と、その結果を保存しておく機能。
その後、まったくおなじSQLが来たら、クエリキャッシュから結果を返却することで高速化をはかっている。
ちなみにデータ変更があると、関連するクエリキャッシュは全て削除されるので、古いデータが戻されることはない。
クエリキャッシュを使うとよいのは、システムとして表の更新はそこそこで参照が多い場合に有効。※ただし最近はハードウェアなどの進化によりそこまで効果のある機能ではなくなってきている。
■スレッド周りの説明
通常は、１クライアントにつき、１スレッドが生成および破棄される。
スレッドキャッシュ機能により、複数クライアントを受け持つスレッドのグループ単位で、
処理することが出来る。これにより、スレッド生成処理に伴うオーバーヘッドを
抑える事ができる。
※MySQLでは、この機能はEnterPrise版でのみ利用可能だが、MariaDBでは無償で利用可能。
※Oracleなどでいうコネクションプーリングとは違う。
⇒スレッドのキャッシュが、（接続認証後の）スレッド生成要求が来た場合のキャッシュなのに対して、コネクションプーリングは、それより前の（接続認証済みの）接続自体を確保しておく。
つまり、スレッドのキャッシュは生成時に行われるスレッドの生成／データ構造体の初期化などを省くことが出来る。
コネクションプールは、認証済みの接続を使い回すため、認証処理から含めて省ける。
■オプティマイザが分析時に利用する統計情報はいつ更新されるか
（１）テーブルが最初にオープンされたとき
（２）テーブルのデータが多く（１６分の一）更新された時もしくは２０億数行など
（３）ANALYZE TABLEが実行されたとき
（４）show tables status/ show index fromが実行されたとき
（５）InnoDBモニタがONになったとき
（６）MySQLサーバーの再起動
統計情報はデフォルトでは、テーブルに保持されていないため、途中で統計情報を変更してほしくない場合は、
ANALYZE TABLEを利用して、システムテーブルに保持するように変更する。
（MySQL5.6以降）
■perror （エラー内容確認ユーティリティ ）
よくSQLエラーになった時に、すぐ原因がわからない場合がある。
そんなときはperrorユーティリティを使う。
例）存在しないテーブルに対してSELECT
MariaDB [test]> select * from tbl;
ERROR 1146 (42S02): Table 'test.tbl' doesn't exist
[root@ ]# perror 1146
MySQL error code 1146 (ER_NO_SUCH_TABLE): Table '%-.192s.%-.192s' doesn't exist
例が微妙だが、同じ意味でも違った記述になるので内容によっては有用か。