MySQL SELECT查询间歇性返回不一致的原因排查求助

这种偶发的「首次查询返回0行、第二次正常」的问题确实挺棘手，咱们从常见到少见的场景逐一分析，不一定是硬盘I/O故障导致的：

1. 主从复制同步延迟（最常见） #

如果你的MySQL架构用了主从复制，且登录查询是负载均衡到从库的，就可能出现这个问题：

• 用户完成注册（数据写入主库）后，首次登录请求被路由到了还没同步完数据的从库，此时查询返回0行；
• 第二次登录时，从库已经完成了该用户数据的同步，或者请求被路由到了主库，就能查到数据。

排查方式：

• 执行SHOW SLAVE STATUS\G查看从库的Seconds_Behind_Master值，确认问题发生时段有没有同步延迟；
• 检查应用的读写分离路由规则，看登录请求是否有可能被分配到从库。

2. 事务提交不及时或隔离级别影响 #

如果用户账号是刚创建的（比如注册后立即登录），可能是创建账号的事务还没提交，导致首次查询看不到数据：

• 注册流程中，插入用户数据的事务如果因为某些原因（比如异步操作、代码逻辑延迟）没及时提交，此时用另一个连接执行登录查询，在MySQL默认的REPEATABLE READ隔离级别下，是看不到未提交的事务数据的；
• 等事务提交后，第二次查询就能正常读取到。

排查方式：

• 检查注册接口的代码，确认插入用户的事务是否在返回成功响应前就已经提交；
• 查看数据库的事务日志，确认问题用户的账号创建事务提交时间和首次登录查询时间的先后关系。

3. 缓存层的异常 #

虽然MySQL 8.0已经移除了Query Cache，但如果应用层自己实现了查询缓存，就可能出现缓存空结果的情况：

• 首次查询时，用户数据还没写入，缓存了「0行」的结果；
• 数据写入后缓存没有及时失效，不过如果缓存有短时间过期策略，第二次查询时缓存失效，就会去数据库读取到最新数据。

排查方式：

• 检查应用层的缓存逻辑，看是否对SELECT * FROM users WHERE username=?这类查询做了缓存；
• 确认缓存的失效机制是否和用户数据的写入操作绑定。

4. 短暂的硬盘I/O阻塞（你的怀疑方向） #

虽然MySQL一般不会静默返回错误，但如果出现短暂的磁盘I/O阻塞（比如磁盘队列满、临时的硬件卡顿），也可能导致首次查询无法读取到数据：

• 首次查询时，MySQL的读请求被磁盘I/O阻塞，超时或者返回空结果；
• 第二次查询时，I/O恢复正常，就能读取到数据。

排查方式：

• 查看MySQL的错误日志，搜索是否有innodb_io_*相关的警告或错误；
• 查看操作系统的系统日志（比如dmesg、/var/log/messages），看问题发生时段有没有磁盘I/O相关的报错。

5. 连接池或会话状态异常 #

如果应用使用了数据库连接池，个别连接的会话状态可能异常：

• 比如某个连接之前被设置了特殊的事务隔离级别（比如READ UNCOMMITTED之外的级别，且有未提交的事务），导致首次查询读取不到最新数据；
• 第二次登录请求使用了连接池中的新连接，会话状态正常，就能查到数据。

排查方式：

• 查看应用日志，记录首次和第二次查询使用的数据库连接ID，对比两次连接的会话参数；
• 检查连接池的配置，看是否有连接复用的异常情况。

内容的提问来源于stack exchange，提问作者glaba