分区剪枝依赖优化器静态推导WHERE条件与分区键的匹配关系，需避免函数、子查询等动态表达式，以EXPLaiN PARTITION的partitions列为唯一验证依据，且不同mysql版本对分区类型的支持差异显著。
WHERE 条件必须能静态推导出分区范围
分区剪枝不是靠运行时扫描判断的，而是优化器在生成执行计划前，根据 WHERE 子句里的值和分区定义做静态推理。如果条件含函数、子查询、用户变量或列间比较（如 dt > create_time），就大概率失效。
常见错误现象：EXPLAIN PARTITION 显示所有分区都出现在 partitions 列里，哪怕你只查一天的数据。
- ✅ 有效写法：
WHERE dt = '2024-01-01'、WHERE dt BETWEEN '2024-01-01' AND '2024-01-05' - ❌ 无效写法：
WHERE date(dt) = '2024-01-01'（DATE()阻断了分区推导）、WHERE dt > NOW() - INTERVAL 7 DAY（NOW()是运行时函数） - ⚠️ 特殊注意：
WHERE dt IN ('2024-01-01', '2024-01-02')在 MySQL 8.0+ 支持剪枝，但 5.7 对多值IN推导较弱，建议拆成OR或用范围
分区键必须是 WHERE 中独立出现的等值或范围操作数
即使你用了分区字段，如果它被包裹在表达式里，或者和其它列做了组合条件而没单独约束，剪枝也会跳过。
使用场景：按日期分区的表，想查某天数据，但 WHERE 里同时写了 dt = ? AND status = ? —— 只要 dt 是明确值，剪枝仍生效；但如果写成 WHERE status = ? AND dt = ?，顺序无关，关键还是 dt 是否有确定值。
- ✅ 有效：
WHERE dt = '2024-01-01' AND user_id % 10 = 3（dt独立确定） - ❌ 无效：
WHERE YEAR(dt) = 2024 AND MONTH(dt) = 1（YEAR()/MONTH()拆解破坏了原始分区键语义） - ⚠️ 复合分区（如
RANGE COLUMNS(dt, id)）要求WHERE必须从左到右连续提供等值条件，缺一不可；只写dt = '2024-01-01'不够，必须补上id的约束才能剪枝
EXPLAIN PARTITION 的 partitions 列才是唯一可信依据
别信表名、分区名、或者“看起来应该走剪枝”的直觉。EXPLAIN PARTITION 输出中 partitions 这一列显示了实际参与扫描的分区名，这才是剪枝是否生效的铁证。
性能影响：如果该列列出 1 个分区，基本没问题；列出 32 个，说明全表分区扫描，I/O 和 CPU 开销直接翻几十倍。
- 执行命令：
EXPLAIN PARTITION select * FROM t_log WHERE dt = '2024-01-01'; - 看输出：
partitions: p20240101✅；partitions: p20230101,p20230102,...,p20241231❌ - 注意：
EXPLAIN不加PARTITION关键字，不会显示分区信息，输出和普通表一样，毫无参考价值
MySQL 版本与分区类型对剪枝能力有实质性差异
MySQL 5.7 对 LIST / RANGE 分区的剪枝支持尚可，但对 HASH / KEY 分区几乎不剪枝（除非是等值且分区数为 2 的幂）；到了 8.0，尤其是 8.0.29+，才真正支持 HASH 分区的等值剪枝。
兼容性影响：你在 8.0 上验证有效的写法，迁到 5.7 可能退化成全分区扫描，且无任何警告。
- RANGE/LIST 分区：剪枝能力相对稳定，重点检查
WHERE是否可推导 - HASH/KEY 分区：仅支持等值查询剪枝，且 MySQL 5.7 基本不生效，8.0.29 起才有实用价值
- 注意：
ALTER table ... REORGANIZE PARTITION后，部分旧版本可能临时丢失分区统计信息，导致剪枝失效，需要ANALYZE TABLE
实际调优时，最易被忽略的是复合分区键的连续性要求和 MySQL 小版本间的剪枝能力断层——写 SQL 时以为条件够了，但执行计划根本不认，得靠 EXPLAIN PARTITION 逐条盯死 partitions 列。