MySQL分区未提速反变慢，因分区键与WHERE条件不匹配时需扫描所有分区并增加元数据开销；应通过EXPLAIN PARTITIONS确认分区裁剪，且分区键须为WHERE等值/范围条件一部分、避免函数包裹。
分区表为什么没提速反而变慢了
MySQL 分区本身不自动优化查询，反而可能拖慢——特别是当 PARTITION BY 键和 WHERE 条件不匹配时。比如按 created_at 日期范围分区，但查询只用 user_id 过滤，MySQL 仍需扫描所有分区（ALL PARTITIONS），还多了一层元数据调度开销。
- 确认执行计划是否真的“裁剪”了分区：执行
EXPLAIN PARTITIONS SELECT ...，看partitions列是否只列出少量分区 - 分区键必须是
WHERE中的等值或范围条件的一部分，且最好是联合索引的最左前缀 - 避免在分区键上使用函数，如
WHERE DATE(created_at) = '2024-01-01'会失效；应写成WHERE created_at >= '2024-01-01' AND created_at
RANGE 和 LIST 分区哪个更适合时间类字段
时间类字段（如日志、订单创建时间）首选 RANGE 分区，它天然支持按时间段切分并可动态 ALTER TABLE ... REORGANIZE PARTITION 添加新分区。而 LIST 要求显式枚举每个值，维护成本高，仅适合状态码、地区编码等有限离散值。
-
RANGE示例：PARTITION BY RANGE (TO_DAYS(created_at)) (PARTITION p2023 VALUES LESS THAN (TO_DAYS('2024-01-01')), ...) - 别用
YEAR()或MONTH()函数做分区表达式——它们不可持续，且无法利用索引；TO_DAYS()或直接用DATETIME值更稳妥 - 每个分区数据量建议控制在 500MB–2GB，太大失去裁剪意义，太小则分区元数据开销占比上升
查询带 LIMIT 时分区真的有用吗
不一定。如果 LIMIT 靠前（如 LIMIT 10），而匹配数据分散在多个分区，MySQL 仍需合并各分区结果再排序取前 N，此时分区可能比单表更慢。只有满足“分区裁剪 + 排序字段在分区键或主键中”时，LIMIT 才受益明显。
- 典型高效场景：按
tenant_idHASH 分区 + 查询带WHERE tenant_id = ? ORDER BY id LIMIT 20 - 危险场景：按时间 RANGE 分区 +
WHERE status = 1 ORDER BY created_at DESC LIMIT 10—— 若status无索引，MySQL 可能全分区扫描后堆排序 - 检查
Handler_read_*状态变量：若Handler_read_next远高于Handler_read_rnd_next，说明扫描有序，分区裁剪大概率生效
分区表和普通表共存时的 JOIN 性能陷阱
MySQL 5.7+ 对跨分区表 JOIN 没有特殊优化，若关联字段不是分区键，优化器很可能放弃分区裁剪，退化为全分区嵌套循环。更隐蔽的问题是：分区表与非分区表 JOIN 时，统计信息不一致，可能导致错误的执行计划。
- 强制走分区裁剪的方法：把分区表作为驱动表，并确保 ON 条件包含分区键等值匹配，例如
JOIN orders PARTITION (p2024) ON o.user_id = u.id - 避免在 JOIN 中对分区表字段使用函数或类型转换，如
ON CAST(o.created_at AS DATE) = u.date会禁用裁剪 - 定期运行
ANALYZE TABLE更新分区表统计信息，尤其在大批量导入后——否则优化器可能误判分区选择性
