回城传送–》《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实战案例，欢迎找我聊聊，可以一起探讨探讨。感谢大家的支持，让我们下文见。
三、参考
应用示例荟萃 | performance_schema全方位介绍（下）SQL进阶-查询优化- performance_schema系列三：事件记录（SQL 小虚竹)
我是虚竹哥，我们明天见~