一、持久化统计信息的意义:
统计信息用于指导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
这个参数的值,注意这个值也不要加的太大,要不然会老半天都执行不完analyze table 语句。
七、附加说明:
上文中说的mysql实际上指的只是Innodb这个引擎
以上就是详解mysql持久化统计信息的详细内容,更多关于mysql持久化统计信息的资料请关注其它相关文章!
RTX 5090要首发 性能要翻倍!三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB,每个模块容量为2GB。其速度预设为32 Gbps(PAM3),但也可以降至28 Gbps,以提高产量和初始阶段的整体性能和成本效益。
据三星表示,GDDR7内存的能效将提高20%,同时工作电压仅为1.1V,低于标准的1.2V。通过采用更新的封装材料和优化的电路设计,使得在高速运行时的发热量降低,GDDR7的热阻比GDDR6降低了70%。
更新动态
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]