disabled_storage_engines=myisam是mysql 5.7.8起唯一生效的硬性禁用机制，必须写在[mysqld]段且大小写敏感；它使myisam引擎无法初始化，显式建表会报错3161，但mysql_upgrade升级时需临时注释该配置。
disabled_storage_engines=MyISAM 是唯一真正生效的配置
MySQL 5.7.8 起，disabled_storage_engines 是唯一能从启动时硬性拦截 MyISAM 表创建的官方机制。它不是“关闭”或“跳过”，而是让引擎根本无法初始化——连 SHOW ENGINES 都查不到 MyISAM 行（Support 列为空或直接不显示）。
必须写在 [mysqld] 段下，且大小写敏感：disabled_storage_engines=MyISAM；写成 myisam 或 disable_storage_engine 都无效。
旧方案如 skip-myisam 在 MySQL 5.7.29+ 已废弃，加了只会报 warning 并被忽略。
禁用后哪些操作会立即失败
所有显式指定 ENGINE 的 DDL 语句会直接报错，错误码统一为 3161：
CREATE TABLE t1 (...) ENGINE=MyISAMALTER TABLE t2 ENGINE=MyISAMCREATE TEMPORARY TABLE tmp (...) ENGINE=MyISAM
注意：SHOW ENGINES 里 MyISAM 仍可能显示为 YES，这是状态残留，不能作为判断依据；真正生效标志是建表报错 3161。
mysql_upgrade 升级时卡住怎么办
升级脚本内部可能尝试重建历史兼容表，触发 [ERROR] 3161: Storage engine MyISAM is disabled。这不是数据问题，只是流程卡在非必要步骤：
- 临时注释掉
disabled_storage_engines=MyISAM - 重启 mysqld
- 执行
mysql_upgrade - 还原配置，再次重启
整个过程只需短暂停机，日常运行中该参数完全静默，不影响主从复制或业务查询。
真正难排查的是没报错但行为异常的场景
禁用后最隐蔽的问题来自隐式依赖：
- 存储过程或触发器里
CREATE TEMPORARY TABLE没写ENGINE=InnoDB，默认引擎变成 InnoDB 后，事务可见性、锁粒度、自动清理时机都变了 - 监控脚本硬编码
ENGINE='MyISAM'条件，导致information_schema.TABLES查询漏匹配 - 老版本
mysqldump加了--skip-create-options，还原时拼出 MyISAM 语句而失败
这些不会立刻报错，但可能在某次高峰或事务并发时暴露逻辑偏差——必须结合业务路径做回归验证，尤其关注临时表、全文索引、AUTO_INCREMENT 插入行为等细节。
