MySQLシェアするLINE!CLIP!MySQLでテーブルが排他ロックになり、全部待ち状態になり動かなくなりました。processlist;でどのSQLが動いているか確認したところ、以下の順で命令されたSQLがロック状態でした。Locked4.参照処理もロックされているので、画面表示すらも何も出来なくなっていました。この環境のMySQLのバージョンは5.1です。今回は、この原因と対応方法を調べたので記録しておきます。参考情報スポンサーリンク原因ストレージエンジンがMyISAMだった結論として、該当テーブルのストレージエンジンにMyISAMを使っていた為でした。今回の環境でのMySQLのバージョンは5.1でした。MySQL5.1ではデフォルトのストレージエンジンがMyISAMだったのです。MySQL5.5からようやくデフォルトのストレージエンジンがInnoDBにになっていたのです。デフォルトのストレージエンジンでした。我々の経験上、ほとんどのユーザーはデフォルト設定を変更しませんでした。デフォルトのストレージエンジンです該当テーブルがMyISAMか調べるコマンドは以下です。'test_db';https://normalblog.net/system/mysql/mysql_matome/#InnoDBMyISAM何故、MyISAMだからロックの原因になるのかロック方式ロック方式には以下の2種類があります。テーブルロック・行ロックロック対象には以下の2種類があります。※InnoDBでもテーブルロックになる場合があります。update)をするとテーブル全体を排他ロックしてしまいます。排他ロックなので、ロック中は参照処理(select)する事すら待ち状態になってしまいます。update)と参照処理(select)両方がロックになっていたのは何故?今回の現象に照らし合わせてみると新たな疑問が出てきました。update)が実行中ならば、4.参照処理(select)がロックされてしまうのはわかるのですが、まだ1.重い参照処理(select)中なので、2.参照処理(select)と4.参照処理(select)は参照出来ず、ロックされてしまったのは何故だったのか?更新処理の優先度の方が参照処理よりも高いからクエリには優先度があり、更新処理が発生した後に発生した参照処理が、更新前の情報を持って帰らないようにしています。update)のロックに合わせて、後続の4.参照処理(select)までがロックになってしまったという事のようです。update)が待ち状態になったので、未実行だった、2.参照処理(select)もロックになったと推測されます。運用視点なMyISAMとInnoDBと。http://tech.lexues.co.jp/archives/1405運用あるある共有ロックなのに排他ロックになる参照クエリと更新クエリでは更新クエリの方が優先順位が高いです。重い参照クエリを投げてそのテーブルがロックされたあと、更新クエリを発行すると、実行中の参照クエリの次に更新クエリを実行しようと優先順位を上げます。その瞬間、共有ロックだったはずのテーブルが排他ロックになります(更新クエリが終わってから次の参照クエリを実行しようとするため)。更新処理が終わるまでは、参照できなくなってしまいます。Lockedこのようにロックになってしまった場合、先ずMyISAMから調査してMyISAMだった場合は、MyISAMをInnoDBに変更する。SQLの実行時間を短くする。この2点が考えられました。MyISAMをInnoDBに変更するについては以下コマンドで出来ますが、調べていくと、気を付けたい事項などが色々出てきましたので別途まとめます。https://dev.mysql.com/doc/refman/5.6/ja/innodb-default-se.html運用視点なMyISAMとInnoDBと。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。NormalBlog.net。