问题背景： 用户的rds数据库，最近出现了这样一个问题：没有使用读写分离，提交一个update语句修改状态值，修改之后，当时查不到修改后的值，查到的还是修改前的值，过了2小时之后才可以查到，审计日志看sql语句是更新成功的。
以下是用户提供的截图信息
问题分析: 通过截图可以看到将invest_status状态值修改为3，但是navica 查到的还是修改前的值2。
解析binlog看，日志里确实有执行成功过update，看用户的截图。binlog信息里看### @13=3 / INT meta=0 nullable=1 is_null=0 / 该字段确实修改了。
现场排查： 下午用户侧复现问题，联系我们继续分析，还是做了update但是查不到结果。SQL语句是这样的：
UPDATE project_periods SET return_time=1563166809672 , return_status = 2 , update_time = 1563166809672 WHERE pro_id = 104 and new_period = 5
查询时候确实没有被更新
审计日志里看当时确实update过这个sql
分析：SQL审计里我们看到的SQL语句，是执行过，但是未必提交，因此还需进一步分析
select * from information_shema.innodb_trx ，发现有与用户反馈时间一致的一个线程处于running状态，并未被提交
show processlist可以看到该SQL线程15833244
说明正如分析所说，事务还未提交，而RDS的默认隔离级别是RC，如果不在一个事务里查询，事务提交之前其他会话看不到，RC隔离级别是提交读，也就是提交后，其他会话才能查到。过了2小时左右事务被提交，审计里看到了该SQL线程15833244 commit
用户侧确认是框架修改后，事务自动提交部分有变导致的，问题解决。
附上事务隔离级别说明，RDS默认隔离级别RC：