MySQL查询结果不一致最常见原因是事务未提交或隔离级别导致快照不同，REPEATABLE-READ下存在幻读，READ-COMMITTED每次SELECT可能看到新提交数据，长事务和主从延迟也会加剧该现象。
MySQL 查询结果不一致，先查当前会话的隔离级别
结果不一致最常见原因是事务没提交、其他事务在改数据，而你的会话看到的是不同快照——这直接由 transaction_isolation 决定。别猜，直接查：
SELECT @@transaction_isolation;
注意：MySQL 8.0+ 返回类似 REPEATABLE-READ，5.7 可能是 REPEATABLE-READ 或带 SESSION 前缀的完整值；如果返回 READ-COMMITTED，那每次 SELECT 都可能看到新提交的数据，自然“不一致”。
- 全局设置不影响已开启的事务，只对后续新会话生效
-
SET SESSION transaction_isolation = 'READ-COMMITTED';立即生效，但仅限当前连接 - 应用用连接池时，可能复用旧连接，导致隔离级别和你预期不符
幻读不是 bug，是 REPEATABLE-READ 下的正常现象
你在同一个事务里两次 SELECT，第二次多出几行（或少几行），但没改过这些行——这就是幻读。MySQL 默认的 REPEATABLE-READ 能防止不可重复读，但**不阻止幻读**（除非加 SELECT ... FOR UPDATE 或用间隙锁）。
- 普通
SELECT不加锁，InnoDB 用 MVCC 快照，但快照只覆盖“已有行”，不锁定“未来插入的位置” - 想彻底避免幻读，得显式加锁：
SELECT * FROM t WHERE id > 100 FOR UPDATE;，但这会阻塞其他插入 -
INSERT ... SELECT或UPDATE ... WHERE在REPEATABLE-READ下也会受幻读影响，因为内部执行时可能读到新插入的行
检查是否被长事务拖累
一个没提交的事务卡了 10 分钟，它持有的快照会让所有后续 SELECT 都看不到这期间的变更，看起来像“结果卡住不动”。查活跃事务：
SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id FROM information_schema.INNODB_TRX;
重点关注 trx_state = 'RUNNING' 且 trx_started 时间很早的记录。
- 长期空闲但未提交的事务（比如应用异常退出没 rollback）最危险
- 监控
innodb_trx_trx_state和innodb_trx_trx_started是定位根源的最快方式 - 不要依赖超时自动回滚——
wait_timeout只断连，不结束事务；必须靠应用显式COMMIT或ROLLBACK
应用层读写分离时，从库延迟放大不一致感
如果你的“不一致”出现在主从架构下，比如刚 INSERT 主库就去从库查，查不到——这不是隔离级别问题，是复制延迟。确认方式：
SHOW SLAVE STATUS\G
看 Seconds_Behind_Master 是否非零，以及 Slave_SQL_Running 是否为 Yes。
- 即使
Seconds_Behind_Master = 0，也可能因并行复制重放顺序导致瞬时不一致 - 强制读主库的方案（如注释
/*FORCE_MASTER*/）比调低隔离级别更治本 - 从库默认也是
REPEATABLE-READ，但它的快照时间点取决于 SQL 线程执行时刻，不是客户端连接时刻
幻读本身不报错，也不抛异常，它安静地发生——最容易被忽略的，就是你在开发环境没并发写入，测试不出问题，上线后才暴露。
