MySQL内置函数在高并发下是否线程安全
绝大多数 MySQL 内置函数（如
UUID()、
NOW()、
RAND()、
CONCAT()）本身是线程安全的——它们不依赖全局可变状态，每次调用在当前会话上下文中独立计算。但「线程安全」不等于「业务语义安全」：比如
UUID()虽不会崩溃或返回脏数据，但在高并发插入场景下可能因网络延迟或客户端时钟漂移，导致生成的 ID 在时间维度上不严格递增，影响索引写入效率。
哪些函数在高并发下容易暴露性能瓶颈
真正拖慢高并发的关键不是函数本身出错，而是它们触发的隐式开销：
UUID_SHORT()依赖服务器时钟和自增计数器，若每秒插入超万级，可能因锁争用（
auto_inc_lock或内部计数器互斥）导致延迟毛刺
GET_LOCK()和
RELEASE_LOCK()是显式阻塞型函数，在高并发抢锁场景下极易堆积等待，且锁不随连接断开自动释放，易引发死锁或资源泄漏
SLEEP()直接让线程休眠，任何业务逻辑中混用它都会放大连接池耗尽风险，尤其在连接复用率高的应用中 涉及子查询或临时表的函数（如
JSON_CONTAINS()配合大 JSON 字段）会在每行计算时触发内存分配和解析，QPS 上千后 CPU 使用率陡升
用户自定义函数（UDF）比内置函数更危险
UDF 由 C/C++ 编写，加载到 MySQL 进程空间，一旦有内存越界、未加锁共享变量或阻塞系统调用，会直接导致 mysqld crash，且故障不可预测。高并发下暴露概率指数级上升：
没有线程局部存储（TLS）意识的 UDF，在多线程执行时可能读写同一全局变量，结果错乱 调用了非 reentrant 的 libc 函数（如localtime()），在并发调用时返回错误时区或崩溃 未设置
DETERMINISTIC属性却返回确定值，导致查询缓存误判，或主从复制时 binlog 记录不一致 MySQL 8.0+ 对 UDF 加载限制更严，默认禁用动态库加载，需显式配置
secure_file_priv和
plugin_load_add
替代方案比“修函数”更重要
遇到高并发下的函数性能问题，优先考虑绕过函数计算，把压力转移到应用层或架构层：
用应用层生成ULID或
CUID替代
UUID()，避免服务端时钟依赖和随机 I/O 将
DATE_FORMAT(NOW(), '%Y%m%d')这类固定格式需求，改为应用传入预计算字符串，减少服务端函数调用频次 对需要原子计数的场景（如发号器），改用 Redis INCR + MySQL 异步落库，而非死磕
LAST_INSERT_ID()配合
SELECT ... FOR UPDATEJSON 字段高频查询字段（如
$.status）应冗余为普通列，并建索引；MySQL 5.7+ 支持虚拟列 + 索引，比运行时解析高效得多
函数只是工具，高并发下的稳定性从来不由单个函数决定，而取决于它在整个执行链路中的位置、是否持有锁、是否触发磁盘/网络/内存敏感操作——这些细节，往往在压测时才突然浮出水面。
