EXPLAIN SELECT id FROM t_order WHERE user_id = 88123; -- 输出按 ds_00 到 ds_15 分段 逐段检查 type
同一条查询在分片环境下 explain 输出 16 段，每段的目标库不同，开发只看第一段，以为走了索引，实际有 9 个片在扫全表。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：中间件把 explain 按片展开，每片的统计信息和索引选择可能不同。只看第一段代表不了整体，慢的往往是数据量最大的那个片。
「分片执行计划」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
处理上按这个顺序：把 explain 结果按片收集 逐段看 type 和 rows；按 rows 排序 先处理最大的那个片；片间数据量差异大时 单独 analyze table；把每片执行计划接进巡检 出现 ALL 就告警。
确认没问题再收工，16 段执行计划的 type 都是 ref 没有一段是 ALL。