MySQL自定义函数本身不加锁，但调用时出现严重并发锁争用，根本原因在于函数内部SQL操作、事务上下文或隐式行为引发锁冲突，如在SELECT中执行UPDATE、用于WHERE/ORDER BY触发全表扫描与间隙锁、UDF导致线程阻塞等。
MySQL 自定义函数（UDF 或存储函数）本身不直接加锁，但调用它时出现严重并发锁争用，说明问题不在函数语法层面，而在于函数内部执行的 SQL 操作、事务上下文或隐式行为。根本原因通常是：函数被用在了不该用的地方，触发了意外的锁行为或阻塞路径。
为什么在 SELECT 中调用含 UPDATE 的自定义函数会卡住整个查询
MySQL 存储函数（FUNCTION）必须是「只读」的（即不能修改数据），否则创建时就会报错：ERROR 1418。但如果你绕过限制（比如用 sql_mode 关闭检查，或误用存储过程伪装成函数），或者函数里调用了外部服务/临时表/用户变量等副作用操作，就可能引发不可预测的锁行为。
更常见的是：
- 函数体里写了
SELECT ... FOR UPDATE或UPDATE - 函数被用在
WHERE子句或JOIN条件中，导致 MySQL 无法下推过滤，被迫对每行都执行函数 —— 每次执行又去查/更新另一张表 - 函数内访问了没有索引的列，触发全表扫描 + 间隙锁（
Gap Lock），扩大锁范围
典型表现：SELECT id FROM orders WHERE status = my_func(user_id)，而 my_func() 内部执行 UPDATE user_cache SET last_used = NOW() WHERE uid = xxx —— 这会让每个匹配行都尝试更新缓存表，锁竞争瞬间爆炸。
自定义函数在 ORDER BY 或 GROUP BY 中引发临键锁放大
当函数用于排序或分组字段，且该函数返回值依赖于某张表的字段（例如 get_user_level(user_id) 内部查 users 表），MySQL 可能为满足一致性读（MVCC）而对查询涉及的所有索引区间加 Next-Key Lock（记录锁 + 间隙锁）。
尤其在 REPEATABLE READ 隔离级别下：
- 即使函数只做
SELECT，只要它查的是非唯一索引，InnoDB 就可能锁定整个间隙 - 多个并发查询同时调用该函数，会互相等待对方释放间隙锁，表现为
Lock wait timeout exceeded -
EXPLAIN看不出问题，因为执行计划显示“Using filesort”，但实际锁已在函数内查询时产生
UDF（C/C++ 编写的外部函数）导致连接级阻塞
如果使用的是真正意义上的 UDF（通过 CREATE FUNCTION ... SONAME），那它运行在 MySQL Server 进程内，完全绕过 SQL 层的锁控制逻辑：
容易踩的坑：
- UDF 内部做了文件 I/O、网络请求、或调用了线程不安全的库，造成整个 MySQL worker 线程卡死
- UDF 返回结果依赖全局状态（如共享内存、静态变量），多个并发调用互相覆盖或等待互斥量
- UDF 执行时间长，而 MySQL 默认不中断长时间运行的函数，导致后续语句排队等待该线程释放
这种阻塞不会出现在 INFORMATION_SCHEMA.INNODB_TRX 或 sys.innodb_lock_waits 中，因为它根本没走到 InnoDB 锁管理模块 —— 你只能看到 State: executing 却无锁信息。
替代方案：什么时候该放弃自定义函数
不是所有逻辑都适合塞进函数。高并发场景下，优先考虑：
能用 SQL 直接写的，别封装成函数 —— 比如 COALESCE(status, 'unknown') 比 get_status_label(id) 安全十倍。
- 需要跨表关联的逻辑，改用
LEFT JOIN+COALESCE，避免函数调用开销和锁扩散 - 缓存类计算（如用户等级、积分区间），提前物化到主表或用冗余字段，而不是实时算
- 必须封装的业务规则，改用应用层计算，数据库只负责存取；或改用存储过程显式控制事务边界
- 若坚持用函数，确保它只读、无副作用、只查单表主键、且被调用字段上有覆盖索引
最常被忽略的一点：MySQL 对函数的执行是逐行进行的，没有批处理优化。哪怕你 SELECT ... FROM big_table LIMIT 10，只要 WHERE 或 ORDER BY 里有函数，它仍可能扫描并调用函数上千次 —— 每一次都是一次潜在锁请求。
