触发器管理需先确认存在性，用SHOW TRIGGERS或information_schema查询；删除必加IF EXISTS；命名须规范为trg_表名_时机_事件_用途；ALTER TABLE后须验证NEW/OLD引用；超轻量逻辑应移交应用层。
触发器查不到、删不掉？先确认它真在那儿
很多“管理混乱”其实始于根本不知道触发器是否存在或定义是否生效。MySQL 不像存储过程那样能用 SHOW PROCEDURES 一键扫清，必须主动查。
- 用
SHOW TRIGGERS查当前库所有触发器：SHOW TRIGGERS;
- 按表过滤更实用：
SHOW TRIGGERS LIKE 'orders';
- 看完整定义（尤其怀疑语法被静默截断时）：
SHOW CREATE TRIGGER update_order_log;
- 如果返回空，不是“没生效”，而是压根没创建成功——检查
CREATE TRIGGER是否执行过，以及有没有被事务回滚或权限拦截
删错触发器或误删后无法恢复？必须加 IF EXISTS
线上环境执行 DROP TRIGGER trigger_name 报错 ERROR 1360 (HY000): Trigger does not exist 并不可怕；可怕的是没加防护就批量删，结果把关键审计触发器干掉了。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 永远用
IF EXISTS保底：DROP TRIGGER IF EXISTS before_user_insert;
- 跨库删除要显式指定 schema：
DROP TRIGGER IF EXISTS sales_db.audit_customer_update;
- 别依赖“记得住名字”——用
information_schema.triggers导出清单再操作：SELECT trigger_name, event_object_table, action_timing, event_manipulation FROM information_schema.triggers WHERE trigger_schema = 'prod_db';
触发器越来越多，命名和职责开始打架？立刻建立命名与隔离规范
当出现 trg_orders_after_insert_v2、trg_orders_after_insert_audit、trg_orders_after_insert_sync 并存时，说明逻辑已失控。MySQL 触发器不支持注释字段，命名就是唯一文档。
- 强制命名格式：
trg_[表名]_[时机]_[事件]_[用途]，例如：trg_products_before_update_price_check - 禁止多个触发器监听同一事件+同一表——合并逻辑，或用条件分支（
IF OLD.status != NEW.status THEN ...）替代 - 日志类、校验类、同步类触发器必须分表处理：校验放
BEFORE，日志写独立trigger_log表，同步走应用层或事件调度器，绝不让一个触发器干三件事
改了表结构，触发器突然报错？重点检查 NEW/OLD 引用和 SQL 模式
ERROR 1327 (42000): Undeclared variable: NEW.price 或隐性数据截断，往往不是触发器坏了，而是底层变了它还不知道。
- 每次
ALTER TABLE后，手动验证涉及的触发器：INSERT INTO products (name) VALUES ('test');看是否抛错 - 启用严格模式防“静默失败”：
SET sql_mode = 'STRICT_TRANS_TABLES';
这能让NEW.xxx访问不存在字段、字符串超长等立刻暴露 - 避免在触发器里拼接动态列名——
NEW和OLD是固定上下文，不支持变量列引用；真要泛化处理，得上存储过程+预编译，但那已超出触发器适用范围
