innodb是mysql 8.0事务与高并发场景下事实唯一选择；myisam虽show engines显示支持，但系统表已禁用、无事务语义、不支持外键及原子ddl，生产环境不可用。
InnoDB 不是“可选项”，而是 MySQL 8.0 中事务与并发场景下的事实唯一选择；其他引擎在生产环境基本不具备替代能力。
为什么 SHOW ENGINES 显示 MyISAM 支持，但实际不能用？
MySQL 8.0 仍保留 MyISAM 的加载能力（SUPPORT = YES），但已移除对其系统表（如 mysql.user）的支持。这意味着：
- 你仍能执行
CREATE TABLE t ENGINE=MyISAM，但无法用它替换核心系统表 -
ALTER TABLE mysql.user ENGINE=MyISAM会直接报错：ERROR 1785 (HY000): Statement violates GTID consistency - 即使建成功，遇到
START TRANSACTION或COMMIT时，语义被静默忽略——事务根本不存在 -
SHOW CREATE TABLE输出里没看到ENGINE=InnoDB，大概率是建表时被配置项（如旧版default-storage-engine=MyISAM）降级，而 MySQL 8.0 已不兼容该写法，降级行为可能失败或不可靠
什么时候必须强制用 InnoDB？
只要业务逻辑中存在以下任一场景，就必须用 InnoDB：
- 涉及资金、状态变更、一致性校验的操作，例如：
INSERT INTO orders后要扣库存，或用户积分更新后需发通知 - 需要原子性保障的复合操作，比如用
SELECT ... FOR UPDATE加锁再更新，MyISAM 完全不支持该语法 - 表未来可能加外键约束——
InnoDB是 MySQL 8.0 中唯一支持外键的引擎 - 使用窗口函数、CTE 或原子 DDL（如
ALTER TABLE ... RENAME COLUMN）时，这些功能依赖数据字典统一基于InnoDB实现
非事务场景下，还能选 MEMORY 或 ARCHIVE 吗？
可以，但必须清楚代价和边界：
-
MEMORY表只适合临时中间计算，重启即丢数据；且不支持TEXT/BLOB类型，超max_heap_table_size会报 ERROR 1114 (HY000): The table 'xxx' is full -
ARCHIVE仅适用于归档审计日志类只读场景：插入快、压缩率高，但不支持UPDATE/DELETE，查单条记录需全表扫描，QPS 极低 - 所谓“纯静态字典表”（如地区、菜单）用 MyISAM 图快，实际收益微乎其微：InnoDB 的缓冲池（
innodb_buffer_pool_size）缓存热数据后，读性能差距几乎不可测；而一旦某天要加个UPDATE status操作，就得停服重建表
光指定 ENGINE=InnoDB 远不够，关键参数必须配对
建表写 ENGINE=InnoDB 只是起点，真正影响事务安全与并发表现的是运行时参数：
-
innodb_buffer_pool_size应设为物理内存的 50%–75%，过小会导致频繁磁盘 IO；过大会挤压 OS 缓存，反而拖慢备份等后台任务 -
innodb_flush_log_at_trx_commit=1（默认）保证每次事务都刷 redo log 到磁盘，崩溃不丢数据；设为 2 或 0 虽提升吞吐，但可能丢失最多 1 秒事务——金融类业务严禁调低 -
innodb_lock_wait_timeout默认 50 秒，高并发下死锁等待太久会拖垮应用线程池；建议按业务链路超时时间反推设置（如接口超时 3 秒，则设为 2）
最常被忽略的一点：混合引擎部署会让备份恢复链路脆弱——MySQL 8.0 数据字典完全基于 InnoDB，MyISAM 表无法参与原子 DDL，mysqldump --single-transaction 对它无效，必须额外加 --lock-all-tables，导致备份窗口变长、主从延迟风险上升。
