欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

mysql-5.7 持久化统计信息详解

程序员文章站 2023-11-08 08:52:28
一、持久化统计信息的意义: 统计信息用于指导mysql生成执行计划,执行计划的准确与否直接影响到SQL的执行效率;如果mysql一重启 之前的统计信息就没有了,那么当SQL语句来临时,那么mysql就要收集统计信息然后再生成SQL语句的执行 计划。如果能在关闭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 参数来控制更新

  统计信息时的采样,样本页面的数量。

[mysqld]
innodb_stats_persistent=1
innodb_stats_auto_recalc=1
innodb_stats_persistent_sample_pages=20

 

四、手动更新统计信息的方式:

  mysql通过analyze table 语句来手动的更新统计信息

 

五、查看表的统计信息是什么时候更新的:

  mysql把统计信息相关的内容记录在mysql.innodb_table_stats ,mysql.innodb_index_stats 这两张表里面。

  mysql.innodb_table_stats以表为单位记录着统计信息

 
mysql> select * from innodb_table_stats;
+---------------+----------------------------+---------------------+--------+----------------------+--------------------------+
| database_name | table_name                 | last_update         | n_rows | clustered_index_size | sum_of_other_index_sizes |
+---------------+----------------------------+---------------------+--------+----------------------+--------------------------+
| fdb           | auth_group                 | 2017-08-10 14:36:40 |      0 |                    1 |                        1 |
| fdb           | auth_group_permissions     | 2017-08-10 14:36:41 |      0 |                    1 |                        2 |
| fdb           | auth_permission            | 2017-08-10 14:36:41 |     30 |                    1 |                        1 |
| fdb           | auth_user                  | 2017-08-10 14:36:41 |      0 |                    1 |                        1 |
| fdb           | auth_user_groups           | 2017-08-10 14:36:41 |      0 |                    1 |                        2 |
| fdb           | auth_user_user_permissions | 2017-08-10 14:36:41 |      0 |                    1 |                        2 |
| fdb           | cninfo_company             | 2017-08-10 14:36:58 |   4996 |                  161 |                        6 |
| fdb           | csindex_indexdetail        | 2017-09-17 14:04:27 |      0 |                    1 |                        0 |
| fdb           | csindex_indexoverview      | 2017-09-01 12:44:18 |     11 |                    1 |                        0 |
| fdb           | django_admin_log           | 2017-08-10 14:36:47 |      0 |                    1 |                        2 |
| fdb           | django_content_type        | 2017-08-10 14:36:47 |     10 |                    1 |                        1 |
| fdb           | django_migrations          | 2017-09-04 14:04:09 |     37 |                    1 |                        0 |
| fdb           | django_session             | 2017-08-10 14:36:47 |      0 |                    1 |                        1 |
| fdb           | glod_glodprice             | 2017-08-10 14:36:48 |   2271 |                   10 |                        0 |
| fdb           | pbc_moneysupply            | 2017-08-10 14:37:08 |     78 |                    1 |                        0 |
| fdb           | shibor_shiborrate          | 2017-08-10 14:37:18 |   2711 |                   14 |                        0 |
| fdb           | sse_marketoverview         | 2017-08-15 16:06:12 |      0 |                    1 |                        0 |
| mysql         | gtid_executed              | 2017-09-06 11:02:14 |      2 |                    1 |                        0 |
| sys           | sys_config                 | 2017-08-10 12:19:06 |      6 |                    1 |                        0 |
| tempdb        | person                     | 2017-09-14 11:18:15 |      1 |                    1 |                        0 |
| tmp           | t                          | 2017-08-15 11:06:18 |      2 |                    1 |                        0 |
+---------------+----------------------------+---------------------+--------+----------------------+--------------------------+
21 rows in set (0.00 sec)
 

  各个列所代表的意义:

  database_name        表所在的库名

  table_name          表名

  last_update          最近一次的更新时间

  n_rows            表中的行数

  clustered_index_size       主键的大小

  sum_of_other_index_sizes   所有二级索引的大小

 

 

 六、一些在analyze table 过程中的经验:

  如果我们用explan 语句查看sql的执行计划的时候发现,计划走的不准,多半是由于统计信息过时引起的,这个

  时候就要执行一下analyze table 来重新生成一下执行计划了;有时候可能发现重新生成执行计划后并没有什么用

  sql还是走的不准,这个时候最可能的原因就是生成执行计划时的采样页的数量太低了,innodb_stats_persistent_sample_pages

  这个参数的值,注意这个值也不要加的太大,要不然会老半天都执行不完analyze table 语句。