详解mysql持久化统计信息
一、持久化统计信息的意义：
统计信息用于指导mysql生成执行计划，执行计划的准确与否直接影响到SQL的执行效率；如果mysql一重启
之前的统计信息就没有了，那么当SQL语句来临时，那么mysql就要收集统计信息然后再生成SQL语句的执行
计划。如果能在关闭mysql的时候就把统计信息保存起来，那么在启动时就不要再收集一次了，这种处理方式
有助于效率的提升。
二、统计信息准确与否也同样重要：
第一目中我们说明了“持久化统计信息的意义”，我们的假设统计信息是有用的，是准确的；如果统计信息本身
已经过时了，比如说统计信息是在表中只有100行时统计出来的，这种情况下往往走全表扫描开销会更小，但是
呢！现在表中的行数已经达到了100万行，明显这种过时的统计信息会引发性能灾难，所以统计信息的时效性也
是同样重要的。那mysql它什么时候自动更新统计信息呢？默认情况下当表中的数据有10%被修改过的就会更新。
三、mysql对统计信息的处理：
针对上面的两个问题mysql都有给出解决方案，并且都可能通过简单的配置来解决
1、针对是否持久化统计信息mysql可以通过innodb_stats_persistent参数来控制
2、针对统计信息的时效性，mysql通过innodb_stats_auto_recalc参数来控制是否自动更新
3、针对统计信息的准确性，mysql通过innodb_stats_persistent_sample_pages参数来控制更新
统计信息时的采样，样本页面的数量。
四、手动更新统计信息的方式：
mysql通过analyzetable语句来手动的更新统计信息
五、查看表的统计信息是什么时候更新的：
mysql把统计信息相关的内容记录在mysql.innodb_table_stats，mysql.innodb_index_stats这两张表里面。
mysql.innodb_table_stats以表为单位记录着统计信息
mysql>select*frominnodb_table_stats; +---------------+----------------------------+---------------------+--------+----------------------+--------------------------+ |database_name|table_name|last_update|n_rows|clustered_index_size|sum_of_other_index_sizes| +---------------+----------------------------+---------------------+--------+----------------------+--------------------------+ |fdb|auth_group|2017-08-1014:36:40|0|1|1| |fdb|auth_group_permissions|2017-08-1014:36:41|0|1|2| |fdb|auth_permission|2017-08-1014:36:41|30|1|1| |fdb|auth_user|2017-08-1014:36:41|0|1|1| |fdb|auth_user_groups|2017-08-1014:36:41|0|1|2| |fdb|auth_user_user_permissions|2017-08-1014:36:41|0|1|2| |fdb|cninfo_company|2017-08-1014:36:58|4996|161|6| |fdb|csindex_indexdetail|2017-09-1714:04:27|0|1|0| |fdb|csindex_indexoverview|2017-09-0112:44:18|11|1|0| |fdb|django_admin_log|2017-08-1014:36:47|0|1|2| |fdb|django_content_type|2017-08-1014:36:47|10|1|1| |fdb|django_migrations|2017-09-0414:04:09|37|1|0| |fdb|django_session|2017-08-1014:36:47|0|1|1| |fdb|glod_glodprice|2017-08-1014:36:48|2271|10|0| |fdb|pbc_moneysupply|2017-08-1014:37:08|78|1|0| |fdb|shibor_shiborrate|2017-08-1014:37:18|2711|14|0| |fdb|sse_marketoverview|2017-08-1516:06:12|0|1|0| |mysql|gtid_executed|2017-09-0611:02:14|2|1|0| |sys|sys_config|2017-08-1012:19:06|6|1|0| |tempdb|person|2017-09-1411:18:15|1|1|0| |tmp|t|2017-08-1511:06:18|2|1|0| +---------------+----------------------------+---------------------+--------+----------------------+--------------------------+ 21rowsinset(0.00sec)
各个列所代表的意义：
database_name表所在的库名
table_name表名
last_update最近一次的更新时间
n_rows表中的行数
clustered_index_size 主键的大小
sum_of_other_index_sizes所有二级索引的大小
六、一些在analyzetable过程中的经验：
如果我们用explan语句查看SQL的执行计划的时候发现，计划走的不准，多半是由于统计信息过时引起的，这个
时候就要执行一下analyzetable来重新生成一下执行计划了；有时候可能发现重新生成执行计划后并没有什么用
SQL还是走的不准，这个时候最可能的原因就是生成执行计划时的采样页的数量太低了，innodb_stats_persistent_sample_pages
这个参数的值，注意这个值也不要加的太大，要不然会老半天都执行不完analyzetable语句。
七、附加说明：
上文中说的mysql实际上指的只是Innodb这个引擎
以上就是详解mysql持久化统计信息的详细内容，更多关于mysql持久化统计信息的资料请关注毛票票其它相关文章！