【第30天】SQL进阶-查询优化- performance_schema系列实战五：查看最近的事务执行信息（SQL 小虚竹)

news2024/12/28 20:15:19

回城传送–》《32天SQL筑基》

文章目录

零、前言
一、查看最近的事务执行信息
- 数据准备（如果已有数据可跳过此操作）
- 开启第一个会话，配置启用事务事件
- 开启第二个会话，用于执行事务，并模拟事务回滚
- 第一个会话查询活跃事件
- 第二个会话回滚事务
- 第一个会话再查询活跃事务事件
- 第二个会话模拟事务正常提交
- 第一个会话再查询活跃事务事件
二、总结
三、参考

零、前言

今天是学习 SQL 打卡的第 30 天，每天我会提供一篇文章供群成员阅读（ 不需要订阅付钱 ）。

希望大家先自己思考，如果实在没有想法，再看下面的解题思路，自己再实现一遍。在小虚竹JAVA社区中对应的【打卡贴】打卡，今天的任务就算完成了，养成每天学习打卡的好习惯。

虚竹哥会组织大家一起学习同一篇文章，所以有什么问题都可以在群里问，群里的小伙伴可以迅速地帮到你，一个人可以走得很快，一群人可以走得很远，有一起学习交流的战友，是多么幸运的事情。

我的学习策略很简单，题海策略+ 费曼学习法。如果能把这些题都认认真真自己实现一遍，那意味着 SQL 已经筑基成功了。后面的进阶学习，可以继续跟着我，一起走向架构师之路。

今天的学习内容是：SQL进阶-查询优化- performance_schema系列实战五：查看最近的事务执行信息

一、查看最近的事务执行信息

慢查询日志可查询一个sql的执行时长，但在实际开发中，存在大事务执行回滚，或者异常终止。这时候是不会记录到慢查询日志里的

解决方案：借助performance_schema的events_transactions_*表进行查看事务相关的记录。

这些表中详细记录了是否有事务被回滚、活跃(长事件未提交的事务也属于活跃事件)或已提交

详细的说明，可以看这边，传送门：–》SQL进阶-查询优化- performance_schema系列三：事件记录（SQL 小虚竹)

数据准备（如果已有数据可跳过此操作）

使用sysbench准备初始化数据
创建测试数据库sysbenchdemo

create database sysbenchdemo;

在这里插入图片描述
准备测试数据：

sysbench /usr/share/sysbench/oltp_insert.lua \
--mysql-host=localhost \
--mysql-port=3306 \
--mysql-socket=/tmp/mysql.sock \
--mysql-user=root \
--mysql-password=xiaoxuzhu \
--mysql-db=sysbenchdemo \
--db-driver=mysql \
--tables=8 \
--table-size=100000 \
--time=180 prepare

在这里插入图片描述

开启第一个会话，配置启用事务事件

事务事件默认是没启用的
登录mysql数据库

use performance_schema;

在这里插入图片描述

update setup_instruments set enabled='yes',timed='yes' where name like 'transaction';

在这里插入图片描述

update setup_consumers set enabled='yes' where name like '%transaction%';

在这里插入图片描述
执行清理，避免其他事务干扰

truncate events_transactions_current;
truncate events_transactions_history;
truncate events_transactions_history_long;

在这里插入图片描述

开启第二个会话，用于执行事务，并模拟事务回滚

use sysbenchdemo;

在这里插入图片描述

begin;
update sbtest1 set pad='yyy' where id=1;

在这里插入图片描述

第一个会话查询活跃事件

select THREAD_ID,EVENT_NAME,STATE,TRX_ID,GTID,SOURCE,TIMER_WAIT,ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT,NESTING_EVENT_ID,NESTING_EVENT_TYPE from events_transactions_current;

在这里插入图片描述
正好一条，符合测试的情况。

第二个会话回滚事务

被回滚完成的事务不再活跃

rollback;

在这里插入图片描述

第一个会话再查询活跃事务事件

先查询活跃事件

select THREAD_ID,EVENT_NAME,STATE,TRX_ID,GTID,SOURCE,TIMER_WAIT,ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT,NESTING_EVENT_ID,NESTING_EVENT_TYPE from events_transactions_current;

在这里插入图片描述
我们从图上可知，查询的活跃事件已经没有了。当前的事件这条数据的状态已经是回滚状态。

第二个会话模拟事务正常提交

begin;
update sbtest1 set pad='yyy' where id=1;
commit;

在这里插入图片描述

第一个会话再查询活跃事务事件

select THREAD_ID,EVENT_NAME,STATE,TRX_ID,GTID,SOURCE,TIMER_WAIT,ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT,NESTING_EVENT_ID,NESTING_EVENT_TYPE from events_transactions_current;

在这里插入图片描述
事务事件记录中的事务事件为COMMITTED状态，表示事务已经提交成功。

注意：如果一个事务长时间未提交(长时间处于ACTIVE状态)，可以借助于information_schema.innodb_trx表来进行辅助判断

先在第二个会话开启一个事务。

begin;
update sbtest1 set pad='yyy' where id=1;

在这里插入图片描述

select * from information_schema.innodb_trx;

在这里插入图片描述
可以看到事务是什么时间点开始的。

二、总结

通过本文学习，掌握了如何查看最近的事务执行信息。通过两个会话之间的实战演练，清晰明了地展示了事务从开启到回滚时，通过performance_schema可以清楚地看到执行情况。
performance_schema的实战系列到今天为止介绍完成，后面有比较好的实战案例，会不定期地添加进来，如果您有不错的performance_schema实战案例，欢迎找我聊聊，可以一起探讨探讨。感谢大家的支持，让我们下文见。