锐客网

  1. 首页 > 生活百科 > it技术 > >

mysql怎么排查 mysql查询sid

IT技术正在

mysql 差异数据排查先把两个接口的查询语句各自创建一个独立表，再去查询在表1里面但是不在表2里面的数据，这样就把两个接口的 sql 查询出来的差异数据找出来，就可以根据数据关系去查找 bug 了 。
Mysql数据库CPU占用过高原因排查 show processlistmysql服务器最近偶尔出现cpu百分百居高不下的情况，所以需要进行分析
兄弟命令show processlist;只列出前100条，如果想全列出请使用show full processlist;
先 简单说一下各列的含义和用途：
正在将表中修改的数据刷新到磁盘中，同时正在关闭已经用完的表 。这是一个很快的操作，如果不是这样的话，就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中 。
Connect Out
复制从服务器正在连接主服务器 。
Copying to tmp table on disk
由于临时结果集大于 tmp_table_size ， 正在将临时表从内存存储转为磁盘存储以此节省内存 。
Creating tmp table
正在创建临时表以存放部分查询结果 。
deleting from main table
服务器正在执行多表删除中的第一部分，刚删除第一个表 。
deleting from reference tables
服务器正在执行多表删除中的第二部分，正在删除其他表的记录 。
Flushing tables
正在执行 FLUSH TABLES，等待其他线程关闭数据表 。
Killed
发送了一个kill请求给某线程，那么这个线程将会检查kill标志位，同时会放弃下一个kill请求 。MySQL会在每次的主循环中检查kill标志 位，不过有些情况下该线程可能会过一小段才能死掉 。如果该线程程被其他线程锁住了，那么kill请求会在锁释放时马上生效 。
Locked
被其他查询锁住了 。
Sending data
正在处理 SELECT 查询的记录，同时正在把结果发送给客户端 。
Sorting for group
正在为 GROUP BY 做排序 。
Sorting for order
正在为 ORDER BY 做排序 。
Opening tables
这个过程应该会很快，除非受到其他因素的干扰 。例如，在执 ALTER TABLE 或 LOCK TABLE 语句行完以前，数据表无法被其他线程打开 。正尝试打开一个表 。
Removing duplicates
正在执行一个 SELECT DISTINCT 方式的查询 ， 但是MySQL无法在前一个阶段优化掉那些重复的记录 。因此，MySQL需要再次去掉重复的记录，然后再把结果发送给客户端 。
Reopen table
获得了对一个表的锁，但是必须在表结构修改之后才能获得这个锁 。已经释放锁，关闭数据表，正尝试重新打开数据表 。
Repair by sorting
修复指令正在排序以创建索引 。
Repair with keycache
修复指令正在利用索引缓存一个一个地创建新索引 。它会比 Repair by sorting 慢些 。
Searching rows for update
正在讲符合条件的记录找出来以备更新 。它必须在 UPDATE 要修改相关的记录之前就完成了 。
Sleeping
正在等待客户端发送新请求.
System lock
正在等待取得一个外部的系统锁 。如果当前没有运行多个 mysqld 服务器同时请求同一个表，那么可以通过增加 --skip-external-locking参数来禁止外部系统锁 。
U pgrading lock
INSERT DELAYED 正在尝试取得一个锁表以插入新记录 。
Updating
正在搜索匹配的记录，并且修改它们 。
User Lock
正在等待 GET_LOCK() 。
Waiting for tables
该线程得到通知，数据表结构已经被修改了，需要重新打开数据表以取得新的结构 。然后，为了能的重新打开数据表，必须等到所有其他线程关闭这个表 。以下几种 情况下会产生这个通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, 或 OPTIMIZE TABLE 。
waiting for handler insert
INSERT DELAYED 已经处理完了所有待处理的插入操作，正在等待新的请求 。
大部分状态对应很快的操作，只要有一个线程保持同一个状态好几秒钟 ， 那么可能是有问题发生了 ， 需要检查一下 。
还有其他的状态没在上面中列出来，不过它们大部分只是在查看服务器是否有存在错误是才用得着 。
文章转自：
记一次Mysql故障排查(lock wait timeout exceeded;try restarting transaction)最近接了一个锅,进入新公司接手了一个进入交付阶段的项目.在code review的时候发现很多问题,然后开始修复bug.
在测试阶段突然发现几乎所有涉及到更新的操作都失败,下面贴出异常信息.
第一次 出现的时候百度了一下,猜想可能是多服务部署资源冲突,重启服务故障消失.所以没有特别重视
第二次 出现的时候只有测试环境部署,不存在多机资源冲突的问题,猜想是多线程资源交叉导致的,于是给可能导致资源竞争的地方加上了分布式锁.
由于无法重现故障,所以并没有确认问题得到解决.
第三次 故障依旧,当发现问题依然存在的时候,开始认真反思,发现自己解决问题的思路明显有问题,过于片面,一直都只在应用层面寻求解决问题的办法,而且解决问题的方式也只是在尝试百度出来的方法.并没有去思考更深层的问题.
在Mysql5.5中 ， information_schema 库中增加了三个关于锁的表（MEMORY引擎）；
INNODB_TRX ## 当前运行的所有事务
INNODB _LOCKS ## 当前出现的锁
INNODB_LOCK_WAITS ## 锁等待的对应关系
通过查询 INNODB_TRX 发现
当前事务中又两个RUNNING状态开始时间在一个小时之前
开始一直以为是锁表了
查看了INNODB_LOCKS事务信息之后发现有4行数据被锁住了一直没有释放
从这里开始发现问题了,应用已经抛了异常,事务理所当然的应该回滚才对,为什么资源依然没有释放,导致持续的阻塞呢?
其实最开始的异常信息就已经给出了答案,回到开始的地方,再看异常信息就很清楚了,应用里面的异常类是 MySQLTransactionRollBackException
是一个回滚异常, 这就说明在事务回滚的时候出了问题资源没有得到释放
然后开始查询 MySQLTransactionRollBackException相关的信息
这个时候innodb_rollback_on_timeout=0(默认配置)这个MySQL的配置开始进入我的视线,
举个栗子
事务在锁等待超时后是回滚事务内所有的statement还是最后一条语句；
0表示rollback最后一条语句，默认值； 有点坑爹啊( 细思极恐 )
1表示回滚事务内所有的statements；(此参数是只读参数，需在my.cnf中配置，并且重启生效；)
吃过一次亏,这次并没有盲目的相信百度到的信息
于是开始测试
一、验证innodb_rollback_on_timeout=off的情况
1.session A
开启事务,事务未提交,锁住id=1的数据
2.session B
开启事务,执行更新id=2的数据成功(事务未提交,锁住id=2),然后请求id=1等待锁超时,id=2的数据更改为222.
3.session C
请求id=2的数据50秒后显示等待锁超时
执行 SELECT * FROM information_schema.INNODB_TRX;
可发现有资源一直未释放,具体到测试数据中就是id=2的资源一直被锁定,线程一直被挂起.
总结:通过实验基本可以确定是业务资源交叉导致死锁之后资源没释放造成的持续阻塞，
【mysql怎么排查 mysql查询sid】二.验证innodb_rollback_on_timeout=on
修改配置后将验证innodb_rollback_on_timeout=off的步骤再走一遍
发现锁等待只能在业务层面尽量避免
on/off的区别在于session C进入时不会持续阻塞,session B异常后全部回滚
mysql之慢sql问题排查0、首先排除机器问题，如cpu、内存情况
1、根据日志找到sql语句，从两点，一是索引、二是语句的写法
2、使用mysql的explain 语句形式，排查是否引用索引 ， 通过key、extra，key表示有没有用到索引，用到的是哪个索引，像like、or等是索引失效的，extra using index表示覆盖索引，usingwhere表示where条件用到了索引，通过explain结果 ， 修改sql语句，该加索引加索引，该修改语句修改语句
3、语句编写上，子查询、关联查询大表小表
4、部署测试
mysql cpu暴涨快速排查方法标红的是mysql的线程id
解释：看事务表INNODB_TRX，里面是否有正在锁定的事务线程，看看ID是否在show processlist里面的sleep线程中，如果是，就证明这个sleep的线程事务一直没有commit或者rollback而是卡住了，我们需要手动kill掉 。
搜索的结果是在事务表发现了很多任务 ， 这时候最好都kill掉 。
批量删除事务表中的事务
我这里用的方法是：通过information_schema.processlist表中的连接信息生成需要处理掉的MySQL连接的语句临时文件，然后执行临时文件中生成的指令 。
kill掉以后再执行SELECT * FROM information_schema.INNODB_TRX; 就是空了 。
这时候系统就正常了
记一次mysql磁盘io高的问题排查现象是，系统里的java连接mysql超时了 ，
于是去mysql的机器，查看/var/log/messages日志，查对应的时间点的情况
发现mysql被阻塞了blocked for more than 120 seconds ， mysql的io非常之高，用top查看系统的负载也到达了50的样子
用mpstat查看cpu情况
好明显，都在等io
用iostat查看io情况，\util的值 ， 一直在80%，99%之间变化
以为磁盘有问题 ， 用dd测下速看看
从上面的结果看，也还好 ， 没问题
以为可能磁盘有坏道，用下面命令也扫了一遍 ， 没问题
结果也没有坏的块，这个过程，很耗时 。
用show processlist命令查看mysql正在忙着什么，一看，也没什么任务在执行的
想看看mysql，研究写哪个文件时，最耗时的
从上面结果来看，xxl_job是最耗时的 。知道点眉目了，因为公司的定时任务是用的xxljob ， 定时任务里，有每几秒执行的任务，我猜它的日志记录一定很大，于是查看一下
我的天，这个表的记录有千万?。。≌庑┘锹迹?没做定时任务来清理，由于都是一些没用的记录 ， 所以这个表的数据我全清了
清了之后，再用iostat查看
\util一下子就降下来了 ， 用iotop查看mysql进程的io也下降了
cpu的iowait也下降了
定义一个事件，让mysql定时清理30天前的日志记录
记录一下 ， 希望对有需要的朋友也起一点提示
mysql怎么排查的介绍就聊到这里吧，感谢你花时间阅读本站内容 ， 更多关于mysql查询sid、mysql怎么排查的信息别忘了在本站进行查找喔 。

    推荐阅读


    上一篇：服务器网络带宽测试 怎么测服务器宽带

    下一篇：像素飞行弹幕游戏，像素飞机射击游戏