Mysql统计信息
MySQL执行SQL会经过SQL解析和查询优化的过程，解析器将SQL分解成数据结构并传递到后续步骤，查询优化器发现执行SQL查询的最佳方案、生成执行计划。查询优化器决定SQL如何执行，依赖于数据库的统计信息，下面我们介绍MySQL 5.7中innodb统计信息的相关内容。
MySQL统计信息的存储分为两种，非持久化和持久化统计信息。
一、非持久化统计信息
非持久化统计信息存储在内存里，如果数据库重启，统计信息将丢失。有两种方式可以设置为非持久化统计信息：
1全局变量，
INNODB_STATS_PERSISTENT=OFF
2 CREATE/ALTER表的参数，
STATS_PERSISTENT=0
非持久化统计信息在以下情况会被自动更新：
1执行ANALYZE TABLE
2 innodb_stats_on_metadata=ON情况下，执SHOW TABLE STATUS, SHOW INDEX, 查询 INFORMATION_SCHEMA下的TABLES, STATISTICS
3 启用--auto-rehash功能情况下，使用mysql client登录
4 表第一次被打开
5 距上一次更新统计信息，表1/16的数据被修改
非持久化统计信息的缺点显而易见，数据库重启后如果大量表开始更新统计信息，会对实例造成很大影响，所以目前都会使用持久化统计信息。
二、持久化统计信息
5.6.6开始，MySQL默认使用了持久化统计信息，即INNODB_STATS_PERSISTENT=ON，持久化统计信息保存在表mysql.innodb_table_stats和mysql.innodb_index_stats。
持久化统计信息在以下情况会被自动更新：
1INNODB_STATS_AUTO_RECALC=ON
情况下，表中10%的数据被修改
2增加新的索引
innodb_table_stats是表的统计信息，innodb_index_stats是索引的统计信息，各字段含义如下：
mysql> describe mysql.innodb_table_stats;
+--------------------------+---------------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+--------------------------+---------------------+------+-----+-------------------+-----------------------------+
| database_name | varchar(64) | NO | PRI | NULL | |
| table_name | varchar(199) | NO | PRI | NULL | |
| last_update | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| n_rows | bigint(20) unsigned | NO | | NULL | |
| clustered_index_size | bigint(20) unsigned | NO | | NULL | |
| sum_of_other_index_sizes | bigint(20) unsigned | NO | | NULL | |
+--------------------------+---------------------+------+-----+-------------------+-----------------------------+
6 rows in set (0.00 sec)
mysql> describe mysql.innodb_index_stats;
+------------------+---------------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+------------------+---------------------+------+-----+-------------------+-----------------------------+
| database_name | varchar(64) | NO | PRI | NULL | |
| table_name | varchar(199) | NO | PRI | NULL | |
| index_name | varchar(64) | NO | PRI | NULL | |
| last_update | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| stat_name | varchar(64) | NO | PRI | NULL | |
| stat_value | bigint(20) unsigned | NO | | NULL | |
| sample_size | bigint(20) unsigned | YES | | NULL | |
| stat_description | varchar(1024) | NO | | NULL | |
+------------------+---------------------+------+-----+-------------------+-----------------------------+
8 rows in set (0.00 sec)
stat_name=n_leaf_pages时：stat_value表示叶子节点的数量
stat_name=n_diff_pfxNN时：stat_value表示索引字段上唯一值的数量，此处做一下具体说明：
1、n_diff_pfx01表示索引第一列distinct之后的数量，如PRIMARY的a列，只有一个值1，所以index_name='PRIMARY' and stat_name='n_diff_pfx01'时，stat_value=1。
2、n_diff_pfx02表示索引前两列distinct之后的数量，如i2uniq的e,f列，有4个值，所以index_name='i2uniq' and stat_name='n_diff_pfx02'时，stat_value=4。
3、对于非唯一索引，会在原有列之后加上主键索引，如index_name='i1' and stat_name='n_diff_pfx03'，在原索引列c,d后加了主键列a，(c,d,a)的distinct结果为2。
了解了stat_name和stat_value的具体含义，就可以协助我们排查SQL执行时为什么没有使用合适的索引，例如某个索引n_diff_pfxNN的stat_value远小于实际值，查询优化器认为该索引选择度较差，就有可能导致使用错误的索引。
三、统计信息不准确的处理
我们查看执行计划，发现未使用正确的索引，如果是innodb_index_stats中统计信息差别较大引起，可通过以下方式处理：
1、手动更新统计信息，注意执行过程中会加读锁：
ANALYZETABLE TABLE_NAME;
2、如果更新后统计信息仍不准确，可考虑增加表采样的数据页，两种方式可以修改：
a) 全局变量INNODB_STATS_PERSISTENT_SAMPLE_PAGES，默认为20；
b) 单个表可以指定该表的采样：
ALTER TABLE TABLE_NAME STATS_SAMPLE_PAGES=40;
经测试，此处STATS_SAMPLE_PAGES的最大值是65535，超出会报错。
原文链接：https://blog.csdn.net/liys0811/article/details/132408205
