最近MariaDBばっかりです。
実施したバージョンは、10.1.20です。
●スレッドプール
MySQL（Standard）にはなくて、MariaDBに備わっている目玉機能は、
スレッドプールでしょう（thread_handling=pool-of-threads）。
スレッドプールというのは、クライアントからの接続に対して、
プール済みのスレッドから割り当てるものである。
実はよく似て、非なるパラメータがある。
それは、thread_cache_sizeである。
スレッドプールとthread_cache_sizeは説明などをよく読むと、
「生成済みのスレッドを使い回し、スレッド生成コストを抑える」
みたいなことが書いてある。
確かにその通りなのだが、内部的な動きに大きな違いがある。
筆者はMariaDBとMySQLの専門家ではないので、
以下間違った解釈かもしれません。なので、以下を呼んでも鵜呑みにしないでいただきたい。
個人的な解釈だが、スレッドプールとスレッドキャッシュの違いは、
スレッドのコンテキストスイッチまで踏み込んでいるかどうかだと考えている。
javaをやる人ならおなじみにコンテキストスイッチというのは、
大量スレッドが生まれた時の、スレッドの切り替えのことであり、
これが意外にコストが重い。
スレッドプールは、コンテキストスイッチを抑える機能でもあり、
スレッドキャッシュは、スレッドの生成抑制のみで、コンテキストスイッチを抑える働きはないと思う。
たとえば、スレッドプールを無効化した状態で、スレッドキャッシュサイズを100に設定したとする。
このとき、200の接続がきたら、100はキャッシュされ、100は新規作成＆終わったら破棄される。
また次の瞬間200の接続が来たら、100はキャッシュから取り出され、100は新規作成＆終わったら破棄される。
このように、スレッドキャッシュは、同時実行スレッドの抑制まではしない。
それに対し、スレッドプールの場合、スレッドプールサイズを100に設定したとする。
このとき、200の接続がきたら、100はスレッドプールが割り当てられ、残りの100は待機状態になる。
しかし、プールされた100スレッドは、トランザクションの重さによって、徐々に重いグループに移動され、軽いグループの空きを作って、そこに残りの100接続が徐々に割り当てる。
このように、同時実行をある程度制御することで、コンテキストスイッチを抑え、持続的なパフォーマンス維持に努めるのがスレッドプールの特徴である。
つまり、スレッドプールをやったからといって、必ずしもパフォーマンスが向上するわけではない。
スレッドプールの最大の特徴は、パフォーマンスの維持であると考えている。
そのため、大量のOLTPには向いているが、バッチ処理などには向いていないなど、得手不得手もある。
●並列レプリケーション
MariaDBにはMySQLとは異なる形で、並列レプリケーション機能を提供している。
MySQLの並列レプリケーションは、「異なるスキーマ」に対してのみ機能する。
それに対し、MariaDBの並列レプリケーションは、「異なるスキーマ」「コミットグループ」に対して、機能する。
具体的には以下2つである。
- slave-domain-parallel-threads（スキーマ）
- slave-parallel-threads（グループ）
詳しくは本家の説明ページを参照されたい。
https://mariadb.com/kb/en/mariadb/parallel-replication/
諸々書いてきたが、
MySQL5.7とMariaDB10.1ではほぼ同等（世間的にはMySQL5.7の上かな？）といったところと思います。
ただ、MariaDBのレプリケーションは、結構素晴らしいと思っています。
並列レプリケーション以外にも、GTIDがデフォルトで使えることによる扱いやすさもあるので、
個人的には国内でもMariaDBがもっと流行るといいなと願っています。