MySQL 函数本身（如
SUM()、
DATE_ADD()、
JSON_EXTRACT()等内置函数）在高并发下是线程安全的，不会因并发调用而崩溃或返回错误结果——但「稳定」不等于「高效」，实际稳定性取决于函数如何被使用、是否触发隐式锁、是否依赖低效执行路径，以及底层资源是否被耗尽。
为什么有些 MySQL 函数在高并发下会“卡住”或拖垮性能
函数本身无状态、无副作用，但它们常嵌套在慢查询中，放大执行代价。尤其当函数出现在
WHERE或
ORDER BY子句里时，可能直接导致索引失效、全表扫描或临时表膨胀。
LIKE '%abc'或
CONCAT(name, ' ') = 'Alice '：无法走索引，每行都要计算，QPS 上千时 CPU 瞬间拉满
UNIX_TIMESTAMP(created_at) > 1700000000：对字段加函数，强制放弃
created_at索引
JSON_CONTAINS(data, '"pending"', '$.status')：若
data列未建虚拟列+索引，每次都要解析整段 JSON 字符串 自定义函数（
CREATE FUNCTION）：默认为
DETERMINISTIC但未显式声明，或含 SQL 操作，会禁用 query cache（MySQL 5.7 及以前），且无法并行执行，成为单点瓶颈
高并发下必须避开的函数陷阱
不是函数不能用，而是某些用法在并发压力下会暴露设计缺陷。以下操作在峰值 QPS > 1000 的业务中已多次引发连接堆积、
Threads_running暴涨、甚至主从延迟飙升。 在大表
UPDATE中用
UUID()或
NOW(6)生成值：触发行锁升级或间隙锁扩散，阻塞其他写入 用
FIND_IN_SET(status, 'pending,processing,done')替代枚举字段或关联表：无法利用索引，且字符串匹配开销随列表长度非线性增长 在
GROUP BY中嵌套
IF()+
CASE WHEN+
DATE_FORMAT()：临时表易爆内存，
sort_buffer_size不足时会写磁盘，I/O 直接打满 对
TEXT/
MEDIUMTEXT字段调用
LENGTH()或
SUBSTRING()：若字段未加前缀索引且数据量大，每次访问都需读取完整大字段
真正影响稳定性的从来不是函数，而是配套配置和用法
MySQL 函数只是“扳机”，真正扣动性能崩塌扳机的是参数配置失当、连接管理失控、或缓存策略缺失。比如：
没调innodb_buffer_pool_size→ 热数据不在内存 → 每次函数计算都要等磁盘 I/O → 并发一上来就排队
max_connections设为 2000，但应用层连接池最大也只配了 50 → 实际只用到 50 个连接，其余全是空转消耗内存 没设
wait_timeout = 300→ 大量空闲连接长期占着线程和内存 →
Threads_connected持续 > 90% → 新连接被拒绝，报错
Too many connections开了
general_log = ON调试函数行为 → 日志写满磁盘 → 整个 MySQL 写入阻塞
SHOW STATUS LIKE 'Threads_%'; SHOW STATUS LIKE 'Aborted_connects'; SHOW GLOBAL VARIABLES LIKE 'max_connections';
高并发场景下最危险的不是你用了什么函数，而是你没看
Threads_running是否持续高于 50、没确认
innodb_buffer_pool_hit_rate是否低于 99%、也没查过慢查询日志里有多少条带着
Using temporary; Using filesort—— 这些才是稳定性真正崩塌前的静默信号。
