skywalking mysql 持久化 mysql的持久化

转载

mob64ca14193248 2023-08-20 20:30:26

文章标签 mysql数据持久化 mysql 执行计划持久化 文章分类 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通过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