mysql 8.0 默认且推荐使用 innodb 引擎，myisam 仅适用于极少数只读+全文检索场景，memory 引擎非持久化、不可用于主从复制；云环境需调优 innodb_buffer_pool_size 等参数以发挥性能。
MySQL 8.0 默认用的是 InnoDB，别乱切引擎
除非你明确知道要什么，否则直接用默认的 InnoDB。MySQL 5.5 之后就已把 InnoDB 设为默认存储引擎，8.0 更是彻底移除了 MyISAM 的系统表支持（比如 mysql.help_topic 这类内部表现在全用 InnoDB）。强行在建表时指定 ENGINE=MyISAM 虽然语法不报错，但会失去事务、行锁、外键等关键能力，且备份恢复、主从一致性都更难兜住。
常见错误现象：mysqldump 备份后还原出数据不一致；主库执行 INSERT ... SELECT，从库复制中断报错 Table definition has changed；并发写入时出现“幻读”或锁表卡死——这些很多根源就是误用了 MyISAM 或混用引擎。
MyISAM 只适合极少数只读+全文检索场景
如果你真有需求，比如：静态词典表、日志归档表（不再更新）、或需要 FULLTEXT 索引且不关心事务（MySQL 5.6+ 的 InnoDB 其实也支持 FULLTEXT，只是分词逻辑略有差异），才考虑 MyISAM。但注意：
-
MyISAM表级锁，哪怕只是插入一行，整张表都不可写 - 崩溃后无法自动恢复，
REPAIR TABLE命令不一定能救回数据 -
mysqldump备份时加--single-transaction对MyISAM无效，必须加--lock-tables，导致备份期间写阻塞 -
云服务器上磁盘 I/O 通常走网络存储（如 AWS EBS、阿里云云盘），
MyISAM的频繁表扫描会放大延迟，不如InnoDB的缓冲池友好
想用 Memory 引擎？先看清它根本不是持久化方案
Memory 引擎常被误当作“高性能缓存”，但它只存在内存里，实例重启、OOM、或 MySQL 崩溃，数据全丢。它没有 WAL、不写磁盘、也不参与 binlog 记录——所以不能用于主从复制，也不能用 mysqlbinlog 恢复。
真正适合它的场景极少：SELECT ... INTO TEMPORARY TABLE 的中间结果集；短生命周期的去重临时表（配合 CREATE TEMPORARY TABLE）；或者某些 OLAP 查询中做快速聚合的“计算暂存”。但一旦涉及任何可靠性要求，比如订单状态缓存、用户会话映射，就绝对不该用 Memory。
云环境特别要注意 InnoDB 的配置调优点
云服务器的内存和磁盘资源弹性高，但默认配置往往偏保守。装完 MySQL 后务必检查这几项：
-
innodb_buffer_pool_size：建议设为物理内存的 50%–75%，云主机若内存 ≥4GB，别低于 2GB -
innodb_log_file_size：默认 48MB 太小，写密集场景建议调到 256–1024MB（需停机修改，且修改前清空ib_logfile*） -
innodb_flush_log_at_trx_commit：云盘延迟波动大，设为2可显著提升吞吐（牺牲最多 1 秒数据），设为1才是真正的 ACID，按业务容忍度选 -
innodb_io_capacity和innodb_io_capacity_max：AWS io2、阿里云 ESSD 等高 IOPS 盘，要对应调高（比如设为 1000/2000），否则 I/O 调度压不住
这些参数不改，InnoDB 在云上跑得再快，也只发挥出本地 SSD 的一半性能。而很多人装完就跑应用，等到慢查询报警才回头翻配置，已经晚了。
