mysql 5.7.28+ 可通过配置 disabled_storage_engines="myisam" 全局禁用 myisam 引擎，需写入 my.cnf 的 [mysqld] 段并重启生效；之后 create table ... engine=myisam 将报错，但 create table ... select 等特定场景仍可能绕过限制。
MySQL 5.7+ 如何全局禁用 MyISAM 引擎
MySQL 本身不提供「禁止某引擎」的开关，但可以通过 disabled_storage_engines 配置项阻止 MyISAM 被加载——这是最接近“禁止”的有效手段。
该配置仅在 MySQL 5.7.28+ 和 8.0.19+ 生效，旧版本不支持，强行写入会启动失败。
- 必须在
my.cnf（或my.ini）的[mysqld]段落下添加：disabled_storage_engines = "MyISAM"
- 值是字符串，引号必需，多个引擎用逗号分隔，如：
"MyISAM,ARCHIVE" - 修改后必须重启 MySQL，
SET GLOBAL无法动态生效 - 启用后，任何尝试创建 MyISAM 表的操作都会报错：
ERROR 1286 (42000): Unknown storage engine 'MyISAM'
为什么 CREATE TABLE ... ENGINE=MyISAM 仍可能成功？
即使设置了 disabled_storage_engines，某些场景下 MyISAM 表仍能建出来——这不是配置失效，而是绕过了校验路径。
- 使用
CREATE TABLE ... SELECT且源表是 MyISAM 时，新表默认沿用源引擎，不触发引擎白名单检查 - 从备份恢复（如
mysql命令导入 SQL）时，如果 SQL 文件里明确写了ENGINE=MyISAM，而服务端版本不支持该配置项，就会直接执行 -
ALTER TABLE ... ENGINE=MyISAM在引擎已加载状态下可能成功（disabled_storage_engines只影响初始化加载，不影响运行时切换，但 8.0.23+ 已修复此漏洞）
MyISAM 禁用后对现有表和操作的影响
禁用的是「新加载」和「新建」，不是「删除」或「隔离」。已有 MyISAM 表仍可读写，直到你主动转换或服务重启后引擎未被加载。
- 重启后，如果系统表（如
mysql.plugin）依赖 MyISAM，MySQL 可能无法启动——但现代版本默认用 InnoDB，一般无此问题 -
SHOW ENGINES中 MyISAM 显示为DISABLED，不再是YES -
information_schema.TABLES仍能查到 MyISAM 表，但CREATE TABLE、CREATE TEMPORARY TABLE等语句会立即失败 - 复制（Replication）不受影响，只要主从配置一致，MyISAM 表变更仍能同步（但不推荐）
替代方案：应用层拦截比配置更可靠
配置项有版本和重启限制，而真实生产环境常需灰度控制或细粒度拦截。这时候靠数据库代理或中间件更可控。
- Percona Server 提供
sql_mode扩展：STRICT_ENGINE_TYPE，可在语句级拒绝非默认引擎 - ProxySQL 或 MaxScale 可配置规则，匹配
ENGINE=MyISAM的建表语句并返回错误 - 应用 ORM 层统一设置默认引擎（如 Django 的
DEFAULT_TABLESPACE、Laravel 的connections.mysql.engine），比依赖 MySQL 配置更前置 - 注意：
disabled_storage_engines不影响 MEMORY、CSV 等其他引擎，若需一并限制，必须显式列出
真正麻烦的不是加一行配置，而是确认所有备份、迁移脚本、监控采集点、DBA 工具是否还悄悄依赖 MyISAM 的行为——比如某些老监控会查 mysql.myisam_log 这类不存在的表。
