DROP TABLE触发器必须用BEFORE DROP或AFTER DROP，不能依赖AFTER CREATE；Oracle/SQL Server支持该机制，MySQL不支持；需注意作用域、权限、时区及禁止在触发器中执行DDL或未授权DML。
DROP TABLE 触发器必须用 BEFORE DROP 或 AFTER DROP，不能靠 AFTER CREATE 补漏
很多人误以为建个 AFTER CREATE 触发器就能覆盖删除行为，结果 DROP TABLE t1 照常执行——因为 CREATE 和 DROP 是完全独立的 DDL 事件，Oracle、SQL Server、MySQL 都不互通。真正能捕获删除动作的，只有显式声明的 BEFORE DROP 或 AFTER DROP 事件。
-
BEFORE DROP可调用RAISE_APPLICATION_ERROR（Oracle）或ROLLBACK（SQL Server）中止操作；AFTER DROP只能记录日志，无法阻止 - 触发器作用域必须匹配：想拦 SCOTT 用户下的表，就得在 SCOTT 模式下建 schema 级触发器，不是在 SYS 下建一个就能管全库
- MySQL 不支持 DDL 触发器，别在 MySQL 里找
BEFORE DROP TABLE——它压根没这个语法
SQL Server 中用 DATABASE 级触发器拦截 DROP 并回滚
SQL Server 最常用的是数据库级 DDL 触发器，绑定到 ON DATABASE，监听 DROP_TABLE 事件。关键点是必须加 ROLLBACK，否则只打印提示但不阻断。
- 触发器内用
EVENTDATA()提取元数据，比如@data.value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname')获取被删表名 - 直接
PRINT不够，必须跟ROLLBACK才能终止事务；否则语句仍会成功执行 - 避免在触发器里查
sys.tables这类视图判断表是否存在——DROP已开始执行，表可能已从缓存中移除，查询反而报错
Oracle DDL 触发器里查数据字典容易报 ORA-00604 / ORA-00942
最常踩的坑是：在 SCOTT 模式下写的触发器，却在 HR 用户执行 DROP 时被调用，这时 USER_TABLES 查的是 HR 的对象，不是 SCOTT 的，导致权限不足或查不到表，抛出 ORA-00604（递归 SQL 错误）或 ORA-00942（表不存在）。
- 所有数据字典查询优先用
DBA_OBJECTS，并加WHERE OWNER = SYS.LOGIN_USER显式限定上下文用户 - 禁止在触发器里做 INSERT 日志表操作，除非该日志表对所有可能触发的用户都已授权
INSERT - 调试时
DBMS_OUTPUT.PUT_LINE必须配合SET SERVEROUTPUT ON，否则输出被静默吞掉，你以为没触发
只拦特定表、不拦全部 DROP，靠系统绑定变量，别硬编码或查表
想只禁止删 EMP 和 DEPT，别写 SELECT COUNT(*) FROM USER_TABLES WHERE TABLE_NAME = 'EMP'——触发器执行时表可能已被删了一半，查不到就误放行。Oracle 提供了安全的上下文变量：ora_dict_obj_name 和 ora_dict_obj_owner，它们在触发瞬间就被赋值，稳定可靠。
- 判断逻辑应为：
IF ora_dict_obj_owner = 'SCOTT' AND ora_dict_obj_name IN ('EMP', 'DEPT') - 日志时间统一用
SYSDATE，不用CURRENT_DATE，后者受会话时区影响，归档分析时容易错乱 - 绝对不要在
BEFORE DROP里调用EXECUTE IMMEDIATE或DBMS_DDL——Oracle 官方明确警告这是未定义行为，极易引发崩溃
真正难的不是写触发器，而是预判谁会在什么上下文里执行 DROP、日志表有没有被所有人授权、时区和权限是否一致。这些细节一错，触发器要么不生效，要么自己先崩。
