背景描述
最近遇到多次业务方，反馈数据写入成功，但是需要查询使用时，数据确找不到了，所以需要确认数据什么不见了？
排查方案
- 通过应用排查数据是否写入成功。
- 通过应用确认每次都是写入成功.
- 而且写入后，进行查询都是有数据的。
- 通过主键自增确认写入过数据。
- 确认主键自增都是有的，但是最后数据不见了。
- 查看binlog是否有提交记录。
- 确认binlog中没有相应的提交记录，说明最终没有提交成功。
- 通过SQL洞察和审计最终确认原因。（重点）
SQL洞察和审计
RDS MySQL的SQL洞察和审计由数据库自治服务DAS提供，在全量请求和安全审计的基础上，融合了搜索、SQL洞察、安全审计以及流量回放和压测等功能，帮助您更好地获取SQL语句的具体信息、排查各种性能问题、识别高危风险来源、验证实例规格。
支持版本范围
- RDS MySQL实例为高可用版、三节点企业版或集群版。
支持SQL记录
- 开启SQL洞察和审计功能可以记录所有DQL、DML和DDL操作信息，这些信息是通过数据库内核输出，对系统CPU消耗极低。
SQL洞察与Binlog日志的区别
- 类似于MySQL的审计日志，会统计所有DQL、DML和DDL操作信息，这些信息是系统通过网络协议分析所得。
- SQL洞察不解析实际的参数值，在SQL查询量较大的时候会丢失少量记录。因此通过这种方式来统计增量数据可能会出现不准确的情况。
- SQL洞察是在开始执行时就记录了，所以在显示提交事务时，若最后回滚或退出，就会出现数据没有，但是SQL洞察是有执行记录的。
- 准确记录数据库所有的增、删、改操作信息以及恢复用户的增量数据。
- Binlog是在事务commit时才会记录，所以binlog中记录的，一定是已经提交的记录。
实战场景
在事务中，插入数据，然后执行进行插入数据，最后没有commit，最终数据没有被提交。
1. 测试表：
CREATE TABLE `t11` (
`c1` int NOT NULL AUTO_INCREMENT,
`c2` varchar(100) DEFAULT NULL,
`c3` varchar(100) DEFAULT NULL,
PRIMARY KEY (`c1`),
KEY `idx_c2` (`c2`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb3 COMMENT='TEST';
2. 执行的测试SQL：
set autocommit=0;
insert into t11(c2,c3)values('a','b');
commit;
insert into t11(c2,c3)values('a2','b2');
rollback;
insert into t11(c2,c3)values('a3','b3');
exit3. 控制台SQL洞察分析
- 搜索条件
探索条件使用得当可以快速找到问题原因。本次探索条件都是跟事务操作有关：
Login：登录操作；
LOGOUT：登出操作；
SET：环境变量操作；
ROLLBACK：未提的事务回滚；
COMMIT：提交事务；
线程ID：可以查看整个线程的操作逻辑
- 通过上面的搜索条件，获取关键数据
- 结论：
通过SQL洞察与审计最终可以确定数据为什么不见了！
QA
Q：什么情况会导致出现rollback和没提交就退出了。
A：
- 业务代码缺陷，导致最终没有提交事务就自动退出或回滚了。
- SQL锁冲突，当会导致其它一个会话回滚。
- 会话没有最终执行commit操作就退出了。
解决方案：
- 优化调整业务逻辑，避免代码缺陷或锁冲突。
- 业务上在出现异常时，保留关键的日志，可以快速定位问题。
