MySQL中无SLEEP()仍可延时，但需依版本权限选择：5.7+有SLEEP()（需PROCESS权限、秒级、会话阻塞）；SQL Server用WAITFOR DELAY（毫秒级、独立语句、事务中慎用）；多库兼容则用时间轮询。
MySQL 里没有 SLEEP() 就不能延时？
能，但得看版本和权限。MySQL 5.7+ 默认提供 SLEEP() 函数，但它会阻塞整个语句执行，且需要 PROCESS 权限（很多生产环境被禁用）。直接在存储过程中写 SELECT SLEEP(5); 看似简单，实际可能被拒绝或拖慢连接池。
- 低权限账号执行会报错：
ERROR 1370 (42000): execute command denied to user -
SLEEP()是会话级阻塞，不是“后台延时”，调用期间该连接完全不可用 - 它不支持毫秒级精度，最小单位是秒（传小数如
SLEEP(0.1)会被截断为 0）
SQL Server 的 WAITFOR DELAY 怎么在存储过程里安全用？
这是最接近“原生延时”的方案，但必须注意语法位置和事务影响。WAITFOR DELAY 不是函数，不能出现在表达式里（比如不能写在 SET @x = WAITFOR... 中），只能作为独立语句存在。
- 正确写法：
WAITFOR DELAY '00:00:02.500';（支持到毫秒，格式严格为hh:mm:ss.mmm） - 如果在事务中使用，延时期间事务持续持有锁，可能引发阻塞——别在大事务中间插延时
- 无法动态拼接时间字符串，
@delay_str变量不能直接传给WAITFOR，得用EXEC动态执行（但会退出当前作用域，局部变量失效）
跨数据库的通用替代方案：用循环 + 系统时间判断
当权限受限、或需兼容 MySQL/PostgreSQL/SQL Server 多种环境时，手动轮询 NOW() 或 GETDATE() 是唯一可控方式。性能差、不精确，但胜在无权限依赖、逻辑透明。
- MySQL 示例：
SET @start = NOW();<br>WHILE TIMESTAMPDIFF(MICROSECOND, @start, NOW()) < 2000000 DO<br> DO SLEEP(0.01);<br>END WHILE;
- SQL Server 示例：
DECLARE @start DATETIME2 = GETDATE();<br>WHILE DATEDIFF(MILLISECOND, @start, GETDATE()) < 2000<br>BEGIN<br> WAITFOR DELAY '00:00:00.010';<br>END
- 注意：循环间隔别设太短（如每 1ms 查一次），否则 CPU 毛刺明显；也别太长（如 1s），误差可能超预期
为什么别在存储过程里做“真正”的异步延时？
所有主流关系型数据库的存储过程都是同步执行模型，没有事件循环、没有回调、不支持后台线程。所谓“延时”，本质只是让当前会话卡住一段时间。
- 想实现“3 秒后发通知”这类需求，存储过程本身做不到——必须靠外部调度（如应用层定时任务、数据库作业如 SQL Server Agent、MySQL Event Scheduler）
- 用
SLEEP()或WAITFOR模拟延时，只适合调试、限流、避免高频重试等短时控制场景 - 最容易被忽略的是连接生命周期：一个延时 10 秒的存储过程，就占着一个连接 10 秒，连接池小的时候等于直接拖垮并发能力
