mysql事务中可安全使用uuid()、now()、connection_id()等只读函数；sleep()可用但慎用；get_lock()和release_lock()会隐式提交，导致事务立即结束；load_file()不触发提交，错误时事务仍可回滚。
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 类命令，却没人意识到它已切走事务上下文。
