MySQL 8.0 已彻底移除 MyISAM，InnoDB 是唯一合理选择；其事务、行锁、外键、崩溃恢复和 MVCC 是现代应用数据一致性的底线保障，安装后须重点调优 innodb_buffer_pool_size 等参数。
MySQL 8.0 默认只支持 InnoDB，MyISAM 已被移除；5.7 及更早版本虽保留 MyISAM，但生产环境几乎不该选它。
为什么 InnoDB 是唯一合理的选择
除非你维护一个十几年前的遗留系统且明确依赖 MyISAM 的全文索引（FTS）或表级锁行为，否则没有理由跳过 InnoDB。它的事务、行锁、外键、崩溃恢复和 MVCC 支持，是现代 Web 应用数据一致性的底线保障。
常见错误现象：ERROR 1286 (42000): Unknown storage engine 'MyISAM' —— 这在 MySQL 8.0.29+ 安装后首次建表时就可能出现，因为服务端已禁用 myisam 插件（skip_myisam=ON 默认启用）。
- 安装时无需“选择”引擎：只要不显式禁用
innodb（默认开启），它就是唯一可用的通用引擎 -
CREATE TABLE ... ENGINE=MyISAM在 8.0 中直接报错，不是配置问题，是代码层移除 - 如果必须兼容旧脚本，可在 5.7 安装后手动启用
myisam插件，但需承担无事务、易损坏、无法热备等风险
安装时真正该关注的 InnoDB 配置项
引擎不是靠“选”，而是靠调。安装完立刻检查并调整以下几项，否则默认值在多数场景下会拖慢性能甚至引发锁等待：
-
innodb_buffer_pool_size：应设为物理内存的 50%–75%，低于 2GB 内存的机器必须调小，否则启动失败 -
innodb_log_file_size：8.0 默认 48MB，高写入场景建议 256–1024MB；修改前必须停库、删旧日志文件（ib_logfile0/ib_logfile1） -
innodb_flush_log_at_trx_commit=1（默认）保 ACID，但每事务刷盘；若允许短暂丢失（如日志类数据），可设为2提升吞吐 -
innodb_file_per_table=ON（默认）—— 必须保持开启，否则所有表挤进ibdata1，后续无法收缩单表空间
Memory 和 CSV 引擎的适用场景与陷阱
它们不是“替代 InnoDB 的选项”，而是极窄用途的辅助工具，误用会导致数据丢失或不可查：
-
MEMORY引擎数据全在 RAM，重启即空；仅适合临时缓存、SELECT ... INTO TEMPORARY TABLE或高速排序中间结果 -
CSV引擎把表映射成逗号分隔文本，不支持索引、事务、NULL 值处理脆弱；只用于快速导入导出，绝不能用于业务表 - 试图对
MEMORY表加FOREIGN KEY？会报错ERROR 1005 (HY000): Can't create table—— 它根本不支持外键 -
CSV文件被外部程序修改后，MySQL 不会自动感知，SELECT可能读到脏行或报错ERROR 1300 (HY000): Invalid utf8mb4 character string
真正要花时间的不是“选引擎”，而是确认 innodb_buffer_pool_size 是否合理、innodb_log_file_size 是否匹配写入压力、以及是否关闭了 skip_innodb（某些精简版 Docker 镜像会默认关）。其他所谓“选择”，基本是历史包袱或认知偏差。
