MySQL 8.0中报表系统必须用InnoDB，因MyISAM分区功能已被彻底移除，建表直接报ERROR 1031；其无事务、无MVCC、分区裁剪失效、临时表落盘依赖InnoDB，已深度绑定核心能力。
MySQL 8.0 中数据仓库报表系统必须用 InnoDB，不是“更推荐”，而是 MyISAM 已被移除且不可用——CREATE TABLE ... ENGINE=MyISAM PARTITION BY RANGE 会直接报错 ERROR 1031 (HY000): Table storage engine for 't' doesn't support partitioning。
MySQL 8.0 分区表只支持 InnoDB
报表系统常依赖按时间（如 dt、created_at）做 RANGE 分区，而 MySQL 8.0 起已彻底移除 MyISAM 的分区能力。即使你手动指定 ENGINE=MyISAM，建表也会失败；5.7 是最后一个支持版本，但官方早已标记为“不推荐”。实际环境中，MyISAM 分区表在导入或查询时极易触发 ERROR 1031，根本无法稳定运行。
常见错误现象：
- 执行
ALTER TABLE t REORGANIZE PARTITION时崩溃，MyISAM 无事务保障，修复后状态不一致 -
EXPLAIN PARTITIONS显示命中单个分区，但执行时扫描全部.MYD文件——分区裁剪失效 - 主从切换后，MyISAM 分区表的
AUTO_INCREMENT出现跨分区重复 ID，报表去重逻辑直接失效
报表查询中 COUNT(*) 和 WHERE 范围扫描反而更快
有人误以为 MyISAM 的 COUNT(*) “快”对报表有利，这是错觉。MyISAM 的行数缓存仅对**非分区整表**有效；一旦分区，每个分区需单独统计再累加，I/O 开销更大。真实场景中：
-
SELECT COUNT(*) FROM sales WHERE dt BETWEEN '2026-01-01' AND '2026-06-30'：InnoDB 可利用分区裁剪 + 主键/索引覆盖快速遍历，实测比 MyISAM 分区快 2–3 倍 - MyISAM 没有 MVCC，长查询期间遇到写入会触发全表锁，报表任务卡住，监控显示大量
Waiting for table level lock - InnoDB 的
Buffer Pool同时缓存数据页和索引页，热分区反复访问时基本不碰磁盘；MyISAM 的key_buffer_size只缓存索引，每次查数据都得读.MYD，iowait 暴涨
临时表落盘默认走 InnoDB，绕不开它
报表 SQL 常含 GROUP BY、ORDER BY、DISTINCT 等操作，触发内隐临时表。MySQL 8.0.16+ 默认使用 TempTable 引擎，内存超 temptable_max_ram（默认 1GB）后，会按页落盘——落盘引擎由 internal_tmp_disk_storage_engine 控制，**默认且唯一可靠选项是 InnoDB**。
为什么不用 MyISAM？
- MySQL 5.7 及以前曾用 MyISAM 作磁盘临时表，但因崩溃易损、无事务、修复慢，8.0+ 彻底弃用
- InnoDB 落盘临时表能复用已有
redo log和崩溃恢复机制，异常重启后自动清理，无需人工干预 - 盲目调大
tmp_table_size不解决问题，只会掩盖 SQL 缺索引或聚合逻辑低效的本质
真正容易被忽略的是：报表系统看似“只读”，但背后大量依赖临时表、分区裁剪、并发查询调度——这些能力在 MySQL 8.0 中已与 InnoDB 深度绑定，不是选不选的问题，而是没得选。
