MySQL不支持DDL触发器，因其触发器机制仅覆盖INSERT、UPDATE、DELETE等DML操作，DDL语句（如CREATE、ALTER、DROP）绕过存储引擎直接由Server层处理，语法上执行CREATE TRIGGER ON DATABASE FOR CREATE_TABLE会直接报ERROR 1064。
DDL 触发器在 MySQL 中根本不存在 —— 不是“不推荐”或“已弃用”，而是语法层面不识别 CREATE TRIGGER ... ON DATABASE FOR CREATE_TABLE 这类语句，执行会直接报错 ERROR 1064 (42000)。SQL Server 支持，是因为它的事件系统（Event Notification + DDL trigger engine）从 SQL Server 2005 起就将 DDL 操作抽象为可订阅的服务器/数据库级事件，而 MySQL 的触发器模型自始只覆盖 INSERT、UPDATE、DELETE 三类 DML 操作。
MySQL 为什么连语法都不允许定义 DDL 触发器
MySQL 的触发器实现绑定在存储引擎层（主要是 InnoDB），仅响应行级数据变更；CREATE TABLE 或 DROP INDEX 这类操作不经过存储引擎的数据路径，而是由 Server 层解析并直接调用元数据管理模块（如 dict_table_t 操作）。没有中间事件总线，自然无法插入触发逻辑。
这和架构设计取舍有关：MySQL 优先保证 DML 性能与轻量，不引入类似 SQL Server 的 EVENTDATA() 机制或 XML 事件上下文解析开销。
- 你不能在 MySQL 中写
CREATE TRIGGER tr_log_ddl AFTER CREATE ON SCHEMA—— 解析器会立刻拒绝 -
INFORMATION_SCHEMA.TRIGGERS表里永远查不到任何EVENT_TYPE为CREATE、DROP的记录 - 替代方案只能靠外部轮询
information_schema.TABLES或监听 binlog（需解析Query_log_event，且无法拦截或阻止操作）
SQL Server 的 DDL 触发器依赖哪几个关键组件
它不是靠“扩展触发器语法”实现的，而是构建在三层基础设施之上：
-
sys.server_event_notifications和sys.database_event_notifications：用于注册事件监听（但 DDL trigger 本身不依赖它） -
EVENTDATA()函数：每个 DDL 触发器内部必须调用，返回 XML 格式的事件上下文（含EventType、ObjectName、TSQLCommand等） - 目录视图如
sys.triggers（parent_class_desc = 'DATABASE'或'SERVER'）和sys.trigger_events：用来查询触发器绑定的事件类型，不能用OBJECT_ID()查 DDL 触发器
注意：DROP TRIGGER 本身也会触发 DROP_TRIGGER 事件 —— 所以删除前务必确认是否被自身阻断。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
想在 MySQL 里模拟 DDL 审计或拦截，实际能做什么
没有原生支持，就得绕路，每种都有明显短板：
- 开启 general_log 并定期解析日志文件：能看谁执行了
CREATE PROCEDURE，但无法阻止，且 I/O 开销大、日志格式不稳定 - 使用 MySQL 8.0+ 的
audit_log插件：可过滤QUERY类型事件，但审计粒度粗（无法区分CREATE VIEW和CREATE TABLE），且不能ROLLBACK - Proxy 层拦截（如 ProxySQL、MaxScale）：可匹配 SQL 模式（如
^CREATE\s+(TABLE|INDEX)）并返回错误，但无法识别参数化语句或嵌套在存储过程里的 DDL - 应用层统一 DDL 网关：最可控，但要求所有变更必须走该入口，运维习惯和权限模型得重构
真正需要“防止误删表”的场景，别寄希望于触发器 —— REVOKE DROP ON *.* FROM 'user' 或启用 sql_mode=STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER 更直接有效。
跨产品元数据架构差异的根本影响
MySQL 把元数据当“配置快照”存于磁盘文件（.frm 已弃用，现为 mysql.ibd + 数据字典表），SQL Server 则把元数据当“运行时对象”维护在内存+系统库（sys.objects、sys.schemas）中，并支持事务性修改。前者适合快速启动和简单复制，后者才能支撑 DDL 触发器、ALTER DATABASE SET READ_ONLY 这类带状态联动的操作。
所以当你看到 CREATE TRIGGER 在两边都存在，但行为天差地别时，本质不是语法差异，而是底层是否把“数据库结构变化”当作一个可观测、可参与、可干预的一等事件。
