# データベース性能トラブルシューティング ## 定義 データベース性能トラブルシューティングは、関係データベースの性能ボトルネックを特定・診断・解消するプロセスである。一般的に **Detection**(何が・いつ問題か)、**RCA**(なぜ性能が低下したか)、**Recommendation/Remediation**(どう修正するか)の 3 段で構成される。クラウドマネージド DB 環境では DBA の手動診断からの脱却が求められ、ML ベースの自動化が進んでいる。([[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]]) 本ページは [[データベース自律診断]] のうち、とくにパイプライン設計・Detection-RCA-Resolution の連鎖・スケーラビリティの観点に焦点を当てた横断集約を担う。 ## 横断的知見 - **Detection-RCA-Recommendation の 3 段パイプラインが産業標準となっている**: Vista ([[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]])、D-Bot ([[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]])、OpDiag ([[@2025__TKDE__OpDiag - Unveiling Database Performance Anomalies Through Query Operator Attribution]])はいずれもこの 3 段構造を採用する。異なるのは各段の実装——Vista は深層予測モデル + POF RCA、D-Bot は UCT 型探索 + LLM 推論、OpDiag は演算子レベル帰属——であり、パイプライン構造の共通性は「問題の構造が技術に依らず安定している」ことを示す。(Source: [[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]], [[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]], [[@2025__TKDE__OpDiag - Unveiling Database Performance Anomalies Through Query Operator Attribution]]) - **実世界のクラウド DB ワークロードは「ノイズ多・非定常・準周期的」という特性が従来手法の適用を妨げる**: Vista は 5 種の実顧客ワークロード(21 日間)を示し、周期性・スケール・外れ値の種類が DB ごとに大きく異なることを実証した。これは DBSherlock の「正常ベースラインを人間が指定する」設計や STL の静的モデルでは対処できない。同じ観察は iSQUAD([[@2026-06-26 DB ingest]])・PinSQL などの産業研究でも共通している。(Source: [[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]] §1) - **SQL クエリ統計の long-tail 分布が平均ベース RCA の根本的な失敗原因である**: Vista は「平均比較(T-test 等)は long-tail 分布で偽陽性と偽陰性を同時に生む」ことを図 7・8 で定性的に示した。FluxInfer ([[@2020__IPCCC__FluxInfer - Automatic Diagnosis of Performance Anomaly for Online Database System]])が DB メトリクスに対し「有向因果推定を捨てて無向グラフ + PageRank」で PC 系 8 手法を上回ったこと、BARO ([[@2024__FSE__BARO - Robust Root Cause Analysis for Microservices via Multivariate Bayesian Online Change Point Detection]])がマイクロサービス RCA で「平均でなく中央値・IQR」で頑強性を得たことと、同じ構図が DB ドメインで再確認される。「ノンパラメトリック / 分位数ベース統計が long-tail に有利」という原理がドメインをまたいで一致する。(Source: [[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]] §4.3, [[@2020__IPCCC__FluxInfer - Automatic Diagnosis of Performance Anomaly for Online Database System]], [[@2024__FSE__BARO - Robust Root Cause Analysis for Microservices via Multivariate Bayesian Online Change Point Detection]]) - **「高 Precision + bounded Recall」は本番では「最高 F1」より有用**: Vista の産業知見として、顧客は noisy なサービスより少ない偽アラームを好む。F1 最大化の方針は本番展開の前提と合わない。QTE の高分位数閾値設定(治療群 p90 vs 制御群 max)が Precision 重視の直接実装。同じ観察は [[MonitorAssistant]]([[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]])の「実用的異常 = 統計的逸脱 + インシデント裏付け」定義とも接続する——顧客にとって価値ある異常のみを検知することが、アルゴリズム精度より先に求められる要件。(Source: [[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]] §6.3.2) - **Self-supervised 深層モデル × フリートデータが「個別インスタンスのモデル維持不要」を実現した**: 数十万 DB に対して個別モデルを作ることは規模上不可能。Vista は ~100K ワークロードで共通の GRU 予測器を学習し、ゼロラベルでフリート全体に適用する。OSprey ([[@2024__arXiv__OS Pre-trained Transformer - Predicting Query Latencies across Changing System Contexts]])がシステムコンテキストをまたぐ汎化を因子分解アーキテクチャで達成したのと同じ「個別訓練コストを分散させる」設計方針の DB 異常検知版。(Source: [[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]] §4.2, [[@2024__arXiv__OS Pre-trained Transformer - Predicting Query Latencies across Changing System Contexts]]) ## 未解決の問い - Vista の RCA は「何が変わったか(クエリの挙動)」を特定するが、「なぜそれが問題なのか(因果)」の説明は人間 DBA に委ねる。LLM ベース手法(D-Bot・OpDiag)は因果説明まで自動化できるか。Vista の QTE スコアを LLM の説明生成の証拠として渡す統合は有効か。 - Wait event 集計による候補クエリ選択(トップ K = 5)は、根本原因クエリが wait event 上位に必ず現れるという仮定に依存する。クエリが少量実行されているが壊滅的な影響を持つケース(例: スキーマロック)では見逃しが生じないか。 - Vista の単変量 db_load が多変量異常検知に拡張された場合、RCA の QTE + Permutation test は多変量設定で計算効率を維持できるか。 - D-Bot・OpDiag は特定の DBMS (PostgreSQL・MySQL) に依存する知識を使う。Vista のエンジン非依存設計と組み合わせた場合、知識蒸留の最適な粒度はどこか。 ## 関連 - 親 concept: [[データベース自律診断]] / [[データベース O&M]] - 隣接 concept: [[異常検知]] / [[根本原因分析]] / [[データベースノブチューニング]] - 主要ソース: [[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]] / [[@2020__IPCCC__FluxInfer - Automatic Diagnosis of Performance Anomaly for Online Database System]] / [[@2025__TKDE__OpDiag - Unveiling Database Performance Anomalies Through Query Operator Attribution]] ## 出典 - [[@2023__Amazon Science__Vista - Machine Learning based Database Performance Troubleshooting Framework in Amazon RDS]](Vista: 3 段パイプライン・GRU 検知・POF RCA・産業展開) - [[@2020__IPCCC__FluxInfer - Automatic Diagnosis of Performance Anomaly for Online Database System]](FluxInfer: 無向グラフ + PageRank による DB RCA) - [[@2025__TKDE__OpDiag - Unveiling Database Performance Anomalies Through Query Operator Attribution]](OpDiag: 演算子レベル帰属) - [[@2024__PVLDB__D-Bot - Database Diagnosis System using Large Language Models]](D-Bot: UCT + LLM による診断)