统计信息的作用
上周同事在客户现场遇到了由于统计信息的原因，导致应用数据迁移时间过慢，整个迁移差点失败。关键时刻同事发现测试环境与生产环境SQL语句执行计划不一致，立刻收集统计信息才保证迁移得以正常完成。
统计信息对于SQL的执行时间有重要的影响，统计信息的不准确会导致SQL的执行计划不准确，从而致使SQL执行时间变慢，Oracle DBA非常了解统计信息的收集规则，同样在MySQL中也有相关的参数去控制统计信息。
相关参数
innodb_stats_auto_recalc
控制innodb是否自动收集统计信息，默认是打开的。当表中数据变化超过%10时候，就会重新计算统计信息。参数的生效依赖于建表时指定innodb_stats_persistent是打开的或CREATE
TABLE , ALTER TABLE
时指定STATS_PERSISTENT=1采样page的个数通过参数innodb_stats_persistent_sample_pages来控制。
测试验证
创建一张测试表，并在表上创建一个索引:
通过mysql.innodb_index_stats可以查看索引最后收集统计信息的时间,这里的聚集索引我们删除先不用去看，只看自己创建的二级索引
我们手工往表中插入数据，让数据的变化超过%10
这时我们在查看下mysql.innodb_index_stats表,last_update时间发生了变化
[root@shadow:/root 5.7.18-log_Instance1 root@localhost:test 22:38:36]>select * from mysql.innodb_index_stats where database_name = ‘test’;
+—————+————+—————–+———————+————–+————+————-+———————————–+ | database_name | table_name | index_name | last_update | stat_name | stat_value | sample_size | stat_description |
+—————+————+—————–+———————+————–+————+————-+———————————–+ | test | dhytest | idx_id | 2017-07-10 22:38:28 | n_diff_pfx01 | 1 | 1 | id |
| test | dhytest | idx_id | 2017-07-10 22:38:28 | n_diff_pfx02 | 2 | 1 | id,DB_ROW_ID |
| test | dhytest | idx_id | 2017-07-10 22:38:28 | n_leaf_pages | 1 | NULL | Number of leaf pages in the index |
| test | dhytest | idx_id | 2017-07-10 22:38:28 | size | 1 | NULL | Number of pages in the index |
+—————+————+—————–+———————+————–+————+————-+———————————–+ 7 rows in set (0.00 sec)
innodb_stats_persistent
控制是否将统计信息持久到磁盘当中，设置此参数之后我们就不需要实时去收集统计信息了，因为实时收集统计信息在高并发下可能会造成一定的性能上影响，并且会导致执行计划有所不同。建议是将此参数打开，将innodb_stats_auto_recalc参数进行关闭。
innodb_stats_persistent_sample_pages
控制收集统计信息时采样的page数量，默认是20。收集的page数量越多，每次收集统计信息的实际则越长，但是统计信息也相对比较准确。
我们可以在创建表的时候对不同的表指定不同的page数量、是否将统计信息持久化到磁盘上、是否自动收集统计信息
CREATE TABLE `t1` ( `id` int(8) NOT NULL auto_increment, `data` varchar(255), `date` datetime,
PRIMARY KEY (`id`), INDEX `DATE_IX` (`date`)
) ENGINE=InnoDB,
STATS_PERSISTENT=1,
STATS_AUTO_RECALC=1,
STATS_SAMPLE_PAGES=25;
innodb_stats_on_metadata
此参数在5.6.5版本之前是默认开启的，设置此参数后当我们执行show
index 或者 show table status 或者访问INFORMATION_SCHEMA.TABLES or
INFORMATION_SCHEMA.STATISTICS表时就会收集统计信息，但是这样可能会导致执行计划改变。
在以前当表中记录变化超过1/16就会收集统计信息，但是现在如果设置了innodb_stats_persistent就不会有这样的说法了。
innodb_stats_include_delete_marked
5.6.35版本中新增的参数，就是在未提交的事务中如果我们删除了记录，收集统计信息的时候是排查这些开发云主机域名删除了的记录的。这样就可能导致统计信息并不是很准确，设置此参数之后就是收集统计信息的时候包含未提交事务中被标记为已删除的数据。
innodb_stats_method
控制统计信息针对索引中NULL值的算法
当设置为nulls_equal 所有的NULL值都视为一个value group
当设置为nulls_unequal每一个NULL值被视为一个value group
设置为nulls_ignored时 NULL值被忽略
这个参数同事彭许生做过一些测试发现nulls_equal和nulls_unequal没有发现show index中的cardinality有不同的地方，但是如果设置为nulls_ignored的时候会有所不同。
测 试
表结构数据
设置为nulls_ignored
设置为nulls_unequal
设置为nulls_equal
推荐配置
innodb_stats_method 统计信息的自动收集在高并发情况下可能会带来性能的抖动，建议将此参数关闭。
innodb_stats_persistent 建议打开此参数将统计信息持久化到磁盘上 。
innodb_stats_include_delete_marked建议设置开启，这样可以针对未提交事务中删除的数据也收集统计信息 。
innodb_stats_method经过测试和mos查看到的按默认配置就可以，当然如果设置nulls_ignored时候会让你的语句走到索引，但是效率并不一定是好的。
MySQL的中AUTO_INCREMENT类型的属性用于为一个表中记录自动生成ID功能，可在一定程度上代替Oracle，PostgreSQL等数据库中的sequence。 在数据库应用，我们经常要用到唯一编号，以标识记录。在MySQL中可通过数据列的AUTO_…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
