联合索引列序：等值 + IN + 范围 + ORDER BY 混用时，MySQL 优化器到底怎么选列？有没有可复现的判定规则？

【背景】 做了 15 年 DBA，联合索引的列序设计几乎天天碰。社区里"加索引 vs 改 SQL"的取舍（id=1581 的讨论、id=19 的三件套文章）我已经看过了，方向没有分歧。但我想把问题再聚焦一层：不是"加不加"，而是"列怎么排"。

具体场景：一张 3200 万行的 t_delivery 表，业务方给的典型查询长这样——

SELECT tracking_no, carrier, delivery_time
FROM t_delivery
WHERE warehouse_id = 1024          -- 等值
  AND status IN (3, 5, 7)          -- IN（3 个值）
  AND created_at > '2025-10-01'    -- 范围
ORDER BY delivery_time DESC
LIMIT 50;

候选索引方案至少有三种：

• A: (warehouse_id, status, created_at, delivery_time) —— 教科书"等值→IN→范围→排序"
• B: (warehouse_id, delivery_time, status, created_at) —— 把 ORDER BY 提到范围前面，赌它能免 filesort
• C: (warehouse_id, status, delivery_time) —— 砍掉 created_at，靠 delivery_time 排序 + 回表后再过滤

EXPLAIN 结果：A 走 index range scan 但 filesort（rows≈180万）；B 走 range + 有序扫描但 status 过滤变成回表后 filter（rows≈210万）；C 介于两者之间。三种方案 P99 实测分别是 420ms / 310ms / 380ms，差距不大，但不同数据分布下排序会翻。

【现象 / 卡点】

1. 我按"等值→IN→范围→排序"的教科书顺序建了方案 A，上线后 P99 反而比方案 B 高 35%。用 EXPLAIN FORMAT=JSON 看，优化器把 IN 当"3 个等值"展开后，范围列 created_at 确实被用上了，但 delivery_time 的排序走的是 filesort——因为范围列后面接的列不能用于排序。
2. 我换成方案 B 后，delivery_time 能走索引有序扫描，免了 filesort，但 status IN (3,5,7) 变成了回表后的 filter，多读了约 30% 的行。
3. 最诡异的是：当 IN 的值从 3 个变成 1 个（变成纯等值），方案 A 和 B 的优劣会反转——A 反而更快。我试了 IN (3) 时 A=280ms、B=340ms。

核心疑问：IN 到底算"等值"还是"范围"？这个分类在 MySQL 8.0 优化器里是硬编码的还是动态的？有没有一个可复现的判定规则，让我在建索引前就能预测优化器会怎么选列、会不会 filesort？

【已尝试的排查与结果】

• EXPLAIN FORMAT=JSON：能看到 attached_condition 里哪些列被推到索引扫描、哪些留在 filter，但没有直接告诉我"为什么 IN 在这里被当等值 / 在那里被当范围"。
• optimizer_trace（SET optimizer_trace="enabled=on"）：能看到 considered_execution_plans 里的 range_analysis，IN 的展开确实生成了 3 个独立的 range，每个 range 内部 created_at 是有效的范围扫描。但 trace 里没有显式标注"此列被归类为 equality"还是"此列被归类为 range"。
• 实际压测（sysbench 模拟 50 并发）：三种方案在 IN(1值) / IN(3值) / IN(10值) 下的 P99 曲线我画出来了，IN 值数量是翻转点，但翻转阈值不稳定，跟 warehouse_id 的数据倾斜有关。
• 社区里 id=452（4500 万行表索引从 5 涨到 17）和 id=1579（change buffer 命中率）我都读了，写放大的账我会算，但列序选择这一步还是靠试。

【期望得到的答案形态】 不要求"万能公式"，但希望至少能覆盖：

1. MySQL 8.0 优化器对 IN 的分类逻辑：是"IN 展开后每个值都是等值，所以 IN 列永远算等值"还是"IN 的展开结果取决于值数量和基数，优化器可能把它当 range"？有没有 optimizer_trace 里的字段能直接确认？
2. 一个可复现的列序判定流程：给定 WHERE 里的等值 / IN / 范围 / ORDER BY 组合，怎么一步步推出"哪些列放前面能让优化器既走索引范围扫描又免 filesort"？最好能给出 2~3 个 counter-example（教科书规则失效的场景）。
3. IN 值数量作为"翻转阈值"的量化方法：有没有办法从 INFORMATION_SCHEMA.STATISTICS 或 performance_schema.table_io_waits_summary_by_index_usage 里拿到一个数字，让我在建索引前就能判断"这个 IN(3) 在你的数据分布下到底算等值还是范围"？
4. 如果列序确实无法同时满足范围扫描 + 免排序，方案 B（牺牲部分行读取换免 filesort）和方案 A（牺牲排序换精确范围）的 P99 差距在什么条件下会超过 2×？ 有没有一个基于 rows_examined/rows_returned 比值的经验阈值？

我倾向方案 B（因为免 filesort 对 3200 万行表是硬收益），但 IN 值数量不稳定让我没法拍板。如果你有过类似"列序翻转"的实战案例，欢迎贴你的 EXPLAIN 对比。