为什么要关注索引统计误差

简介: 为什么要关注索引统计误差

导读

由一个不可思议的索引统计信息误差案例引发的监控需求。

事情的起因是,我的朋友小明同学有一天突然发现有个SQL的执行计划出问题了。经过一番排查,居然发现是该表的辅助索引统计信息存在严重偏差。

我们知道,InnoDB表里每个辅助索引都会同时存储聚集索引列值,这就是所谓的 Index Extensions特性。那么,在统计索引信息时,包含聚集索引列的统计值就应该和聚集索引列的值几乎一样的才对,比如:(建议横屏观看)

[root@yejr.me]>select * from mysql.innodb_index_stats;
+------------+------------+------------+-------------+------------------+
| table_name | index_name | stat_value | sample_size | stat_description |
+------------+------------+------------+-------------+------------------+
...
| zst        | PRIMARY    |      40002 |          20 | id               |
...
| zst        | k1         |      40376 |          20 | uid,id           |
...
+------------+------------+------------+-------------+------------------+

可以看到k1索引的 (uid, id) 统计值(stat_value列)和主键索引是几乎差不多的。

这次小明遇到的问题,也是我这么多年来头一次遇到过,而且这还是在国内某知名公有云数据库上发生的,简直有点不太可思议。提交工单后,工程师给的答复也表示以前没遇到过,暂时不确定是什么原因引起的。

既然这种问题不能避免,那就自己主动加个监控吧,于是就有了本文。

解决方案

找出索引统计信息中,辅助索引统计信息和主键索引相差太大的情况,也就是辅助索引的基数和主键索引相差太大的现象,发出告警,并且手动执行 ANALYZE TABLE t 更新索引统计信息,一般就能解决问题了

如何监控

  1. 每个非唯一辅助索引都会包含主键列,正常情况下,包含主键列的那行统计信息和主键索引的统计信息相差不会太大。
  2. 唯一索引比较特殊,因为在 mysql.innodb_index_stats 表中,唯一索引列统计信息不会再包含主键列,但其基准值和主键列的基准值也不能相差太大。

假设有个表t3的索引统计数据如下(建议横看)

[root@yejr.me] [mysql]>select database_name as db,

table_name as tbl, index_name as idx, stat_name,
stat_value, stat_description
from innodb_index_stats where
database_name = 'zhishutang' and table_name = 't3';
+------------+-----+---------+--------------+------------+-----------------------------------+
| db | tbl | idx | stat_name | stat_value | stat_description |
+------------+-----+---------+--------------+------------+-----------------------------------+
| zhishutang | t3 | PRIMARY | n_diff_pfx01 | 1900 | id |
| zhishutang | t3 | PRIMARY | n_leaf_pages | 1 | Number of leaf pages in the index |
| zhishutang | t3 | PRIMARY | size | 1 | Number of pages in the index |
| zhishutang | t3 | name | n_diff_pfx01 | 1 | name |
| zhishutang | t3 | name | n_diff_pfx02 | 19 | name,id |
| zhishutang | t3 | name | n_leaf_pages | 1 | Number of leaf pages in the index |
| zhishutang | t3 | name | size | 1 | Number of pages in the index |
| zhishutang | t3 | nu | n_diff_pfx01 | 1900 | nu |
| zhishutang | t3 | nu | n_leaf_pages | 1 | Number of leaf pages in the index |
| zhishutang | t3 | nu | size | 1 | Number of pages in the index |
+------------+-----+---------+--------------+------------+-----------------------------------+

以上面为例,希望得到的结果是

  1. 唯一索引nu的统计信息和主键索引统计信息一样,没问题。
  2. 辅助索引name的第二条(含主键列的那条)统计信息 (name, id) 和主键索引统计信息相差太远,属于异常,要能被发现。

实现该目的的SQL方法如下:(建议横看)

set @statdb = 'yejr';
select
a.database_name ,
a.table_name ,
a.index_name ,
a.stat_value SK,
b.stat_value PK,
round((a.stat_value/b.stat_value)*100,2) stat_pct
from
(
select
b.database_name ,
b.table_name ,
b.index_name ,
b.stat_value
from
(
select database_name ,
table_name ,
index_name ,
max(stat_name) stat_name
from innodb_index_stats
where database_name = @statdb
and stat_name not in ( 'size' ,'n_leaf_pages' )
group by
database_name ,
table_name ,
index_name
) a join innodb_index_stats b on a.database_name=b.database_name
and a.table_name=b.table_name
and a.index_name=b.index_name
and a.stat_name=b.stat_name
and b.index_name !='PRIMARY'
) a left join
(
select
b.database_name ,
b.table_name ,
b.index_name ,
b.stat_value
from
(
select database_name ,
table_name ,
index_name ,
max(stat_name) stat_name
from innodb_index_stats
where database_name = @statdb
and stat_name not in ( 'size' ,'n_leaf_pages' )
group by
database_name ,
table_name ,
index_name
) a join innodb_index_stats b
on a.database_name=b.database_name
and a.table_name=b.table_name
and a.index_name=b.index_name
and a.stat_name=b.stat_name
and b.index_name ='PRIMARY'
) b
on a.database_name=b.database_name
and a.table_name=b.table_name
where b.stat_value is not null
and a.stat_value >0
order by stat_pct;

+---------------+-------------------+--------------+--------+--------+----------+
| database_name | table_name | index_name | SK | PK | stat_pct |
+---------------+-------------------+--------------+--------+--------+----------+
| zhishutang | t_json_vs_vchar | c1vc | 37326 | 39825 | 93.73 |
| zhishutang | t_json_vs_vchar | c2vc | 37371 | 39825 | 93.84 |
| zhishutang | t1 | name | 299815 | 299842 | 99.99 |
| zhishutang | t4 | c2 | 2 | 2 | 100.00 |
+---------------+-------------------+--------------+--------+--------+----------+

上面的SQL逻辑过于复杂,我是搞不定的,也是请知数堂SQL优化班郑松华老师帮忙给写的。

这个SQL脚本,我也已放在知数堂github库里“查看索引统计偏差”。

            </div>
相关文章
|
6月前
|
SQL 关系型数据库 分布式数据库
在PolarDB中,行数评估是通过对表的统计数据、基数估计以及算子代价模型来进行估算的。
【2月更文挑战第14天】在PolarDB中,行数评估是通过对表的统计数据、基数估计以及算子代价模型来进行估算的。
138 1
|
6天前
贝叶斯统计中常见先验分布选择方法总结
本文详细介绍了贝叶斯统计中三种常见的先验分布选择方法:经验贝叶斯方法、信息先验和无信息/弱信息先验。
26 3
贝叶斯统计中常见先验分布选择方法总结
|
5月前
|
机器学习/深度学习 监控 数据挖掘
数据并非都是正态分布:三种常见的统计分布及其应用
这篇文章除了介绍线性模型在减肥app预测中的不切实际性,还探讨了不同统计分布在体重管理和数据分析中的应用。文章提到了正态分布和泊松分布,前者常用于描述围绕平均值对称分布的连续数据,如体重;后者适合计数数据,如体重变化次数。正态分布以其钟形曲线闻名,泊松分布则描述独立事件的数量。文章还简要介绍了卡方分布在检验分类变量关系时的作用。最后,文章指出了在线性回归中假设数据正态分布的原因,包括便于统计推断和最小化估计误差。
438 5
|
6月前
【数理统计实验(一)】统计量近似分布的随机模拟
【数理统计实验(一)】统计量近似分布的随机模拟
|
6月前
R语言自定义两种统计量度:平均值和中位数,何时去使用?
R语言自定义两种统计量度:平均值和中位数,何时去使用?
|
6月前
|
数据挖掘
统计的基本概念及抽样分布
统计的基本概念及抽样分布
统计的基本概念及抽样分布
统计: 统计假设检验-比较方法的差别与选择
本文介绍了日常应用最广泛的几种基础的假设检验比较方法及其适用条件,以供参考学习
258 0
J3
|
数据采集 数据可视化 数据挖掘
样本大小如何影响统计结果精确性
一天,我在漫无目的地游走于数据的海洋中,突然有位科研小伙伴跑来问我:“为啥样本大小会影响统计检验结果的精确性呢?”哎呀,这不是小菜一碟嘛!但怎么回答才能展现出我的风采呢?我不就是那个总爱在数据世界里溜达的数据侠客吗!
J3
258 1
样本大小如何影响统计结果精确性
|
关系型数据库 MySQL
mysql查询最接近的值,查询最接近某一值的数据
mysql查询最接近的值,查询最接近某一值的数据
641 0
|
SQL 存储 监控
为什么要关注索引统计误差
为什么要关注索引统计误差
下一篇
无影云桌面