分区表仅在查询精准命中单个分区且数据量远小于全表时才能减轻io压力；否则可能因扫描多分区和元数据开销反而增加io。
分区表真能减轻IO压力？先看实际效果
不能一概而论。只有当查询能精准命中单个分区（即使用分区键做等值或范围过滤），且该分区数据量远小于全表时，IO才明显下降。否则，mysql仍可能扫描多个甚至全部分区文件，IO压力反而因元数据开销略增。
常见错误现象：EXPLAIN PARTITIONS 显示 partitions: p0,p1,p2,p3，但业务查询只查某天数据——说明没走对分区键，或分区键设计与查询模式不匹配。
- 必须用分区键字段参与
WHERE条件，且不能被函数包裹（如WHERE date(created_at) = '2024-01-01'会失效） - 范围查询比等值查询更容易跨分区，
WHERE created_at BETWEEN '2024-01-01' AND '2024-01-05'若跨月分区，可能扫3个分区 - 唯一索引/主键必须包含分区键，否则建表失败：
Error 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning function
按时间分区时，RANGE COLUMNS 比 RANGE 更稳
RANGE 只支持单列数值表达式（如 YEAR(created_at)），但隐式类型转换易出错；RANGE COLUMNS 直接拿日期列本身分区，语义清晰、无转换风险，也支持多列组合（虽时间场景一般不用）。
使用场景：日志表按天/月归档，需长期保留且查询集中在最近N天。
- 推荐写法：
PARTITION BY RANGE COLUMNS(created_at) (PARTITION p202401 VALUES less THAN ('2024-02-01'), ...) - 避免写法：
PARTITION BY RANGE (TO_DAYS(created_at))——TO_DAYS返回整数，但容易因时区或NULL值导致分区边界错位 - 注意：分区字段必须是索引的一部分（哪怕只是二级索引），否则无法剪枝
分区文件物理分布不可控，别指望“把热分区放SSD”
MySQL 的分区只是逻辑切分，所有分区数据文件（.ibd）默认落在同一 datadir 下，共用同一个 InnoDB 表空间配置。你无法单独指定某个分区存到不同磁盘路径。
性能影响：即使做了分区，如果高并发查询分散在不同分区，依然会争抢 buffer pool 和 IO 队列；冷热分区混在一起，预读和缓存效率反而下降。
- 真正能分离存储的方案是
TABLESPACE+DATA Directory，但仅限 MySQL 8.0.23+ 且需启用innodb_file_per_table=ON和innodb_directories - 示例（不推荐日常用）：
CREATE TABLESPACE ts_p202401 ADD DATAFILE 'ts_p202401.ibd' ENGINE=INNODB;再建分区时指定TABLESPACE = ts_p202401 - 多数情况下，不如用归档表（
ALTER TABLE ... RENAME）+ 应用层路由更可控
ALTER TABLE ... REORGANIZE PARTITION 是最常踩的坑
想合并旧分区或调整边界？别直接 DROP + ADD，那会锁全表。用 REORGANIZE 看似安全，但实际会重建涉及的分区数据——IO峰值可能翻倍，且期间该分区不可写。
容易被忽略的地方：
-
REORGANIZE要求源分区必须连续（如p202301,p202302,p202303），跳一个就报错：ERROR 1496 (HY000): Cannot reorganize a partition without knowing its exact definition - 操作前务必确认
innodb_buffer_pool_size足够，否则大量脏页刷盘拖慢整个实例 - 线上环境建议配合
pt-online-schema-change或选低峰期，不要信“只是改元数据”
分区不是银弹，IO瓶颈若来自随机写放大、buffer pool 不足或慢查询未走索引，加分区只会让问题更隐蔽。