MySQL内置函数本身线程安全，但高并发下性能瓶颈源于不当用法：如WHERE/ORDER BY中使用函数导致索引失效、JSON解析无索引、自定义函数无法并行等，叠加配置失当（如buffer_pool_size过小、max_connections不合理）引发连接堆积与I/O打满。
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 —— 这些才是稳定性真正崩塌前的静默信号。
