分表前必须确认分区键被查询条件直接引用，否则分区裁剪失效；如用to_days(create_time)分区，where date_format(create_time,'%y-%m')='2024-01'将全扫分区，正确写法是where create_time>='2024-01-01' and create_time
分表前必须确认分区键是否被查询条件直接引用
分区裁剪（partition pruning）不会自动生效。如果你的归档表建了 PARTITION BY RANGE (TO_DAYS(create_time))，但查询写成 WHERE DATE_FORMAT(create_time, '%Y-%m') = '2024-01'，MySQL 就会扫描所有分区——partitions: NULL 出现在 EXPLAIN PARTITIONS 结果里就是最直接的信号。
真正能触发裁剪的写法只有这些：
WHERE create_time >= '2024-01-01' AND create_timeWHERE create_time BETWEEN '2024-01-01' AND '2024-01-31'WHERE create_time = '2024-01-15'
任何对 create_time 做函数包裹、类型转换或隐式转换的操作，都会让分区失效。别信“看起来一样”，得看执行计划里 partitions 列具体写了哪些分区名。
用 TO_DAYS() 建 RANGE 分区时边界值必须对齐自然月首日
错误示范：LESS THAN (TO_DAYS('2024-01')) 会直接报错，因为 '2024-01' 不是合法日期字面量；LESS THAN (TO_DAYS('2024-01-31')) 看似合理，实则导致 2024-02-01 这天数据落到下一个分区，破坏时间连续性。
正确做法是统一用每月第一天作为分区上限：
-
PARTITION p_202401 VALUES LESS THAN (TO_DAYS('2024-02-01'))→ 存 2024-01-01 至 2024-01-31 -
PARTITION p_202402 VALUES LESS THAN (TO_DAYS('2024-03-01'))→ 存 2024-02-01 至 2024-02-29 - 末尾必须有
PARTITION p_future VALUES LESS THAN MAXVALUE，否则插入未来日期会报ERROR 1526 (HY000)
别用 UNIX_TIMESTAMP()：夏令时切换那两天，同一时间戳可能映射到不同日期，TO_DAYS() 是纯日期计算，更稳。
主键或唯一索引必须包含分区键
MySQL 5.7+ 强制要求：如果表用了分区，所有唯一约束（包括主键）都必须显式包含分区列。否则建表失败，或低版本虽能建但查询行为不可靠。
比如归档表按 create_time 分区，就不能只写 PRIMARY KEY (id)。正确写法是：
CREATE TABLE order_archive ( id BIGINT NOT NULL, create_time DATE NOT NULL, ... PRIMARY KEY (id, create_time) -- 必须联合 ) PARTITION BY RANGE (TO_DAYS(create_time)) (...);
这个限制不是为了刁难你，而是保证每个分区内的主键值唯一——否则跨分区查 id=123 时，优化器无法确定该去哪个分区找。
查询归档表时避免 UNION ALL 手动拼接
有些方案教你在应用层判断时间段、生成多个 SELECT ... FROM order_archive_202401 UNION ALL SELECT ... FROM order_archive_202402，这等于放弃分区表的核心优势：自动路由和元数据感知。
真要跨月查，就用单条 SQL + 正确 WHERE 条件，让 MySQL 自己决定扫哪几个分区。手动 UNION 的坏处很明显：
- 每次增删分区都要改代码或配置
- 无法利用
EXPLAIN PARTITIONS验证实际扫描范围 - 丢失分区级统计信息，优化器可能选错执行计划
- 事务一致性变差：多个独立查询之间存在时间窗口
复杂查询（如带 GROUP BY、ORDER BY LIMIT）在分区表上也能跑，只要 WHERE 条件干净，就别自己拆。
最容易被忽略的一点：分区表不是一劳永逸。新分区要提前建好，p_future 不能长期占位；旧分区定期 ALTER TABLE ... DROP PARTITION 或 TRUNCATE PARTITION，而不是靠 DELETE；所有变更必须在业务低峰期做，且先在从库验证执行计划。
