MySQL/MariaDB UPDATEとDELETEの内部ロジック - BizStationブログ
前回のブログ「MySQL/MariaDBとTransactdのInnoDBロック制御詳細」で、「ロックなし読み取りと更新の混在に注意」と書きましたが、「更新前の値を条件で指定したUPDATEやDELETEは問題ないと思うが心配だ」という質問をいただきました。そこで今回は、UPDATEとDELETE文のInnoDBロックについて説明したいと思います。とは言っても、ロックの内容については既に説明済なので、更新処理の内部ロジックについて説明します。それが今回の質問の答えでもあります。 更新前の値をWHERE句で特定した更新 更新前の値をWHERE句で特定した更新の例としては、statusを1から2に変更して状態遷移させるような更新があります。たとえば以下のようなSQL文です。 UPDATE user SET status = 2 WHERE id = 1 and status = 1; ポイント
MySQL/MariaDBとTransactdのInnoDBロック制御詳細 その1 - BizStationブログ
今回から数回にわたり、TransactdのオペレーションとInnoDBにおけるロックについて解説します。 ロックについてはあまり良くわからなくてもとりあえずそれなりに動くアプリケーションは作れてしまいます。ですが、マルチユーザー環境でミッションクリティカルなアプリケーションを書くには、ロックの理解が不可欠です。ロックをうまく使って、矛盾や間違いのない読み書きをしつつ同時実行性も高いアプリケーションにしましょう。 その1では、Transactdを実装する上でMySQLのソースやドキュメントから得た知見を基に、InnoDBのロックの種類と分離レベルに応じてそれをどのように使うかをまとめてみます。 Index MySQLのトランザクション関連用語 MySQLのREPEATABLE-READ InnoDBのロック 行ロック (row-level locking) GAPロック GAPロック単体 ネ
MySQL パフォーマンスとtransactd その２の１ - BizStationブログ
その２はselect * from tablename where fieldname = xxxです。長くなるのでまずは２の１から。 なんとも簡単なSQL文ですが、テーブルの定義やデータの状況によって全くパフォーマンスが異なってきます。 使用するインデックス解析 MySQLはまずSQL文を解析し、fieldnameフィールドをキーセグメントの先頭に持つインデックスが存在するか調べます。存在すれば、そのインデックスを使用したオペレーションhandler::ha_index_read_map(HA_READ_KEY_EXACT)を使い操作を組み立てます。無ければ、hanndler::ha_rnd_next()かhandler::ha_index_next()を使ったレコードスキャンをします。 実は、このインデックスの選択と、handler::ha_index_read_map()オペレーショ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
