orzdba 监控获取/输出全解【原理系列】

以你之姓@ 2023-07-05 13:29 26阅读 0赞

orzdba好用的不要不要的

##### threads #####

*  run：Threads\_running
 *  con：Threads\_connected
 *  cre：Threads\_created
 *  cac：Threads\_cached

------threads------
     run  con  cre  cac|
       0    0    0    0|
     200  202    0    0|
     201  202    0    0|
     201  202    0    0|
     201  202    0    0|

##### innodb\_hit #####

*  lor : Innodb\_buffer\_pool\_read\_requests \[innodb进行逻辑读的数量。单位是次数\]
 *  hit : (Innodb\_buffer\_pool\_read\_requests - Innodb\_buffer\_pool\_reads\[读磁盘次数\]) / Innodb\_buffer\_pool\_read\_requests \* 100%

-Hit%-
    |     lor    hit|
    |       0 100.00|
    |  385098  98.00|
    |  392831  98.01|

##### innodb\_rows #####

*  innodb\_rows\_inserted\_diff : innodb\_rows\_inserted
 *  innodb\_rows\_updated\_diff ：innodb\_rows\_updated
 *  innodb\_rows\_deleted\_diff ：innodb\_rows\_deleted
 *  innodb\_rows\_read\_diff ：innodb\_rows\_read

---innodb rows status---
      ins   upd   del   read|
        0     0     0      0|
     1717  3430  1718 715111|
     1728  3439  1723 717916|

##### innodb\_data #####

*  reads：Innodb\_data\_reads 次数
 *  writes：innodb\_data\_writes 次数
 *  read：Innodb\_data\_read 字节
 *  written：Innodb\_data\_written 字节

-----innodb data status----
     reads writes  read written|
         0      0      0      0|
      8220   5043 128.4m 106.3m|
      8091   5139 126.4m 108.6m|
      8089   5148 126.4m 109.3m|

##### innodb\_log #####

*  fsyncs：Innodb\_os\_log\_fsyncs 记录往磁盘上写日志的次数
 *  written：innodb\_os\_log\_written 日志刷盘的字节数，如果在commit不怎么变化的情况下，这个值出现暴增，说明系统出现大事务了（处理：kill线程，必要情况kill掉mysql进程）。写入redo logfile中的字节量

--innodb log--
    fsyncs written|
         0       0|
      1701    3.9m|
      1708    4.1m|
      1716    3.9m|

##### innodb\_status #####

获取方式：**show engine innodb status**

*  his
    
     *  list : 取值方式：`history list length` innodb的history list长度代表了有多少undo日志还没有被清理掉。如果发现history list的长度越大，要么就是实例的复杂非常高，要么就是可能有大查询，或者事务没提交，导致Undo log无法分析
 *  log(byte)
    
     *  uflush：= (Log sequence number)-(Log flushed up to) ：没有刷新到redolog的文件大小
     *  uckpt：= (Log sequence number)-(Last checkpoint at) ：没有落盘的redo大小
 *  read
    
     *  view ：`read views open inside InnoDB`。有多少read view被打开了，一个read view是一致性保证的MVCC “snapshot”
 *  query
    
     *  inside ：有多少线程在Innodb内核
     *  que ：队列长度

his --log(byte)--  read ---query---
     list uflush  uckpt  view inside  que|
      566     1k  891.9m  191     4   193|
      757     2k  894.9m  189     5   194|
      529     3k  898.0m  193     3   194|
      427    503  880.6m  190     1   193|
    
    
    ---
    LOG
    （Innodb 事务日志相关信息，包括当前的日志序列号（Log sequence number），已经刷新同步到那个序列号，最近的check point到那个序列号了。除此之外，还显示了系统从启动到现在已经做了多少次check point，多少次日志刷新。）
    ---
    （注：小括号为官方解释。）
    Log sequence number 2560255（当前的日志序列号）
    Log flushed up to   2560255（刷新到日志重做日志文件的lsn）
    Pages flushed up to 2560255（写入磁盘的脏页的lsn。记录在checkpoint中）
    Last checkpoint at 2560246（刷新到磁盘的lsn）
    
     --------------
     ROW OPERATIONS
     --------------
     2 queries inside InnoDB, 0 queries in queue
     2 read views open inside InnoDB
     Main thread process no. 7969, id 1191348544, state: sleeping
     Number of rows inserted 287921794, updated 733493588, deleted 30775703, read 2351464150250
     5.10 inserts/s, 29.38 updates/s, 0.02 deletes/s, 51322.87 reads/s

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4_size_16_color_FFFFFF_t_70]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200215165528811.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NoZW4yMzA4,size_16,color_FFFFFF,t_70