SQL 中固定参数和状态查看
查看固定参数：
要查看MySQL的所有参数配置，可以使用以下SQL语句：
mysql> SHOW VARIABLES;
如果你想查看特定参数的配置，可以使用以下SQL语句：
mysql> SHOW VARIABLES LIKE '参数名';
显示MySQL的系统变量配置，包括当前的值和默认值。
mysql> SHOW GLOBAL VARIABLES;
查看状态：
通过 show status 命令了解 SQL 执行次数，如果使用 SQL 命令，可以使用 like 或者 where 条件来限制结果。like 可以对变量名做标准模式匹配。show status 命令中可以添加统计结果的级别，这个级别有两个
- session 级：默认当前链接的统计结果
- global 级：自数据库上次启动到现在的统计结果
如果不指定统计结果级别的话，默认使用 session 级别。
需要重视的参数指标：
我们日常最关注的参数是QPS、TPS、慢查询、线程池参数、连接数Connections、锁、索引、临时表数量、表缓存、缓冲池、日志相关（binlog、redolog）
1、Uptime：服务器的工作时间
展示Mysql服务器从启动到现在持续运行的时间
show status like 'uptime';
2、Com_ 为开头的参数
对于 show status 查询出来的统计结果，有两类参数需要注意下，一类是以 Com_ 为开头的参数（COM_ 这个类别代表着所有 MySQL 所执行过的指令），一类是以 Innodb_ 为开头的参数.
QPS（每秒Query数，针对于innodb存储引擎）
QPS需要结合时间（Uptime）来计算
show global status like 'Questions';
show global status like 'Uptime';
QPS=(Com_select+Com_insert+Com_update+Com_delete)/Uptime （针对MyISAM引擎为主的DB：QPS=questions/uptime）
其中：
Com_select：执行 select 操作的次数，一次查询会使结果 + 1。
Com_insert：执行 INSERT 操作的次数，对于批量插入的 INSERT 操作，只累加一次。
Com_update：执行 UPDATE 操作的次数。
Com_delete：执行 DELETE 操作的次数。
通过上述的参数可以了解当前数据库的应用是插入更新为主还是查询操作为主，以及各类的SQL的执行比例是多少。
TPS（每秒事务数，针对于innodb存储引擎）
TPS也需要结合时间（Uptime）来计算，通过Com_commit和Com_rollback可以了解事务提交和回滚的情况，对于回滚操作非常频繁的数据库，可能意味着应用编写存在的问题
show global status like 'Com_commit';
show global status like 'Com_rollback';
TPS=(Com_commit+Com_rollback)/Uptime
Com_commit：提交的执行次数
Com_rollback：回滚的执行次数
3、以 Innodb_ 为开头的参数
show global status like '%innodb_row_lock%';
Innodb_rows_read：执行 select 查询返回的行数。
Innodb_rows_inserted：执行 INSERT 操作插入的行数。
Innodb_rows_updated：执行 UPDATE 操作更新的行数。
Innodb_rows_deleted：执行 DELETE 操作删除的行数。
4、慢查询次数相关的状态量
show global status like '%slow_queries%';
5、线程池参数Threads_connected
当客户端请求的数据量比较大的时候，使用线程池可以节约大量的系统资源，使得更多的CPU时间和内存可以高效地利用起来。而数据库连接池的使用则将大大提高程序运行效率，同时，我们可以通过其自身的管理机制来监视数据库连接的数量、使用情况等。
show global status like 'threads_%';
Threads_cached：当前此时此刻线程缓存中有多少空闲线程
Threads_connected：代表当前已建立连接的数量，因为一个连接需要一个线程，也可以看成当前被使用的线程数
Threads_created：代表从最近一次服务启动，已经创建线程的数量
Threads_running：代表当前激活（非睡眠）的线程数
6、数据库的连接次数Connections
查看服务器默认最大连接数max_connections
Connections：试图连接到MySQL服务器的连接数
SHOW GLOBAL VARIABLES LIKE "max_connections";
查看当前服务器响应的最大连接数量max_used_connections
SHOW GLOBAL STATUS LIKE "max_used_connections";
Max_used_connections：服务器启动后已经同时使用的连接的最大数量（这个是连接的最大峰值，主要和参数max_connections（查看命令：SHOW VARIABLES LIKE 'max_connections';）对比来决定是否调整参数）max_connections参数为MySQL的最大连接数，如果服务器的并发连接请求量比较大，建议调高此值，以增加并行连接数量，max_connections设置范围理想状态是服务器响应的最大连接数max_used_connections占服务器上限连接数值比例的10%，如果在10%以下则说明max_connections设置过高。即max_used_connection / max_connections = 10% 当然这建立在机器能支撑的情况下，因为如果连接数越多， MySQL会为每个连接提供连接缓冲区，就会开销越多的内存，所以要适当调整该值，不能盲目提高设值。 数值过小会经常出现ERROR 1040: Too many connections错误，可以通过 mysql> show status like 'connections'; 通配符查看当前状态的连接数量
线程缓存命中率=1-Threads_created/Connections
7、锁相关的状态量
表级别的锁情况
show global status like '%table_lock%';
Table_locks_immediate：指的是能够立即获得表级锁的次数
Table_locks_waited：指的是不能立即获取表级锁而需要等待的次数，如果这个值比较高或者正在增加,那么表明存在严重的并发瓶颈，需要降低表级锁的调用频率
行级别的锁情况
show global status like '%innodb_row_lock%';
Innodb_row_lock_time：行锁定花费的总时间，单位毫秒
Innodb_row_lock_time_avg：行锁定的平均时间，单位毫秒
Innodb_row_lock_time_max：行锁定的最长时间，单位毫秒
Innodb_row_lock_waits：总共等待的次数
8、临时表的使用相关的状态量
MySQL用于存储一些中间结果集的表，临时表只在当前连接可见，当关闭连接时，Mysql会自动删除表并释放所有空间。为什么会产生临时表：一般是由于复杂的SQL导致临时表被大量创建
show global status like '%Created_tmp%';
Created_tmp_disk_tables ：服务器执行语句时自动在磁盘上创建的临时表的数量
Created_tmp_tables：服务器执行语句时自动在内存中创建的临时表的数量
Created_tmp_disk_tables /Created_tmp_tables值比较大时，可以尝试增加tmp_table_size的值大小
Created_tmp_files：创建临时文件的数目
9、表缓存相关的状态量
show global status like 'open_%';
Open_files：当前处于打开的文件数目（可以和参数open_files_limit参数量对比来调整参数）
Open_table_definitions：打开的.frm文件数目（可以和table_definition_cache参数量对比来调整参数）
Open_tables：当前处于打开的表数目（可以和table_open_cache参数量对比来调整参数）
如果是innodb表，可以和innodb_open_files（限制可以打开的.ibd文件数目）参数量对比来调整参数
10、缓冲池buffer pool相关的状态量
show global status like '%innodb_buffer_pool_wait%';
Innodb_buffer_pool_wait_free ：一般情况，通过后台向InnoDB缓冲池写。但是，如果需要读或创建页，并且没有干净的页可用，则它还需要先等待页面清空。该计数器对等待实例进行记数。如果已经适当设置缓冲池大小，该值应小；当这个值比较大时，说明需要增加buffer池的大小了
Innodb_buffer_pool_pages_total：缓冲池总的页数
Innodb_buffer_pool_pages_free：缓冲池空闲的页数
缓冲池的利用率=1 - Innodb_buffer_pool_pages_free/Innodb_buffer_pool_pages_total
Innodb_buffer_pool_read_requests:从缓存池读取的次数，逻辑读
Innodb_buffer_pool_reads：从物理磁盘读取的次数，物理读
缓冲池的读命中率=1 - Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests
11：索引参数
show global status like 'select%';
Select_full_join：没有使用索引的联接的数量
Select_full_range_join ：在引用的表中使用范围搜索的联接的数量
Select_range：利用第一个数据表上的某个区间而完成的多数据表联接操作的次数
Select_range_check：该变量记录了在联接时,对每一行数据重新检查索引的查询计划的数量,它的开销很大，如果该值较高或正在增加,说明一些查询没有找到好索引
Select_scan：通过对第一个数据表进行全表扫描而完成的多数据表联接操作的次数
12、日志相关的状态量
二进制日志binlog
show global status like '%binlog%';
Binlog_cache_disk_use：表示binlog_cache_size的不足导致的缓存二进制日志使用到了临时文件的次数
Binlog_cache_use：使用binlog_cache_size缓存的次数
Binlog_cache_disk_use/Binlog_cache_use值比较大时，可以尝试增加binlog_cache_size的值大小
事务日志redolog
show global status like '%Innodb_log_waits%';
Innodb_log_waits ：因log_buffer不足导致等待的次数，此值较大时，考虑尝试增加innodb_log_buffer_size值大小
常见的错误排查方法：
Too many connections故障：
CPU瞬间爆满，MySQL数据库爆出too many connection错误， MySQL ERROR日志报出[Warning] Too many connections，操作日志爆出Kernal: TCP: time wait bucket table overflow
MySQL连接允许长连接和短连接，其自身建立连接的过程存在较大开销，所以一般会采用长连接。但使用长连接后可能会占用内存增多，因为MySQL在执行查询过程中临时使用内存管理连接对象，这些连接对象资源只有在连接断开时才会释放。如果长连接累计很多将导致内存占用加大而被系统强制KILL而发生MySQL服务异常重启的现象。
排查连接已满的相关因素：
1：空闲连接过多
*当应用使用长连接模式，此时应用侧应配置连接池，连接池的初始连接数量如果设置过高，应用启动后会建立多个到数据库实例的空闲连接。
*当应用使用短连接模式，若出现大量空闲连接则说明应用没有在查询执行完毕后显式的关闭连接。
2：活动连接过多
*慢查询SQL增加将导致活动连接数堆积
*锁等待将导致活动连接数堆积，包括InnoDB锁等待，Metadata表元数据锁等待。
*CPU使用率过高将导致活动连接堆积
*IOPS（每秒IO吞吐量）使用率过高将导致活动连接堆积如何分析：
数据库内部参数观测：
参数设置导致的因素：
查看当前数据库建立的连接数量
1、查看服务器默认最大连接数max_connections
SHOW GLOBAL VARIABLES LIKE "max_connections";
查看当前服务器响应的最大连接数量max_used_connections
SHOW GLOBAL STATUS LIKE "max_used_connections";
如果 max_connections设置过低，可以通过set GLOBAL max_connections=xxx;设置
可以分析数据库线程数量作为辅助
2、查看当前连接数即数据库线程数量Threads_connected，缓存池数连接线程数量是否过高，是否没有空闲线程
show global status like 'threads_%';
3、执行show processlist线程分析
使用SHOW PROCESSLIST将会展示最近的100条线程，其中不包含background thread后台线程，因此可认为线程数约等于连接数。如果想全列出请使用show full processlist; 如果您有SUPER权限，您可以看到所有线程。否则，您只能看到您自己的线程（也就是，与您正在使用的MySQL账户相关的线程）。
使用SHOW PROCESSLIST查看MySQL正在执行的线程，发现是否具有大量sleep休眠和timeout超时的线程。使用kill杀掉所有sleep或timeout的线程，观察连接数是否又会暴增。排除空闲连接过多导致的报错
Id ：Id 就是一个标示，在我们使用 kill 命令杀死进程的时候很有用，比如 kill 进程号。
User：显示当前的用户，如果不是 root，这个命令就只显示你权限范围内的 SQL 语句。
Host：显示 IP ，用于追踪问题
Db：显示这个进程目前连接的是哪个数据库，为 null 是还没有 select 数据库。
Command：显示当前连接锁执行的命令，一般有三种：查询 query，休眠 sleep，连接 connect。
Time：这个状态持续的时间，单位是秒
State：显示当前 SQL 语句的状态，非常重要，下面会具体解释。
Info：显示这个 SQL 语句。state属性是processlist中分析性能的关键部分。可以判断sql执行时的底层运作，进而定位到深层的问题，比如网络吞吐量不够、磁盘I/O压力过大、CPU计算较多、内存紧张等瓶颈。再结合processlist.info的explain结果，问题就可以定位到结果集过大、索引不理想检索行过多、排序较多、临时表过多过大的问题。
常见状态分析：
Sending data
线程正在读取和处理SELECT语句的行 ，并将数据发送到客户端。由于在此状态期间发生的操作往往会执行大量磁盘访问（读取），因此它通常是给定查询生命周期中运行时间最长的状态。如果在这个状态持续的时间比较久，需要拿到processlist.info，通过explain进一步定位问题。常见的问题有下面几种：
1、索引不理想、导致回表较多，磁盘压力大、一直在等待磁盘读完数据；可通过explain的rows看到特征
2、文件排序等待，特征是cpu会变高；可通过explain的extra看到特征
closing tables
该线程正在将更改的表数据刷新到磁盘并关闭已使用的表。这应该是一个快速的操作。如果没有，请验证您没有完整磁盘并且磁盘使用不是很大.磁盘不足的重要状态。
Copying to tmp table on disk
服务器正在复制到磁盘上的临时表。临时结果集变得太大（“MySQL中的内部临时表使用”，超过tmp_table_size）。因此，线程正在将临时表从内存更改为基于磁盘的格式以节省内存。
配置的临时表空间不足时，临时表会从内存写入磁盘，这个动作比较耗时。
相关的状态还有Creating tmp table： 该线程正在内存或磁盘上创建临时表。如果表在内存中创建但稍后转换为磁盘表，则该操作期间的状态将为Copying to tmp table on disk
Updating
线程正在搜索要更新的行并正在更新它们.
一般情况下update因为有主键约束会很快，但有一种情况发生时，会导致update等待严重： 有一个update语句没有走上唯一索引，进行了索引扫描，扫描时索引行是被锁住的，其他更新只能等待。
Writing to net
服务器正在将数据包写入网络.
注意数据库服务器的网络吞吐量是否超限或网络环境较差，或者是否返回的数据太多了。SQL语句导致：
通过 EXPLAIN 命令分析 SQL 的执行计划
通过以上步骤查询到效率低的 SQL 语句后，可以通过 EXPLAIN 或者 DESC 命令获取 MySQL 如何执行 SELECT 语句的信息，包括在 SELECT 语句执行过程中表如何连接和连接的顺序。
上表中涉及内容如下：
（1）select_type：表示常见的 SELECT 类型：
SIMPLE 表示的是简单的 SQL 语句，不包括 UNION 或者子查询操作
PRIMARY ，查询中最外层的 SELECT（如两表做 UNION 或者存在子查询的外层的表操作为 PRIMARY，内层的操作为 UNION），比如下面这段子查询。
UNION，在 UNION 操作中，查询中处于内层的 SELECT（内层的 SELECT 语句与外层的 SELECT 语句没有依赖关系时）。
SUBQUERY：子查询中首个SELECT（如果有多个子查询存在），如我们上面的查询语句，子查询第一个是 sr（sys_role）表，所以它的 select_type 是 SUBQUERY。
（2）table ，这个选项表示输出结果集的表。
（3）type 这个字段会牵扯到连接的性能，它的不同类型的性能由好到差,关于 type 我们经常会在 SQL 调优的环节使用 explain 分析其类型，然后改进查询方式，越靠近 system 其查询效率越高，越靠近 all 其查询效率越低。
system ：表中仅有一条数据时，该表的查询就像查询常量表一样。
const ：当表中只有一条记录匹配时，比如使用了表主键（primary key）或者表唯一索引（unique index）进行查询。
eq-ref ：表示多表连接时使用表主键或者表唯一索引，比如select A.text, B.text where A.ID = B.ID,这个查询语句，对于 A 表中的每一个 ID 行，B 表中都只能有唯一的 B.Id 来进行匹配时。
ref ：这个类型不如上面的 eq-ref 快，因为它表示的是因为对于表 A 中扫描的每一行，表 C 中有几个可能的行，C.ID 不是唯一的。
ref_or_null ：与 ref 类似，只不过这个选项包含对 NULL 的查询。
index_merge ：查询语句使用了两个以上的索引，比如经常在有 and 和 or 关键字出现的场景，但是在由于读取索引过多导致其性能有可能还不如 range（后面说）。
unique_subquery ：这个选项经常用在 in 关键字后面，子查询带有 where 关键字的子查询中，用 sql 来表示就是这样value IN (SELECT primary_key FROM single_table WHERE some_expr)
range ：索引范围查询，常见于使用 =，<>，>，>=，<，<=，IS NULL，<=>，BETWEEN，IN() 或者 like 等运算符的查询中。
index ：索引全表扫描，把索引从头到尾扫一遍。
all ： 这个我们接触的最多了，就是全表查询，select * from xxx ，性能最差。语句优化总结：
1、in 和 not in 要慎用
SQL语句中IN包含的值不应过多，MySQL对于IN做了相应的优化，即将IN中的常量全部存储在一个数组里面，而且这个数组是排好序的。但是如果数值较多，产生的消耗也是比较大的。再例如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
再或者使用连接来替换。
2、少用select *
SELECT语句务必指明字段名称，select * 增加很多不必要的消耗（CPU、IO、内存、网络带宽）；
3、善用limit 1
这是为了使explain中type列达到const类型。当只需要一条数据的时候，使用limit 1，如果加上limit1，查找到就不用继续往后找了。
4、order by字段建索引
避免全表扫描，首先应考虑在 where 及 order by涉及的列上建立索引，如果排序字段没有用到索引，就尽量少排序
5、count()推荐使用
按照效率排序的话，count(字段)<count(主键 id)<count(1)≈count()，推荐使用count()
6、where 子句中避免is null /is not null
select id from t where num is null
应尽量避免在 where 子句中对字段进行 null 值判断，使用is null 或者is not null 理论上都会走索引,存在Null值会导致mysql优化器处理起来比较复杂，容易导致引擎放弃使用索引而进行全表扫描。
7、应尽量避免在 where!=
8、避免%xxx式查询
9、选择重复值较低的字段建索引
10、join使用问题
用连接查询代替子查询、join表不易超过3个、小表驱动大表、链接字段建索引。（4）possible_keys ：表示查询时，可能使用的索引。
（5）key ：表示实际使用的索引。
（6）key_len ：索引字段的长度。
（7）rows ：扫描行的数量。
（8）extra ：执行情况的描述。
索引分析
索引都有哪些分类
全局索引(FULLTEXT)：全局索引，目前只有 MyISAM 引擎支持全局索引，它的出现是为了解决针对文本的模糊查询效率较低的问题，并且只限于 CHAR、VARCHAR 和 TEXT 列。
哈希索引(HASH)：哈希索引是 MySQL 中用到的唯一 key-value 键值对的数据结构，很适合作为索引。HASH 索引具有一次定位的好处，不需要像树那样逐个节点查找，但是这种查找适合应用于查找单个键的情况，对于范围查找，HASH 索引的性能就会很低。默认情况下，MEMORY 存储引擎使用 HASH 索引，但也支持 BTREE 索引。
B-Tree 索引：B 就是 Balance 的意思，BTree 是一种平衡树，它有很多变种，最常见的就是 B+ Tree，它被 MySQL 广泛使用。
R-Tree 索引：R-Tree 在 MySQL 很少使用，仅支持 geometry 数据类型，支持该类型的存储引擎只有MyISAM、BDb、InnoDb、NDb、Archive几种，相对于 B-Tree 来说，R-Tree 的优势在于范围查找。
逻辑类型：
普通索引：普通索引是最基础的索引类型，它没有任何限制 。创建方式如下
唯一索引：唯一索引列的值必须唯一，允许有空值，如果是组合索引，则列值的组合必须唯一，创建方式如下
主键索引：是一种特殊的索引，一个表只能有一个主键，不允许有空值。一般是在建表的时候同时创建主键索引。
组合索引：指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循最左前缀原则，下面我们就会创建组合索引。
全文索引：主要用来查找文本中的关键字，而不是直接与索引中的值相比较，目前只有 char、varchar，text 列上可以创建全文索引，创建表的适合添加全文索引
分析操作：
如果 where 条件使用了 like 查询， % 不在第一个字符，索引才可能被使用。
explain select * from cxuan005 where id like '%1';
explain select * from cxuan005 where id like '1%';
对于复合索引来说，只能使用 id 进行 like 查询，因为 hash 列不管怎么查询都不会走索引。
create index id_hash_index on cxuan005(id,hash);
explain select * from cxuan005 where id = '333';
如果 where 条件的列参与了计算，那么也不会使用索引
explain select * from cxuan005 where id + '111' = '666';
索引列使用函数，一样也不会使用索引
explain select * from cxuan005 where concat(id,'111') = '666';
数据库死锁导致：
查询当前正在锁的事务
SELECT * FROM information_schema.innodb_locks;
查询等待锁的事务
SELECT * FROM information_schema.innodb_lock_waits;
表损坏导致：
使用CHECK TABLE table_name查询表是否有损坏，则使用REPAIR TABLE table_name修复表。
analyze table
optimize table xxx;
操作系统层面：
还是之前的问题：linux系统参数问题导致的connections错误：数据库无法连接，报错：“ERROR 1040(HY000): Too many connections”
故障定位
数据库自己其实是有一个连接池的，你的每个系统部署在一台机器上的时候，那台机器上部署额系统实例自己也是有一个连接池的，系统每个连接socket都对应着数据库连接池中的一个连接socket，这就是TCP网络连接。所以当数据库报错Too many connections的时候，就是说连接池已经满了，业务系统不能跟它建立更多的连接了！
查看参数：show variables like ‘max_connections’，如果发现当前MySQL仅仅只是建立了很少的链接，远不足我们配置中的max_connections，但是依然会有此报错，则可以认为因为底层的linux操作系统把进程可以打开的文件句柄数限制为1024了，导致MySQL最大连接数时214
解决方法：
linux默认会限制每个进程对机器资源的使用的，包括可以打开的文件句柄的限制，可以打开的子进程数的限制，最大可以锁定的内存大小
max locked memory就是最大锁定内存大小
open files就是最大可以打开的文件句柄数量、
max user processes就是最多可以拥有的子进程数量
如果linux限制一个进程的文件句柄太少的话，就会导致我们没办法创建大量的网络连接。所以说，往往在生产环境部署了一个系统，比如数据库系统、消息中间件系统、存储系统、缓存系统之后，都需要调整一下linux的一些内核参数，这个文件句柄的数量是一定要调整的，通常都得设置为65535
临时修改：
ulimit -HSn 65535
永久配置文件
vim /etc/security/limits.conf
* soft nofile 65535
* soft nofile 65535重启服务器
MYSQL 常见的监控指标：
监控指标大致可以分为：
系统级别监控：
CPU/内存
磁盘使用率
IOPS
吞吐量
存储引擎和参数级别：
TPS/QPS
临时表
线程
内存页
刷盘次数
InnoDB Data 读写吞吐量
Buffer Pool 请求次数
InnoDB Redo 写次数
行锁
主从同步：
节点复制线程状态(io线程和 SQL线程)
节点复制延迟(second)系统级别监控：
MySQL CPU/内存 利用率
磁盘使用率(%)
IOPS使用率和 IOPS（MySQL读写次数）
流量吞吐(KB)
mysql.bytes_received：平均每秒从所有客户端接收到的字节数
mysql.bytes_sent：平均每秒发送给所有客户端的字节数
存储引擎和参数级别
TPS/QPS
qps：计算公式：Queries / Uptime
tps：计算公式：(Com_insert + Com_insert_select + Com_update + Com_update_multi + Com_delete_multi + Com_delete + Com_replace + Com_replace_select) / Uptime
DDL_ps：每秒DDL次数
MySQL存储空间使用量(MB)
会话连接：
mysql.total_session：当前全部会话
mysql.active_session：当前活跃会话
执行次数：
临时表
线程
mysql.threads_connected：当前全部线程数
mysql.threads_running：当前活跃线程数
连接数利用率(%/count)
mdl_lock_session：mdl锁阻塞的连接数
conn_usage：连接数利用率
MySQL_SelectScan：执行全表搜索查询的数量
刷盘次数：
mysql.innodb_data_fsyncs：InnoDB 平均每秒fsync操作次数
内部查看：show status like '%fsyncs%';
InnoDB Data 读写吞吐量(KB/B)
mysql.innodb_data_written：InnoDB 平均每秒写字节数
mysql.innodb_os_log_written：InnoDB每秒写入redo log日志量(B)
mysql.innodb_data_read：InnoDB 平均每秒读字节数
InnoDB Buffer Pool 请求次数
mysql.innodb_buffer_pool_reads_requests：InnoDB 平均每秒从Buffer Pool读取页的次数（逻辑读）
mysql.innodb_buffer_pool_write_requests：InnoDB 平均每秒往Buffer Pool写入页的次数
InnoDB Buffer Pool 命中率
mysql.innodb_bp_dirty_pct：InnoDB Buffer Pool 脏页比率；计算公式：Innodb_buffer_pool_pages_dirty / Innodb_buffer_pool_pages_data * 100%
mysql.innodb_bp_hit：InnoDB Buffer Pool 读缓存命中率；计算公式：(Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100%
mysql.innodb_bp_usage_pct：InnoDB Buffer Pool 使用率；计算公式：innodb_buffer_pool_pages_data / ( innodb_buffer_pool_pages_data + innodb_buffer_pool_pages_free ) * 100%
InnoDB Redo 写次数
mysql.innodb_log_writes：Innodb 平均每秒物理写Redo Log File次数
mysql.innodb_os_log_fsyncs：平均每秒向日志文件完成的fsync()写数量。
InnoDB Row Operations
mysql.innodb_rows_deleted：InnoDB 平均每秒删除的行数
mysql.innodb_rows_read：InnoDB 平均每秒读取的行数
mysql.innodb_rows_inserted：InnoDB 平均每秒插入的行数
mysql.innodb_log_writes：Innodb 平均每秒物理写Redo Log File次数
mysql.innodb_rows_updated：InnoDB 平均每秒更新的行数
内存页：
mysql.innodb_buffer_pool_pages_flushed
InnoDB Buffer Pool 刷Page请求数量
行锁
节点复制线程状态
mysql.slave_io_running：读取源二进制日志的I/O线程是否正在运行
mysql.slave_sql_running：执行中继日志中事件的SQL线程是否正在运行
节点复制延迟(second)
取值来源：
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0其中Seconds_Behind_Master大体认为是主从数据库的延时
发布者：LJH，转发请注明出处：https://www.ljh.cool/6691.html
