触发器执行时不直接锁表，但会因内部SQL引发行级锁或间隙锁，具体取决于操作类型和隔离级别；其锁行为继承自所执行的DML语句，并可能延长原始事务边界导致死锁或锁争用。
触发器执行时会锁表吗
不会直接锁整个表，但可能引发行级锁甚至间隙锁，具体取决于触发器里写的 SQL 操作类型和事务隔离级别。
MySQL 的触发器本身不持有表锁，但它运行在触发它的 DML 语句（INSERT/UPDATE/DELETE）的同一事务上下文中。也就是说，锁由触发器内部执行的语句决定，不是触发器语法自带的。
-
SELECT ... FOR UPDATE或UPDATE触发的行会加行锁，如果扫描范围大或有索引缺失，可能升级为间隙锁甚至临键锁 - 触发器里写
INSERT INTO t2 SELECT * FROM t1这类语句，在REPEATABLE READ下可能对t1加范围锁 - 如果触发器调用存储函数且该函数含 DML，锁行为同样继承自那些语句
为什么 ON UPDATE 触发器常导致死锁
因为更新操作本身已持有一部分行锁，触发器再对关联表做更新，容易形成锁等待环路。
典型场景是：主表 orders 更新状态，触发器同步更新 order_logs 表；若两个事务交叉更新不同订单但又都试图写同一批日志记录，就可能卡住。
- 避免在触发器中更新与主表有外键或高频关联的表
- 确保触发器内所有 DML 都走相同索引顺序（比如总是先按
id升序更新），减少锁顺序不一致 - 把耗时操作（如写审计日志）改成异步，比如只插入一条消息到轻量表，由后台任务处理
SHOW CREATE TRIGGER 看不到锁信息，怎么查实际锁情况
触发器没有独立锁视图，得从事务和锁的全局视角看——它只是事务的一部分。
真正要定位问题，得结合 INFORMATION_SCHEMA.INNODB_TRX、INNODB_LOCKS（MySQL 5.7）或 performance_schema.data_locks（8.0+）来查当前谁在等什么锁。
- 执行
SELECT * FROM performance_schema.data_locks可看到每个事务持有的锁类型、对象（表/索引）、锁模式（如RECORD、LOCK_GAP） - 连带查
data_lock_waits能看出哪个线程在等哪个线程的锁 - 注意：触发器里的语句不会单独标记来源，只能通过
TRX_QUERY字段看完整 SQL 判断是否来自触发器逻辑
触发器中调用 NOW() 和 UUID() 的行为差异
这两个函数看似简单，但在复制和并发下表现完全不同，间接影响锁持续时间。
NOW() 是语句开始时间戳，同一个事务中多次调用返回相同值；而 UUID() 每次调用都生成新值，且底层依赖系统时间+MAC地址，在高并发下可能触发额外的锁（尤其旧版本 MySQL）。
- 主从复制时，
UUID()在从库重放会生成不同值，破坏一致性，建议改用UUID_SHORT()或应用层生成 - 频繁调用
UUID()可能引起innodb_buffer_pool内部争用，间接拉长事务时间，增加锁持有窗口 - 如果只是做唯一标记，
CONCAT('tmp_', CONNECTION_ID(), '_', UNIX_TIMESTAMP())更轻量可控
触发器的锁风险不在语法本身，而在它悄悄延长了原始 DML 的事务边界——这点很容易被忽略，尤其是当业务逻辑分散在多个触发器里时。
