数据库索引优化与慢查询分析开发短记：上线前把 DDL 的影响范围写清

数据库索引优化与慢查询分析开发短记上线前把 DDL 的影响范围写清给大表加索引时查询语句只是起点DDL 的执行方式才决定发布风险。不同数据库版本和存储引擎对在线建索引的锁定范围不同即便元数据锁很短也可能被长事务拖住。因此发布前先列出表大小、写入速率、最长事务、复制拓扑和磁盘余量。演练环境需要接近实际表结构和索引基数。建索引过程中记录 DDL 阶段、锁等待、复制延迟、磁盘临时空间与写入耗时。若使用在线变更工具还要明确触发器、校验任务和切换条件避免工具结束后才发现数据校验没有跑完。上线窗口内先检查是否存在长事务或未结束的批处理再对一小部分实例执行。观察点包括 DDL 进度、连接数、事务等待、主从延迟以及相关接口的超时率。警戒条件应由值班同学在变更前确认而不是等告警后再讨论。回退也不能只写“删除索引”。若 DDL 已进入耗时阶段直接中止可能留下额外负担要写清停止新批次、保留现场信息、与 DBA 协同处理的步骤。索引上线的目标是获得可验证的访问路径同时维持可控的数据库运行状态。变更结束后将实际耗时和计划中的估计并列记录。下次同类表变更可参考这份记录但仍要重新核对表规模、事务形态与当前版本不把一次演练直接套用。若表上已有功能索引或外键评审时同时列出依赖关系。它们可能改变 DDL 的执行路径也影响回滚是否需要额外操作。对业务方而言提前知道写入窗口和可能的延迟比看到一份事后报告更有用。变更负责人、DBA 和应用值班人应使用同一份状态页出现锁等待时由负责人决定停止、等待还是切换不在群聊中临时分工。如需跨多个分片执行按固定顺序推进并记录每个分片结果避免失败后无法判断哪些节点已经完成。