mysql innodb status_MYSQL show engine innodb status 这么多年,你真的都懂?

转载:https://cloud.tencent.com/developer/article/1507132

Show engine innodb status  这个命令估计搞MYSQL的听见这个,第一个反应就是烂大街了。这个命令不会你就快回家吧?

OK  那show engine innodb status  展示了多少信息,这些信息对系统的状态的展示你有什么见解?  什么值能证明什么?  说到这里,估计快回家的就不少了。

作为一个不想回家的人,我这边的赶紧捋一捋这个 ,烂大街的命令。

1  show engine innodb status 到底展示了多少信息

background thread

semaphores

Latest detected Deadlock

transactions

file i/o

insert buffer and adaptive hash index

log

buffer pool and memory

individual buffer pool info

Row operations

本着学习一个东西,的深入的态度,一般的带着问题来学习

问题  1   当看到下面的信息后,第一个反应应该是什么

1620

这条 show engine innodb stauts  是无用的信息,为什么?  因为统计一个信息是需要一部分数据来进行计算和统计的,而 last 0 seconds 说明这样的操作数据不是有效的。这样的情况多见于,操作人员不停的执行命令造成的。

下面的信息是从信号量来说的

1620

这里面涉及了数据库与系统交互的一些信息,例如如果看到 os waits 比较大的情况,并且一直在增长的情况,说明 latch 锁征用的情况比较严重.

latch 锁是内存锁,是在一个小型的内存中保护list 的锁的内存结构。

其中他有几个特点 1 不进行排队的操作  2  一个thread 要获得一个latch,则如果这个latch 被占用则空转CPU 来等待这个锁的释放,如果释放后在下一次空转后,如果能获得latch 则进行下一步操作,如果不能则继续自旋。

os waits ,到底目前自旋了多少次。从这个角度可以看到的信息或推测的信息,是否有异常的SQL 造成latch 加重的情况。

下面的transactions 中,是根据当前的数据库的当前值和历史值来判断当前数据库的 purge 状态 以及 undo 等状态是否有异常。另外例如 history list lenght  中显示的UNDO 中未清理的事务数。

1620

同时他也显示的相关事务的连接的信息,如果连接太多,他可能会清除部分的信息,显示部分的最近的信息。

显示文件IO辅助线程的状态——插入缓冲区线程、日志线程、读线程和写线程。它们分别负责插入缓冲区合并、异步日志刷新、预读和脏缓冲区的刷新。

1620

这一片最主要的信息显示读取请求的平均大小。对于随机IO,这些应该是16K页大小,对于全表扫描或索引扫描提前读取,可以执行这些操作,这可以显著增加平均读取大小,通过avg bytes/read  fsyncs/s  等你可以了解到目前的系统的状态,以及数据库与系统之间的交互情况。

1620

1620

显示插入缓冲区和自适应哈希状态。第一行显示插入缓冲区的状态——段大小和空闲列表,以及是否有插入缓冲区的记录。接下来,它将显示在插入缓冲区中执行了多少插入、合并了多少recs以及合并了多少次。合并数与插入数之比在很大程度上是插入缓冲区效率。

其实插入缓存(现在应该叫change buffer),的使用率越高,则越正你添加change buffer 的必要性。change buffer 可以有效利用buffer 将一些与I/O可能频繁交互的操作,在buffer 中进行。

1620

上面这一段是比较重要的信息 ,LOG 信息。

其中通过 log  sequence number   log flushed up to   pages fulushed up to  last checkpoint at  等四个参数的信息对比就可以了解到目前系统可能存在的瓶颈或可能的问题。

例如如果未刷新的日志的数量已经占整体的数量的 20% - 30% 以上,你就要考虑你的innodb_log_buffer_size 到底是否需要调整。

1620

从这些信息看,可以了解到总的innodb buffer pool 获得的内存有多少,字典信息的buffer 多少, 以及到底目前innodb buffer pool 中使用了多少内存,以及一个重要的师表buffer hit (其他的数据库也有这样的信息,体现到底目前的内存状态)

最后的 row operations 展示了,一些关键的系统信息,例如从系统启动到现在到底插入了多少行 ,更新了多少行,等 并且以每秒的形式来显示,这些都是可以通过信息提取到监控系统中的。

1620

有的时候知识可能需要一遍遍的进行刷新,每一次的刷新都如果都能获得新的启发或建立更多的关联性,那刷新的时间必然是没有浪费的。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
要找到 `SHOW ENGINE INNODB STATUS` 命令输出的 InnoDB 存储引擎状态信息中某个线程所在的事务 ID,可以按照以下步骤进行: 1. 执行 `SHOW ENGINE INNODB STATUS\G` 命令,将 InnoDB 存储引擎状态信息以详细的方式输出到终端或客户端。 2. 在输出的状态信息中,找到 `LATEST FOREIGN KEY ERROR` 或 `LATEST DETECTED DEADLOCK` 部分。在这个部分中,通常会列出最近发生的死锁或外键错误的相关信息。 3. 在这个部分中,找到被称为“TRANSACTION”的部分。该部分会列出当前正在运行或等待的事务的详细信息,包括事务 ID、事务状态、锁定的对象等。 4. 在事务列表中找到您要查找的线程所在的事务。您可以根据线程 ID 在列表中查找到该事务,并在该事务的信息中找到事务 ID。 例如,以下是 `SHOW ENGINE INNODB STATUS\G` 命令输出的状态信息中事务列表的示例: ``` ------------ TRANSACTIONS ------------ Trx id counter 0 123456 Purge done for trx's n:o < 0 123455 undo n:o < 0 0 History list length 2 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 0 123455, ACTIVE 10 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 2 lock struct(s), heap size 360, 1 row lock(s) MySQL thread id 123, OS thread handle 0x7fb3b5c1d700, query id 1234 localhost root updating UPDATE `test` SET `value` = '123' WHERE `id` = 1 ------- TRX HAS BEEN WAITING 10 SEC FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 1234 page no 1 n bits 72 index `PRIMARY` of table `test` trx id 0 123455 lock_mode X waiting Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0 ``` 在这个例子中,事务列表中包含了当前正在运行的事务和等待锁定的事务。您可以根据线程 ID 查找到对应的事务,例如这里线程 ID 为 `123`,则可以在事务列表中找到该线程所在的事务,该事务 ID 为 `0 123455`。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值