慢查询复盘后把索引经验沉淀为排查顺序验证边界本文的场景、图表和数值用于说明分析方法不代表特定线上系统的事实或性能承诺。复现时请记录版本、硬件与资源配额、输入和并发模型、预热与统计窗口以及失败路径。本文以可复现的示例场景梳理这一问题先说明约束和排查路径再给出可调整的实现。文中的故障经过、数字和结果需要在相同条件下复核不能直接外推到其他服务。1. 慢查询日志暴涨 30GAgent 自动生成的复合索引把磁盘 IOPS 直接拉满为了减轻 DBA 团队的日常巡检负担业务研发组上线了一款基于 AI Agent 的数据库慢查询自动优化工具。该 Agent 被赋予了查询慢日志、执行EXPLAIN分析以及通过 AI 自动给出CREATE INDEX语句的权限。然而在工具上线后的第三天晚上数据库集群突然触发严重告警主库磁盘 IOPS 冲顶到达 100%写入延迟从 2 毫秒暴增至 450 毫秒。MySQL [trade_db] SHOW PROCESSLIST; -------------------------------------------------------------------------------------------------------------------- | Id | User | Host | db | Command | Time | State | Info | -------------------------------------------------------------------------------------------------------------------- | 42 | admin| 10.0.1.15 | trade_db | Query | 120 | System lock | ALTER TABLE order_item ADD INDEX idx_a_b_c_d_e... | --------------------------------------------------------------------------------------------------------------------排查审计日志发现慢查询分析 Agent 针对一条包含 5 个WHERE条件和ORDER BY的复杂查询自动生成了一个包含 6 个字段的超大复合索引idx_a_b_c_d_e_f。更致命的是该表是一张单表数据量达 8,000 万行的核心交易流水表。Agent 在未评估写放大Write Amplification和锁表影响的情况下直接发起ALTER TABLE导致长时间持有 MDlMetadata Lock与剧烈的磁盘 IO 争抢。AI Agent 具备强大的上下文关联推理能力但在缺乏硬性工程规则约束时它的决策极易越过安全边界引发生产事故。2. 智能慢查询分析 Agent 的工具调用链路与规则决策约束为了阻止 Agent 产生“缺乏工程常识”的盲目优化行为我们重构了慢查询 Agent 的工具调用链路在决策中枢与数据库执行层之间强行打入了一套确定性的规则校验引擎Deterministic Rule Engine。flowchart TD A[MySQL 慢查询日志 Slow Log] -- B[Agent 慢查询解析器] B -- C[工具调用: EXPLAIN sys.schema_index_statistics] C -- D[LLM 生成初步索引优化提案] D -- E{确定性工程规则门禁 Rule Gate} E --|包含 4 个以上字段的超长索引| F[拒绝提案: 触发字段数超限规则] E --|高频写入表 DML QPS 500| G[拒绝提案: 触发写放大防线规则] E --|未指定 ALGORITHMINPLACE| H[自动修正: 强制注入 DDL 安全参数] E --|通过所有硬规则检查| I[生成 ADR 决策文档并提交 DBA 审批] I -- J[运维灰度窗口执行 DDL]核心原则在于将历史故障中汲取的经验转化为代码中不可篡改的“硬规则门禁”。AI Agent 可以发挥其想象力去推演潜在的执行计划但所有的建议需要通过硬性规则校验器的审计才能进入执行管道。3. 确定性安全闸门代码带 AST 树解析与索引写放大校验的建议拦截器下面是我们使用 Python 编写的确定性索引提案安全拦截器代码用于对 Agent 生成的 SQL DDL 语句进行语法解析与安全边界审核。import sqlglot from sqlglot import parse_one, exp from typing import Dict, Tuple class IndexSafetyGate: def __init__(self, max_index_columns: int 3, max_table_dml_qps: int 500): self.max_index_columns max_index_columns self.max_table_dml_qps max_table_dml_qps def evaluate_ddl(self, ddl_sql: str, table_stats: Dict[str, float]) - Tuple[bool, str]: 对 Agent 提交的 DDL 尝试进行 AST 语法解析并做确定性安全检查 try: expression parse_one(ddl_sql, readmysql) except Exception as e: return False, fSQL Syntax Error: {str(e)} # 检查是否为 CREATE INDEX 语句 if not isinstance(expression, exp.CreateIndex): return False, Security Violation: Only CREATE INDEX statements are permitted. # 提取索引列 columns expression.find_all(exp.Column) column_names [col.name for col in columns] # 规则 1限制复合索引的列数量防止过度索引 if len(column_names) self.max_index_columns: return False, fRule Violation: Index contains {len(column_names)} columns, exceeding maximum limit of {self.max_index_columns}. table_name expression.this.name if expression.this else unknown dml_qps table_stats.get(table_name, 0.0) # 规则 2高频写入表禁止在线新增多列索引防止写放大拖垮磁盘 if dml_qps self.max_table_dml_qps and len(column_names) 1: return False, fRule Violation: Table {table_name} has high DML QPS ({dml_qps}), multi-column index rejected. # 规则 3强制校验 DDL 需要包含 ALGORITHMINPLACE, LOCKNONE raw_sql_upper ddl_sql.upper() if ALGORITHMINPLACE not in raw_sql_upper or LOCKNONE not in raw_sql_upper: return False, Rule Violation: DDL must explicitly specify ALGORITHMINPLACE, LOCKNONE. return True, Passed Safety Audit # 规则引擎拦截测试 if __name__ __main__: gate IndexSafetyGate(max_index_columns3, max_table_dml_qps300) # 模拟 Agent 生成的一个危险 DDL 建议 agent_bad_ddl CREATE INDEX idx_trade_complex ON order_item (user_id, status, create_time, pay_type) ALGORITHMINPLACE, LOCKNONE; table_metrics {order_item: 850.0} # DML QPS 高达 850 passed, reason gate.evaluate_ddl(agent_bad_ddl, table_metrics) print(fAgent DDL Evaluation: Passed{passed}, Reason{reason}) # 输出: PassedFalse, ReasonRule Violation: Index contains 4 columns, exceeding maximum limit of 3.这套规则拦截器切断了 AI Agent 的“瞎指挥”。任何不符合线上运维标准的 SQL 修改提案在语法树解析阶段就会被斩立决。4. 线上真实案例复盘从全表扫描 4.2 秒到覆盖索引 12 毫秒的演进路线在引入规则门禁后我们挑选了一个真实的慢查询案例进行治理复盘。初始问题 SQLSELECT order_id, amount, status, create_time FROM user_orders WHERE user_id 1008611 AND status IN (2, 3) ORDER BY create_time DESC LIMIT 20;排障与演进推导路线现象该查询平均执行耗时 4.2 秒。在未建立索引前EXPLAIN显示typeALLrows4,200,000触发全表扫描与Using filesort。错误尝试未受控 Agent 建议 Agent 曾试图创建(user_id, status, amount, create_time)索引试图强行走全覆盖忽略了amount字段为浮点型且更新频繁会导致 B 树频繁分裂。安全规则介入修正规则引擎拒绝了包含amount的索引建议促使 Agent 调整方案为精准的(user_id, status, create_time)联合索引。最终效果对比优化阶段EXPLAIN type扫描行数 (rows)Extra 信息P99 执行耗时磁盘 IOPS优化前ALL4,200,000Using where; Using filesort4,250 ms4,500未受控 Agent (全覆盖)ref120Using index condition18 ms12,000 (写放大严重)规则受控后 (联合索引)range45Using index condition; Backward scan12 ms1,200 (稳定)通过引入规则门禁我们不仅获得了极致的查询性能还将写放大副作用降到了最低。5. 可复制的慢查询治理决策记录ADR与落地模板为了将每一次故障与优化的经验转化为团队长效的规则财富我们建立了标准的架构决策记录Architecture Decision Record, ADR模板并要求 Agent 自动将通过审计的变更沉淀到 Git 仓库中。慢查询治理 ADR 沉淀模板# ADR-20260811-004: user_orders 慢查询索引重构决策 ## 1. 背景与工程现象 - **故障描述**订单中心 nightly 批处理触发 user_orders 全表扫描占用 85% Buffer Pool。 - **慢 SQL 摘要**WHERE user_id ? AND status IN (...) ORDER BY create_time ## 2. 被拒绝的提案 (Anti-Patterns) - ❌ **直接增加 (user_id, status, amount) 覆盖索引**amount 字段频繁变更引起 B 树页分裂与锁争抢。 - ❌ **创建单列 status 索引**基数Cardinality极低无法有效过滤数据。 ## 3. 最终决策方案 (Accepted Solution) - ✅ **建立联合索引**ALTER TABLE user_orders ADD INDEX idx_uid_status_ctime (user_id, status, create_time) ALGORITHMINPLACE, LOCKNONE; - **选择理由**遵从最左前缀匹配原则索引兼顾 WHERE 条件过滤与 ORDER BY 消除 filesort。 ## 4. 确定性规则门禁新增项 (Rule Updates) - 新增 Rule-104**所有作用于包含 ORDER BY 的联合索引其排序列需要置于等值过滤字段之后**。 - 新增 Rule-105**禁止对变更频率 100 次/秒 的数值型字段建立辅助索引**。经验不是飘在脑海中的感悟而是需要硬化为代码里的安全检查。只有把失败案例写成拦截规则系统才会随着时间推移变得越来越坚固。收尾这里的重点是把假设、观测和改动分开记录。先在隔离环境复现再带着基线和回滚条件逐步验证没有对应数据时只把结论当作排查方向。