MySQL 5.7 存储过程无法用SLEEP()实现毫秒级延时，因其仅支持整数秒、需PROCESS权限且阻塞连接；应改用NOW(6)获取微秒时间戳，配合TIMESTAMPDIFF(MICROSECOND)与WHILE循环轮询实现精确延时。
MySQL 5.7 存储过程中无法用 SLEEP() 实现毫秒级延时
SLEEP(n) 只接受整数秒参数，传入小数（如 SLEEP(0.1)）会被截断为 0，实际不等待。它底层调用的是系统 sleep(3)，最小单位是秒，且必须拥有 PROCESS 权限——该权限在多数生产环境已被禁用。更重要的是，它会阻塞整个连接，并发调用时极易耗尽连接池。
用 NOW(6) + 循环轮询模拟毫秒级等待
MySQL 5.7 支持 NOW(6) 返回带微秒精度的时间戳（例如 '2026-09-30 12:12:00.123456'），这是实现可控延时的唯一可行基础。你需要手动记录起始时间，再在循环中比对差值：
- 声明高精度起始时间：
DECLARE start_ts DATETIME(6) DEFAULT NOW(6); - 设定目标等待微秒数（如 500 毫秒 = 500000 微秒）：
DECLARE target_us BIGINT DEFAULT 500000; - 用
WHILE循环持续检查：WHILE TIMESTAMPDIFF(MICROSECOND, start_ts, NOW(6)) -
SLEEP(0.01)是必要的“让出 CPU”操作，避免空转吃满单核；但不要设太密（如SLEEP(0.001)），否则触发频繁系统调用，反而增加误差
注意 TIMESTAMPDIFF(MICROSECOND, ...) 的精度陷阱
TIMESTAMPDIFF(MICROSECOND, a, b) 在 MySQL 5.7 中返回的是整数微秒差，但实际精度受限于系统时钟和函数调用开销。两次 NOW(6) 调用之间本身就存在几微秒到几十微秒的延迟。这意味着：
- 你设
target_us = 100000（100ms），实测可能在 102–108ms 之间完成，误差基本稳定在 ±5ms 内 - 不要尝试实现 1ms 级别等待——函数调用+上下文切换开销已超过目标值，结果不可控
- 若需更高一致性，应在循环内加计数限制，防止因时钟跳变或异常导致无限等待：
DECLARE i INT DEFAULT 0; WHILE ... AND i
真正需要定时触发？别在存储过程里硬扛
存储过程本质是同步、阻塞、会话绑定的执行单元。所谓“500ms 后执行某逻辑”，在过程内部只能靠轮询卡住当前线程；它不能注册回调、不支持后台线程、也无法脱离连接存活。如果你的真实需求是“3 秒后发通知”或“每 500ms 扫描一次状态”，应该：
- 改用 MySQL
EVENT调度器（支持AT CURRENT_TIMESTAMP + INTERVAL 500 MICROSECOND？不支持——EVENT 最小粒度仍是秒，但可设INTERVAL 1 SECOND配合过程内微秒轮询） - 把延时逻辑下沉到应用层（如 Java 的
ScheduledExecutorService、Python 的asyncio.sleep(0.5)） - 用消息队列（如 RabbitMQ 延迟插件、Redis ZSET + 定时拉取）解耦时效性要求
硬在存储过程中做毫秒级控制，只适合极短、确定、低频的等待场景，比如规避主键冲突重试前等 100ms。一旦涉及精度敏感或高频调度，就超出了它的设计边界。
