mysql无法在运行时限制用户使用特定存储引擎，因权限系统不校验create table中的engine子句；disabled_storage_engines需重启生效且不拦截ddl；proxysql是唯一可落地的实时拦截方案；应用层和ci/cd管控更可靠。
MySQL 本身无法在运行时限制用户只能使用特定存储引擎——这不是权限系统能控制的范畴，也没有对应的 GRANT 选项或内置策略机制。
为什么 GRANT 语句对 ENGINE 无效
MySQL 的权限模型只作用于数据库对象（库、表、列）和操作类型（SELECT/INSERT/ALTER），不感知 CREATE TABLE 语句中的 ENGINE= 子句。即使你给用户授予了 CREATE 权限，他依然可以写 CREATE TABLE t1 (...) ENGINE=MyISAM，服务端不会校验该引擎是否“被允许”。
-
disabled_storage_engines是全局配置项，仅阻止引擎模块加载，不影响已有 MyISAM 表的访问，也不拦截建表语句；且修改后需重启 MySQL 才生效 - 试图用
TRIGGER拦截 DDL（如CREATE TABLE）完全不可行：MySQL 不支持 DDL 触发器，information_schema是只读视图，无法在其上建触发器 -
performance_schema.events_ddl_history（8.0.33+）仅记录已执行的 DDL，属于事后审计，无法拒绝请求
ProxySQL 是唯一可落地的实时拦截方案
如果你必须在 SQL 层面硬性阻断非法引擎，得靠中间件在语句转发前做解析匹配。ProxySQL 是目前生产环境里最成熟的选择。
- 启用
mysql-query_processor_verbose=1，否则正则规则可能静默失效 - 规则要覆盖大小写和引号变体：
^CREATE\s+TABLE.*ENGINE\s*=\s*['"]?MyISAM['"]?，并加i标志 - 注意
CREATE TABLE ... SELECT语句不显式含ENGINE=，需额外规则匹配，并检查源表引擎（逻辑更重） -
CREATE TEMPORARY TABLE常带注释或换行，常规正则容易漏，必须单独加规则，比如匹配TEMPORARY.*ENGINE
真正可控的防线在应用层和 CI/CD
比起在数据库侧打补丁，从源头约束建表行为更稳定、更易维护。
- ORM 层硬编码引擎：Django 用
__table_args__ = {'mysql_engine': 'InnoDB'}；SQLAlchemy 同理；Go 的 GORM 默认不写ENGINE，但若用db.Exec("CREATE TABLE ... ENGINE=...")就绕过所有控制 - CI/CD 流水线中加入 SQL 静态扫描，用正则匹配
ENGINE\s*=\s*['"]?MyISAM，在 PR 阶段就拦截 - 禁止动态拼接 DDL：所有建表语句走预编译模板或代码生成器，杜绝运行时传入引擎名
最容易被忽略的是临时表和 CREATE TABLE SELECT 场景——它们既不触发 disabled_storage_engines，也容易逃过 ProxySQL 的基础正则规则，必须单独验证和覆盖。
