ロック待ちでハマる前に知りたかったMySQL InnoDBの行ロックとテーブルロックの挙動
整合性をしっかりとらないといけない処理ではトランザクションをかけるのですが、どうもトランザクションのロック待ちでタイムアウトしてしまうことがあるようです。 java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction トランザクションでテーブル全体にロックがかかってしまう 要するに、「トランザクションを実行するためにロックを獲得しなければいけないが、他のコネクションがロックを握っていて、ロックが獲得できない」ということです。 これの根本的な原因は何かと調べますと、InnoDBでトランザクションを使用するときに、行ロックではなく、テーブル全体にロックがかかってしまう場合がある、というところにたどり着きました。 「InnoDBで行ロック/テーブルロックになる条件」を見ながら、少し試してみます。 テーブ
InnoDB の行レベルロックについて解説してみる
自分の浅はかな理解だと、Deadlock が起こる理由が説明できないケースに遭遇したので、InnoDB の行レベルロックについて調べてまとめてみました。 「行レベルロックだと、同じ行を更新する場合にしか Deadlock が起こらないんでしょ」と思っているような人が対象です。 また、主に InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる を参考にさせていただいたので、そちらの内容がすんなり理解できる方には冗長な内容だと思います。 MySQL のバージョンは 5.6.33 です。 サンプルデータ 次の SQL で作成したデータを扱うことにします。 CREATE TABLE `orders` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `product_id` int(10) unsigned NOT NULL, `us
長年の議論に終止符 -- MySQL、MariaDB、PostgreSQLのオプティマイザ/エクゼキュータ比較 - interdb’s blog
https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、４つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記：オプティマイザについては省略してますが、こんな本がでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 ＊念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
