Runaway Queries 管理：提升 TiDB 稳定性的智能引擎
内容提要
数字化系统中，数据库稳定性是企业关注的核心问题。TiDB在7.2.0引入Runaway Queries管理，通过系统化的手段缓解SQL性能问题，提供查询的识别和处置能力，提升用户体验和可观测性。
延伸解读
动态识别与静态识别的适用场景
动态识别基于运行时规则（如EXEC_ELAPSED）自动发现超时查询，适合应对突发性能问题；静态识别则通过SQL特征（文本、Digest、Plan Digest）精确匹配，适合已知问题查询的黑名单管理。两者互补，动态识别覆盖未知异常，静态识别提供人工干预手段，用户可根据实际需求组合使用。
处置方式的选择与风险控制
TiDB提供DRYRUN、COOLDOWN和KILL三种处置方式。DRYRUN仅记录不干预，适合初期验证规则避免误判；COOLDOWN限制查询速度，但在复杂场景下效果有限；KILL直接终止查询，对服务质量要求高的场景推荐使用。建议先以DRYRUN试运行，确认规则准确后再启用KILL，以平衡稳定性和误杀风险。
监控列表与自动恢复机制
通过WATCH子句可将识别到的查询特征加入监控列表一段时间（如10分钟），期间类似查询直接处置，无需重复等待阈值。到期后自动放开限制，检查查询性能是否恢复：若恢复则移除监控，否则继续监控。这种阶段性检查机制既能快速抑制问题，又避免长期误伤已优化的查询。
可观测性与历史记录
TiDB提供系统表RESOURCE_GROUPS、RUNAWAY_WATCHES和TIDB_RUNAWAY_QUERIES，分别用于查看资源组规则、监控队列和识别处置历史。结合Query Max Duration监控指标，可辅助设置合理的EXEC_ELAPSED阈值。这些工具帮助管理员追踪问题查询、评估规则效果，并为容量规划提供数据支持。
Q&A
TiDB 的 Runaway Queries 管理是什么？
Runaway Queries 管理是 TiDB 从 7.2.0 版本开始引入的一项资源管控功能，旨在通过系统化的手段自动识别和处置执行时间或资源消耗超出预期的查询，以缓解突发 SQL 性能问题，提升数据库稳定性。
Runaway Queries 管理适用于哪些场景？
适用于三种场景：1. 需要自动识别并处理异常 SQL 性能问题以保障重要系统服务质量；2. 遇到突发 SQL 性能问题且无立即修复手段时，希望临时缓解影响；3. 已知个别 SQL 有安全或性能问题，希望加入黑名单或限流。
Runaway Queries 的识别方式有哪些？
有两种识别方式：动态识别根据运行时规则（如 EXEC_ELAPSED 设置执行时间阈值）自动识别；静态识别根据 SQL 特征（如 SQL Text、SQL Digest、Plan Digest）通过 query watch 命令人工管理监控列表。
Runaway Queries 被识别后有哪些处置方式？
支持三种处置方式：DRYRUN 仅识别不处理，用于试运行检测误判；COOLDOWN 将查询置于资源组最低优先级，限制处理速度；KILL 终止查询，防止进一步影响性能。在 7.5.0 版本中，若对服务质量要求高，推荐使用 KILL。
如何查看 Runaway Queries 的历史记录和监控规则？
可以通过以下系统表查询：INFORMATION_SCHEMA.RESOURCE_GROUPS 查看资源组定义及识别处置设置；INFORMATION_SCHEMA.RUNAWAY_WATCHES 查看监控队列中的规则；MYSQL.TIDB_RUNAWAY_QUERIES 查看被识别和处置的历史记录。
能否举例说明 Runaway Queries 管理的实际效果？
例如，正常负载下 QPS 约 11k，P999 约 50ms。出现异常查询后 QPS 降至 3k，P999 升至 200ms。通过设置规则自动杀掉运行超过 1 秒的查询，QPS 回升至 7.5k；进一步将类似查询加入监控列表（WATCH=EXACT DURATION='5m'），QPS 和 P999 恢复到正常水平。
TiDB 未来在 Runaway Queries 管理方面有哪些规划？
未来 TiDB 会持续增强管理 Runaway Queries 的能力，支持更多且复杂的识别规则，增加更丰富的处理手段，全面提升可观测性，并引入图形化管理方式以进一步提升用户体验。
