在 MySQL 8.0 及以上版本中，分区表必须使用 InnoDB 存储引擎，MyISAM 分区功能已经移除且稳定性不足；MySQL 5.7 虽然是最后一个支持 MyISAM 分区的版本，但官方早已不建议继续使用，实际部署中也很容易触发 ERROR 1031。因此，从兼容性、稳定性和官方支持角度来看，InnoDB 才是 MySQL 分区表唯一完整可用的选择。
分区表必须用 InnoDB，MyISAM 分区已废弃且不可靠
从 MySQL 8.0 开始，MyISAM 分区能力已被正式移除；而 MySQL 5.7 作为最后一个支持 MyISAM 分区的版本，也已经被明确标注为“不推荐使用”。在实际应用过程中，这类方案还非常容易触发 ERROR 1031 (HY000): Table storage engine for 't' doesn't support partitioning 错误。当前，InnoDB 是 MySQL 官方唯一完整支持、持续维护并适合生产环境的分区引擎。
为什么 MyISAM 分区在生产环境根本走不通
即便你在较早版本（例如 MySQL 5.6）中勉强创建了 MyISAM 分区表，底层设计上的问题也会很快暴露出来，几乎不适合线上业务场景：
- 崩溃后无法自动恢复：当分区表损坏时，
REPAIR TABLE往往只能修复某一个分区，其他分区仍可能保持 inconsistent 状态，后续排障和人工恢复成本非常高 - 并发写入会直接锁整表：即使只是更新单个分区，MyISAM 依旧采用表级锁，导致其他分区上的读写操作也一并被阻塞
- 分区裁剪存在失效风险：MyISAM 的分区元数据缓存机制较为松散，虽然
EXPLAIN PARTITIONS可能显示已命中目标分区，但实际执行时仍可能扫描全部 .MYD 文件 - 缺乏事务支持：在
INSERT ... SELECT这类跨分区写入过程中，一旦中途失败，已写入的数据无法回滚，容易留下脏数据和不一致状态
InnoDB 分区的关键实操要点
InnoDB 分区并不是“开箱即用”的性能优化万能方案，只有结合合理的表结构设计和业务场景，才能真正发挥 MySQL 分区表的价值：
- 分区键必须包含在主键或唯一索引中，否则创建分区表时会直接报错
ERROR 1064 (42000): Constant, random or timezone-dependent expressions in partitioning function are not allowed - RANGE/LIST 分区更适合按时间字段（如
created_at）或业务状态（如status）进行归档管理；HASH/KEY 分区在高并发写入场景下要谨慎使用，因为可能引发热点分区和锁竞争问题 - 每个分区本质上仍是独立的 B+ 树结构，但会共享同一个 Buffer Pool；如果单个分区过大（例如超过 10GB），往往会进一步加重 buffer pool 压力，因此通常建议将单分区大小控制在 1–5GB
ALTER TABLE ... REORGANIZE PARTITION这类操作通常会锁住整张表，生产环境执行前必须提前评估维护窗口和业务影响
别被 COUNT(*) 误导：MyISAM 的“快”在分区场景下并不存在
有些人会误以为 MyISAM 分区表在执行 COUNT(*) 时更有优势，但实际情况并非如此。MyISAM 的元数据计数优化仅适用于**完整的未分区表**。一旦启用分区，每个分区都需要分别统计再汇总，整体 I/O 成本反而可能高于 InnoDB 通过索引进行快速遍历的方案。在真实压测中，对于 InnoDB 分区表，在 COUNT(*) WHERE dt BETWEEN '2026-01-01' AND '2026-06-30' 这类查询场景下，借助分区裁剪与索引覆盖，其性能通常会优于 MyISAM 分区表。
另外一个常被忽视的重点是：InnoDB 分区表中的 auto_increment 值在跨分区插入时依然保持全局唯一，而 MyISAM 分区历史上曾出现不同分区生成重复 ID 的 bug，尤其在主从切换之后更容易暴露。这个问题在 2025 年多起生产环境事故报告中被反复提及，也进一步说明 MySQL 分区表选择 InnoDB 才是更稳妥、更符合生产标准的方案。
