MySQL 8.0中InnoDB是事务与高并发场景下唯一可行选择；它支持ACID、行级锁、MVCC和崩溃恢复，而MyISAM、MEMORY、ARCHIVE均不支持事务，且MyISAM在8.0已移除系统表支持，ARCHIVE仅适用于只读归档，MEMORY重启即失，关键参数如innodb_buffer_pool_size和innodb_flush_log_at_trx_commit必须正确配置。
MySQL 8.0 中，InnoDB 不是“可选项”，而是事务与并发场景下的事实唯一选择；其他引擎在生产环境基本不具备替代能力。
事务支持是引擎选型的硬门槛
只要业务涉及资金、状态变更、一致性校验（如订单创建、库存扣减、用户积分更新），就必须用 InnoDB。它通过 redo log 和 undo log 实现 ACID，失败事务能自动回滚，不会留下中间态脏数据。
-
MyISAM、MEMORY、ARCHIVE全都不支持事务——COMMIT/ROLLBACK语法会被忽略，START TRANSACTION形同虚设 - 哪怕当前表只做简单计数，一旦未来加个支付回调逻辑，就得重建表：
ALTER TABLE t ENGINE=InnoDB可能锁表数分钟，且外键/全文索引会直接报错 -
SHOW CREATE TABLE输出里没看到ENGINE=InnoDB，说明建表时已被静默降级（比如配置了default-storage-engine=MyISAM但 MySQL 8.0 已不兼容该写法）
高并发写入下，行级锁 + MVCC 是刚需
秒杀下单、实时日志落库、消息队列消费记录等场景，单表每秒写入超 50 次时，MyISAM 的表级锁会让所有读请求排队等待，QPS 断崖式下跌；而 InnoDB 的行级锁配合 MVCC，能支撑千级并发写入不明显阻塞读。
-
MyISAM执行UPDATE时会锁整张表，期间SELECT也被堵住（除非加LOW_PRIORITY，但响应延迟不可控） -
InnoDB默认隔离级别是REPEATABLE READ，快照读不加锁，避免读写互斥；但要注意幻读需靠间隙锁或SELECT ... FOR UPDATE显式控制 -
MEMORY虽快，但仅限临时表：重启丢数据、不支持TEXT/BLOB、受max_heap_table_size限制，超限报错ERROR 1114 (HY000): The table 'xxx' is full
非事务场景也建议默认用 InnoDB
纯静态配置表、地区字典、权限菜单这类“几乎不改”的表，有人想用 MyISAM 图快，但实际收益极小，风险却真实存在。
- MySQL 8.0 的
InnoDB已支持全文索引，SELECT ... MATCH AGAINST性能与MyISAM接近，且支持事务语义 -
ARCHIVE适合归档审计日志——插入快、压缩率高，但不能UPDATE/DELETE，查单条要全表扫描，不适合主业务表 - 混合引擎会增加元数据管理复杂度：MySQL 8.0 数据字典完全基于
InnoDB，MyISAM表无法参与原子 DDL，备份恢复链路也更脆弱
光指定 ENGINE=InnoDB 远不够，必须配关键参数
建表时写 ENGINE=InnoDB 只是起点，没调参等于裸奔：缓存太小导致磁盘 IO 爆表，刷盘策略不对可能丢事务，文件管理不当删大表不释放空间。
-
innodb_buffer_pool_size设为物理内存的 50%–75%，例如 32GB 机器建议innodb_buffer_pool_size = 24G；设太大可能触发 OOM Killer -
innodb_flush_log_at_trx_commit = 1是生产底线，设为2或0时崩溃可能丢失最近 1 秒事务 -
innodb_file_per_table = ON必开，否则所有表数据挤在ibdata1里，删一张 100GB 表，磁盘空间根本回收不了 - 验证是否生效：执行
SHOW ENGINES;看InnoDB行的SUPPORT列是否为DEFAULT或YES；再建测试表并SHOW CREATE TABLE t_test;确认输出含ENGINE=InnoDB
最容易被忽略的是：MySQL 8.0 安装界面勾选了 InnoDB，或配置文件写了 default-storage-engine=InnoDB，不代表你建的每张表都真用了它——旧脚本残留 ENGINE=MyISAM、客户端连接时指定了默认引擎、甚至某些 ORM 自动生成语句带显式引擎声明，都会绕过默认设置。
