[第14回] 実行中のSQLを止める — QueryPieクエリモニタリング

権限と承認を整えても運用中は実行中SQLの確認が必要になる。遅いという連絡があれば、誰がどのDBで何を実行したかから探す。

開発者のWeb SQLエディターで実行し、管理者のRunning Queriesで見つけて停止した。同じエディターで通常の注文参照を続けられるかも確認した。

1. 長時間実行するテストSQLを用意する

Orders Control LabとDemo Developerを使い、Web SQLエディターで次のSQLを実行した。

SELECT SLEEP(300) AS acp_web_monitoring_demo;

300秒待機するテストSQLで、注文を変えずに管理者の確認時間を確保するものだ。障害や過負荷を起こす実験ではない。

2. 管理者は実行中SQLを一か所で確認できる

Databases → Monitoring → Running Queriesを更新すると、SQLが時刻・ユーザー・接続名・権限とともに表示された。

DBアカウントから人を探さず、Demo DeveloperがOrders Control Labで実行したと分かった。共有DBではこの情報がまとまると便利そうだ。

3. 詳細で実際のSQLを確認する

Running Query Detailsにはユーザー、Read-Only、DBとアカウント、接続IP、SQL、Executed From: Web Editorがあった。

停止前にSQLのacp_web_monitoring_demoで自分のテストと確認した。運用でも実行者とSQLを見て対象を判断できそうだ。

4. 管理画面から選択SQLを止める

詳細を閉じ、項目を選んでKill Queryを押し、確認画面でOKを選んだ。

確認した画面からそのまま対応できる点がよかった。今回のWebエディターテストでは別のDBツールで終了コマンドを入れる必要がなかった。

開発者画面に戻るとSQLの下に SQL Execution stoppedと表示された。300秒を待たず管理者の操作で停止したと確認できた。

Running Queriesからも消えた。両画面の前後を確認すると何を止めたかが明確だった。

5. 停止後も必要な参照は続けられる

同じエディターでテストSQLを消し、注文参照を実行した。

SELECT order_id, status, total_amountFROM orders_control.ordersWHERE order_id = 4002;

4002番のDELIVEREDと32000.00が正常に返った。権限を回収せず実行中SQLだけ止めたため、必要な参照を続けられた。

6. 導入検討では運用中の対応にも注目したい

QueryPieの役割は接続者の指定だけではない。接続後のSQLを確認し、必要なら管理者が停止する流れまでつながった。

実行者・DB・SQLを同じ画面で見てから対応できた。状況把握の情報と操作が近く、問題時に使いやすそうだ。

今回確認したのは、 Web SQLエディターのSQLをRunning QueriesのKill Queryで停止する過程だ。実行中作業は止まり、通常参照は続けられた。アクセス制御と日常DB運用を併せて見たい担当者に紹介したい。