mysql表分区不是银弹，需匹配访问模式：分区键必须高频出现在查询条件中以触发分区裁剪，优先选时间等确定性列；按场景选range/list/hash分区类型；单表分区数建议12～60个，单分区行数宜控制在100万～500万。
MySQL 表分区不是“开箱即用就能提速”的银弹，它对性能的影响取决于设计是否匹配实际访问模式。用得好能显著减少 I/O、加速范围查询、简化归档；用得不当反而增加开销、拖慢查询、甚至引发锁争用或元数据瓶颈。
分区键选择直接决定性能上限
分区键是整个分区逻辑的锚点，选错会导致所有优化失效。
- 必须是查询条件中高频出现的列，且最好能被 MySQL 优化器用于 分区裁剪（Partition Pruning）——即跳过无关分区。例如按
order_date分区后，WHERE order_date BETWEEN '2025-01-01' AND '2025-03-31'能精准定位到 3 个分区，而WHERE status = 'shipped'若未包含在分区键中，则可能需扫描全部分区。 - 避免使用非确定性函数（如
NOW()、UUID()）或频繁更新的列作为分区键，否则会破坏数据分布稳定性，影响写入和维护。 - 复合分区键不被原生支持，若需多列参与裁剪，应确保主查询条件能覆盖最左前缀，或改用子分区（如 RANGE-HASH）配合使用。
分区类型要匹配业务数据特征
不同分区方式适用于不同场景，强行套用会适得其反。
-
范围分区（RANGE）适合时间序列或数值连续场景，如日志表按天/月分区、订单表按年份分区。优势在于天然支持范围查询和快速删除过期分区（
DROP PARTITION），但需持续维护新分区（如每月新增），否则插入会失败。 -
列表分区（LIST）适用于离散枚举值，如按
region_code或status_group划分。查询效率高，但新增值需手动扩展分区定义，灵活性较低。 - 哈希/键分区（HASH / KEY）可均匀分散数据，缓解热点写入，但不支持范围查询裁剪。仅适用于等值查询为主、且无时间维度管理需求的场景（如用户ID哈希分片）。KEY 分区自动使用主键哈希，更省心但约束更强。
分区数量并非越多越好
分区数过多会抬高元数据开销、降低单次查询调度效率，甚至触发 MySQL 的内部限制。
- MySQL 5.7 默认最大分区数为 8192，但实际建议控制在几十个以内（如 12～60 个），尤其当使用 MyISAM 或低配硬件时。InnoDB 对大量分区的支持更稳健，但仍需测试验证。
- 每个分区对应独立的 .ibd 文件和索引结构，分区数翻倍意味着文件句柄、内存缓存、锁管理对象同步增长。监控
SHOW OPEN TABLES和innodb_open_files配置是否足够。 - 小分区（如按天分 365 个）易造成碎片化和管理负担；过大分区（如单个分区含千万级记录）则失去分区意义。理想单分区行数建议在 100 万～500 万之间，视查询频次与 SSD 随机读能力而定。
查询写入与维护行为受分区显著影响
分区改变的不只是存储结构，更是 SQL 执行路径和 DBA 日常操作逻辑。
- 写入性能：范围或列表分区下，INSERT 依赖分区键值路由，基本无额外开销；但哈希分区因计算与冲突处理，可能略低于普通表。大批量导入时，关闭唯一性检查、禁用自动提交、按分区批量写入可提升吞吐。
- 查询性能：只有能触发分区裁剪的查询才受益。EXPLAIN 输出中需看到
partitions: p202501,p202502，而非partitions: p202501,p202502,...,p202612全部列出。JOIN 涉及分区表时，若关联字段非分区键，可能无法裁剪，应考虑冗余分区键或改用冗余字段+索引。 - 维护操作：
ALTER TABLE ... REORGANIZE PARTITION可在线重分布数据；TRUNCATE PARTITION比 DELETE 快得多；备份可按分区粒度进行，但 mysqldump 默认导出全表，需配合--where或 Percona XtraBackup 的分区级选项。
