用 MySQL SELECT SLEEP() 优雅模拟网络超时与并发死锁

你写了一个接口，配置了 MyBatis 的查询超时时间为 3 秒（readTimeout=3000）。
测试痛点： 怎么验证这个超时配置生效了？

SELECT SLEEP() 是 MySQL 的内置函数，它能让当前的 SQL 执行线程"睡眠"指定的秒数。这在测试系统的健壮性、连接池配置以及并发锁机制时，好用到爆炸。

语法非常简单：

sql 复制代码

SELECT SLEEP(N);

这是最常用的场景。我们需要验证 Spring Boot / JDBC 是否能正确处理数据库超时异常。

测试 SQL：

sql 复制代码

-- 假设业务查询是查用户
SELECT * FROM users WHERE id = 1 AND SLEEP(5);

预期结果：

如果你的应用层配置了 socketTimeout=3000 (3秒)，那么 3 秒后，你的 Java 程序应该捕获到 SocketTimeoutException 或 MySQLTimeoutException，而不是傻傻地等 5 秒。

背景： 当数据库查询变慢时，连接池很容易被占满，导致整个系统不可用（雪崩效应）。
测试方案：

利用 JMeter 或 Apache Benchmark 开启 50 个线程，并发请求一个执行 SELECT SLEEP(10) 的接口。
观察：

如果你的连接池最大连接数 (maxActive) 设置为 20。你会发现前 20 个请求进去了，后面的请求会开始排队（Waiting），最终报错"Get connection timeout"。
目的： 验证连接池满载时的降级策略和报警机制是否生效。

背景： 有些并发 Bug 只有在两个事务"同时"执行时才会出现。但在本地调试时，代码跑得太快，很难手动模拟"同时"。
技巧： 用 SLEEP 强行延长事务持有锁的时间。

事务 A (模拟长事务):

sql 复制代码

BEGIN;
UPDATE products SET stock = stock - 1 WHERE id = 100;
-- 强行持有锁 20 秒，给事务 B 制造机会
SELECT SLEEP(20); 
COMMIT;

事务 B (测试被阻塞):

在事务 A 睡觉的 20 秒内，启动事务 B 去更新同一行，观察是否会被阻塞（Block）或超时。

这是黑客最喜欢的场景，也是开发者必须防范的。
背景： 某些接口即使报错也不会回显错误信息（Blind），黑客无法知道 SQL 是否注入成功。
攻击手段：
http://api.com/user?id=1 AND SLEEP(5)
判断标准：

虽然 SLEEP 好用，但它在生产环境是危险品。

严禁在生产环境业务代码中使用：
万一你手抖把 SLEEP(1) 写进了线上代码，只要 QPS 稍微高一点，数据库连接池瞬间就会被占满，直接导致全站宕机（Denial of Service）。
WHERE 子句中的陷阱：
注意！SLEEP 是每行执行一次！

sql 复制代码

-- 假设 users 表有 1000 行
SELECT * FROM users WHERE id > 0 AND SLEEP(1);

后果： 并不是睡 1 秒，而是睡 1000 x 1 = 1000 秒 ！MySQL 会扫描每一行，对每一行都执行一次睡眠。这绝对是毁灭级的。

基于 Statement 格式的 Binlog 复制，会将 SLEEP 语句同步到从库执行。主库睡了 10 秒，从库回放时也要睡 10 秒，导致主从延迟瞬间飙升。

SELECT SLEEP() 是后端开发者的"混沌工程"入门工具。