このクエリでロックされるテーブル
INSERT INTO stats.cps
(time_stamp,entries,cust_id)
select start_time, count(*) , c_id from gb.str
where start_time between '$DATE10' and '$DATE'
group by start_time, src_id
order by start_time ASC
DBサーバーから離れたマシンでこのクエリを実行しましたが、start_timeはインデックスではなかったため、しばらく時間がかかりました。パフォーマンスグラフを実行しているときに、クエリを実行しているスクリプトを停止すると、予想どおりに負荷が増加し、表示されなくなったことがわかりました。
別のアプリケーションはその正確な時間に誤動作していましたが、そのアプリケーションはデータが挿入されたstatsdbではなくgb.strテーブルを使用していました。そのアプリケーションの開発者は、このクエリがアプリケーションのパフォーマンス低下の理由であると考えていますが、gb.strをロックするべきではなかったと思います。 gb.strで長いSELECTクエリを実行して、そのアプリケーションのパフォーマンスが低下しているかどうかを確認しましたが、そうではありません。
クエリはgb.strもある程度ロックしますか？すべてのテーブルは、MariaDBに付属しているTokuDBです（10.0.22-MariaDB）
私が解釈する方法 トランザクションと同時実行性 TokuDBwikiで
selectを挿入
- シリアル化可能
- クエリによって読み取られたすべてのキー範囲の読み取りロックを取得します
- 書き込まれたすべてのキーの書き込みロックを取得します
- 繰り返し読み取り
- クエリによって読み取られたすべてのキー範囲の読み取りロックを取得します
- 書き込まれたすべてのキーの書き込みロックを取得します
- コミット済みを読む
- 書き込まれたすべてのキーの書き込みロックを取得します
- コミットされていない読み取り
- 書き込まれたすべてのキーの書き込みロックを取得します
サードパーティアプリケーションによる挿入では、キーを更新する必要があり、そのクエリによって同時に挿入対象として選択される特定の行に対して、キーがロックされる場合があります。
私の場合の解決方法は、過去にわずかにタイムスライスに対してクエリを実行して、そのアプリケーション（実際にデータを追加する）と一致しないようにすることです。