MySQL 事务中能用哪些函数？哪些会隐式提交？
MySQL 中并非所有函数都能安全用于事务内。部分函数（尤其是修改系统状态或涉及非事务引擎的操作）会触发隐式提交，导致当前事务提前结束——这是最常被忽略的坑。
关键判断依据是：
SELECT类纯读取函数通常安全；而任何可能写入、锁定、刷新或切换上下文的函数需格外警惕。
UUID()、
NOW()、
CONNECTION_ID()：只读，无副作用，可在事务中任意使用
SLEEP()：不修改数据，但会阻塞事务执行，不影响事务一致性，可用但慎用（超时可能引发锁等待）
GET_LOCK()和
RELEASE_LOCK()：**会隐式提交**，调用后当前事务立即结束，后续语句在新事务中执行
LOAD_FILE()：依赖 secure_file_priv 配置，不触发提交，但若文件不存在或权限不足，报错
ERROR 1142 (42000): LOAD FILE command denied，事务仍可回滚
为什么 SELECT ... FOR UPDATE
不算“函数”，但必须放在事务里？
它不是函数，而是带锁的查询语句，其行为完全依赖事务隔离级别和事务生命周期。脱离事务使用
SELECT ... FOR UPDATE会导致锁在语句结束后立即释放，失去业务意义。
常见误用：
在自动提交模式下执行：SET autocommit = 1;→
SELECT * FROM t FOR UPDATE;→ 锁立刻释放，后续
UPDATE可能发生脏写 跨连接使用锁：连接 A 加了
FOR UPDATE，连接 B 尝试更新同一行会阻塞，但若连接 A 未提交/回滚就断开，锁由 MySQL 自动释放，B 继续执行 —— 这不是函数问题，是连接生命周期管理疏忽
INSERT ... ON DUPLICATE KEY UPDATE
在事务中的实际行为
该语句本质是原子操作，但内部可能触发唯一键冲突检测、插入或更新分支，MySQL 会确保整个语句在事务中保持一致性。不过要注意：
若表含多个唯一索引，冲突可能发生在不同索引上，ON DUPLICATE KEY UPDATE只响应第一个匹配的唯一约束，行为不易预测 如果
UPDATE子句中引用了
VALUES(col)，且该列在
INSERT部分为
DEFAULT或计算值，需确认是否真按预期取值（例如
VALUES(created_at)取的是 INSERT 时的值，不是当前时间） 与
REPLACE INTO的关键区别：
REPLACE是先
DELETE再
INSERT，会触发两次自增 ID 分配，并可能激活 DELETE 触发器 —— 它在事务中也生效，但逻辑更重，容易引发外键或触发器意外
存储过程里调用函数时事务边界怎么控制？
存储过程本身不开启新事务，但它内部的语句受外部事务控制。真正影响事务边界的，是过程体中是否包含显式
COMMIT/
ROLLBACK，或调用了隐式提交函数（如
GET_LOCK()）。
典型陷阱：
过程定义含SQL SECURITY DEFINER，但调用者权限不足，导致某条语句报错（如
ERROR 1142 (42000): INSERT command denied），此时事务仍处于活跃状态，需显式
ROLLBACK，否则连接保持打开并持有锁 过程内嵌套调用另一个含
GET_LOCK()的过程 → 外层事务在进入该子过程时即已提交，后续语句不再受原事务保护 使用
START TRANSACTION在过程内开启新事务，会报错
ERROR 1305 (42000): SAVEPOINT does not exist（除非配合
SAVEPOINT），因为 MySQL 不允许在已有事务中再
START TRANSACTION
真正需要关注的不是“能不能用函数”，而是“这个函数会不会让我的事务突然失效”。很多线上数据不一致问题，根源都在某处悄悄调用了
GET_LOCK()或
FLUSH类命令，却没人意识到它已切走事务上下文。
