MySQL无法在权限系统中限制存储引擎，disabled_storage_engines不拦截建表，触发器和performance_schema也无法实时阻断；ProxySQL是唯一SQL层实时拦截方案，需配置正则覆盖ENGINE=MyISAM变体；应用层和CI/CD管控更可靠。
MySQL 本身不支持运行时引擎白名单
直接在 MySQL 权限系统里限制用户只能用 InnoDB、不能用 MyISAM，做不到。因为 GRANT 语句没有 ENGINE 相关权限项，CREATE TABLE 语句里的 ENGINE= 子句压根不被校验——哪怕你只给了 CREATE 权限，用户照样能写 ENGINE=MyISAM 并成功建表。
常见错误认知包括：
- 以为
disabled_storage_engines能拦截建表：它只是阻止引擎模块加载，修改后必须重启 MySQL，且对已有表和建表语句完全不拦截 - 试图用触发器拦截 DDL：MySQL 不支持
CREATE TABLE触发器，information_schema是只读视图，无法在其上建任何触发器 - 依赖
performance_schema.events_ddl_history：这是事后记录，不是拦截点，查得到但拦不住
ProxySQL 是唯一能实时拦截的方案
如果你必须在 SQL 层做硬性阻断，ProxySQL 是目前生产环境唯一可行的中间件方案。它在语句转发前解析 SQL，匹配正则并返回错误。
关键配置要点：
- 必须开启
mysql-query_processor_verbose=1，否则规则可能静默失效，调试时看不到匹配日志 - 正则要覆盖大小写和引号变体：
^CREATE\s+TABLE.*ENGINE\s*=\s*['"]?MyISAM['"]?，末尾加i标志 -
CREATE TABLE ... SELECT不含ENGINE=，需额外规则匹配CREATE\s+TABLE.*SELECT，并检查源表引擎 -
CREATE TEMPORARY TABLE常带换行或注释，基础正则容易漏，必须单独加规则，比如匹配TEMPORARY.*ENGINE
真正可控的防线在应用层和 CI/CD
比起在数据库侧打补丁，从源头约束建表行为更稳定、更易维护。
实操建议：
- Django 中用
__table_args__ = {'mysql_engine': 'InnoDB'}硬编码引擎；SQLAlchemy 同理，避免运行时传参 - Go 的 GORM 默认不写
ENGINE，但如果用db.Exec("CREATE TABLE ... ENGINE=MyISAM")就绕过所有控制 - CI/CD 流水线中加入 SQL 静态扫描，用正则
ENGINE\s*=\s*['"]?MyISAM在 PR 阶段就拦截 - 禁止动态拼接 DDL：所有建表语句走预编译模板或代码生成器，杜绝运行时传入引擎名
最容易被忽略的三个场景
临时表、CREATE TABLE SELECT、以及跨库调用存储过程中的隐式引擎选择，这三类操作既不触发 disabled_storage_engines，也容易逃过 ProxySQL 的基础正则规则。
它们需要单独验证和覆盖：
-
CREATE TEMPORARY TABLE t1 (...) ENGINE=MyISAM—— 临时表引擎不受全局禁用影响，且语句格式多变 -
CREATE TABLE t2 AS SELECT * FROM t1—— 不显式声明引擎，但会继承源表引擎，而源表可能是MyISAM - 存储过程中执行建表逻辑 —— 权限检查发生在执行时，若过程定义在
mysql库但操作其他库的表，引擎控制逻辑可能失效
