3. 索引选择变更场景1：数据库分片键变更导致调度索引失效

在分布式数据库架构中，分片键（Sharding Key）是数据路由的核心依据。调度平台通常依赖分片键构建的索引来快速定位任务实例、执行记录或状态数据。当业务增长或数据重分布触发分片键变更时，原有索引结构可能失效，导致调度任务查询超时、数据倾斜甚至任务中断。本节深入分析该场景的根因、影响链路与自动回滚策略。

3.1 场景定义与根因分析

分片键变更通常发生在以下情况：

• 数据重分布：因数据量增长，原有分片策略（如按用户ID哈希）需要调整为更细粒度（如按用户ID+时间戳复合分片）。
• 分片扩容：从4个分片扩展到8个分片，路由规则改变导致旧索引失效。
• 分片键字段修改：业务重构导致分片键从order_id变更为user_id，调度表索引未同步更新。

3.2 失效链路与影响评估

下表展示了分片键变更前后调度索引的查询行为对比：

影响评估指标：

• 查询延迟：从 < 5ms 增加到 > 2000ms（8分片场景）。
• 调度吞吐量：因查询阻塞，任务调度速率下降 60% 以上。
• 任务超时率：超过调度心跳间隔（通常30s）的任务占比从 0.1% 上升到 15%。

3.3 自动检测与回滚流程

CI/CD流水线中集成调度索引变更检测与自动回滚机制，核心步骤包括：

1. 预变更基线采集：在分片键变更前，采集调度表索引使用统计（如 SHOW INDEX FROM t_task_instance）和典型查询执行计划。
2. 灰度验证：在1个分片上执行索引变更，监控查询延迟和错误率。
3. 全量变更：若灰度通过，逐步应用到所有分片。
4. 持续监控：变更后持续采集执行计划，对比基线。
5. 自动回滚触发：当检测到以下任一条件时，自动执行回滚脚本：
   • 查询延迟超过基线 3 倍。
   • 任务超时率超过 5%。
   • 调度队列积压超过 1000 条。

-- 回滚索引变更
ALTER TABLE t_task_instance 
DROP INDEX idx_user_status,
ADD INDEX idx_order_status (order_id, status);

-- 刷新分片路由规则
CALL refresh_sharding_rule('order_id');

-- 验证回滚后索引生效
EXPLAIN SELECT * FROM t_task_instance 
WHERE order_id = 12345 AND status = 'RUNNING';

3.4 架构示意图：分片键变更前后索引路由对比

下图展示了分片键从 order_id 变更为 user_id 后，调度查询从精确路由退化为全分片广播的过程：

3.5 自动回滚决策树

CI/CD流水线中集成以下决策逻辑，确保回滚操作安全可控：

3.6 最佳实践与避坑指南

3.7 小结