1. 树叶云首页
  2. 技术资讯

MySQL 统计信息不准导致的性能问题

管理••技术资讯

表的统计信息错误导致优化器选择错误的执行计划。

一个客户的性能优化案例: 没有修改数据库实例的任何配置参数以及业务代码没有变更的情况下，一条 sql 出现大幅性能下降。

我们来看看出问题的sql 以及他的执行计划:

mysql>explain
->SELECTcount(con.id)          ,
->MAX(DAYNAME(con.date)) ,
->now()                  ,
->pcz.type,
->pcz.c_c
->FROMconAScon
->joinordersooncon.o_id=o.id
->JOINpczASpczONo.d_p_c_z_id=pcz.id
->leftjoincconcon.c_id=c.id
->WHEREcon.date=current_date() andpcz.type="T_D"
->GROUPBYcon.date, pcz.c_c,  pcz.type;
+----+-------------+-------+------------+--------+-------------------+----------+---------+----------------------------+------+----------+----------------------------------------------+
|id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows|filtered|Extra|
+----+-------------+-------+------------+--------+-------------------+----------+---------+----------------------------+------+----------+----------------------------------------------+
|1|SIMPLE|pcz|NULL|ALL|PRIMARY|NULL|NULL|NULL|194|10.00|Usingwhere; Usingtemporary; Usingfilesort|
|1|SIMPLE|o|NULL|ref|PRIMARY,dpcz_FK|dpcz_FK|9|custom.pcz.id|1642|100.00|Usingindex|
|1|SIMPLE|con|NULL|ref|FK_order,IDX_date|FK_order|8|custom.o.id|1|4.23|Usingwhere|
|1|SIMPLE|c|NULL|eq_ref|PRIMARY|PRIMARY|8|custom.con.c_id|1|100.00|Usingindex|
+----+-------------+-------+------------+--------+-------------------+----------+---------+----------------------------+------+----------+----------------------------------------------+

执行计划显示 rows examined = (19410%)1642(14.23%)=1347 查看执行计划我们就发现 where 条件 con.date = current_date() 。这个条件看起来更适合作为索引过滤数据。但是 为什么 MySQL 优化器不选择该索引呢？接下来使用 force index 强制执行计划使用 con.date 字段上的索引。执行计划如下:

mysql>explain
->SELECTcount(con.id)          ,
->MAX(DAYNAME(con.date)) ,
->now()                  ,
->pcz.type,
->pcz.c_c
->FROMconASconUSEINDEX(IDX_date)
->joinordersooncon.o_id=o.id
->JOINp_c_zASpczONo.d_p_c_z_id=pcz.id
->leftjoincconcon.c_id=c.id
->WHEREcon.date=current_date() andpcz.type="T_D"
->GROUPBYcon.date, pcz.c_c,  pcz.type;
+----+-------------+-------+------------+--------+-----------------+----------+---------+---------------------------------------+--------+----------+---------------------------------+
|id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows|filtered|Extra|
+----+-------------+-------+------------+--------+-----------------+----------+---------+---------------------------------------+--------+----------+---------------------------------+
|1|SIMPLE|con|NULL|ref|IDX_date|IDX_date|3|const|110446|100.00|Usingtemporary; Usingfilesort|
|1|SIMPLE|c|NULL|eq_ref|PRIMARY|PRIMARY|8|custom.con.c_id|1|100.00|Usingindex|
|1|SIMPLE|o|NULL|eq_ref|PRIMARY,dpcz_FK|PRIMARY|8|custom.con.o_id|1|100.00|Usingwhere|
|1|SIMPLE|pcz|NULL|eq_ref|PRIMARY|PRIMARY|8|custom.o.d_p_c_z_id|1|10.00|Usingwhere|
+----+-------------+-------+------------+--------+-----------------+----------+---------+---------------------------------------+--------+----------+---------------------------------+

问题来了 rows examined = 110446*(1*10%)=11045 rows根据计算评估， 第一个执行计划的 1347 大概是 110446 的十分之一 ，至少从表面上看来这个是MySQL 优化器选择第一个执行计划的原因。

但是对比实际的查询结果的响应时间，肯定粗问题了。因为执行计划二 的sql 的响应时间在预期之内，但是执行计划一对应的响应时间反而更慢。

进一步来看表 orders 的创建语句以及执行计划1，我们发现 表pcz的确有194行。然后查看 索引 orders.dpcz_FK，表 orders 返回 1642行 ，因为外键约束 orders_ibfk_10 的定义，也就意味着 表 orders 的记录数应该是 194*1642=318548 ，但是实际的行数是 32508150，百倍于执行计划估计的值 318548 。

CREATETABLE`orders` (
`id`bigint(20) NOTNULLAUTO_INCREMENT,
...
`d_p_c_z_id`bigint(20) DEFAULTNULL,
...,
PRIMARYKEY (`id`),
...
KEY`dpcz_FK` (`d_p_c_z_id`),
...
CONSTRAINT`orders_ibfk_10`FOREIGNKEY (`d_p_c_z_id`) REFERENCES`p_c_z` (`id`) ONDELETECASCADEONUPDATECASCADE,
...
) ENGINE=InnoDB....
mysql>select*frommysql.innodb_table_statswheredatabase_name='cutom'andtable_name='orders';
+---------------+------------+---------------------+----------+----------------------+--------------------------+
|database_name|table_name|last_update|n_rows|clustered_index_size|sum_of_other_index_sizes|
+---------------+------------+---------------------+----------+----------------------+--------------------------+
|custom|orders|2022-03-0321:58:18|32508150|349120|697618|
+---------------+------------+---------------------+----------+----------------------+--------------------------+

分析至此，我们可以断定 orders.dpcz_FK 的统计信息是不准确的，于是乎我们使用如下语句确认它的实际数据量:

mysql>select*frommysql.innodb_index_statswheredatabase_name='cutom'andtable_name='orders'andindex_name='dpcz_FK';
mysql>select*frommysql.innodb_index_statswheredatabase_name='custom'andtable_name='orders'andindex_name='dpcz_FK';
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
|database_name|table_name|index_name|last_update|stat_name|stat_value|sample_size|stat_description|
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
|custom|orders|dpcz_FK|2022-02-2812:35:30|n_diff_pfx01|19498|50|d_p_c_z_id|
|custom|orders|dpcz_FK|2022-02-2812:35:30|n_diff_pfx02|32283087|128|d_p_c_z_id,id|
|custom|orders|dpcz_FK|2022-02-2812:35:30|n_leaf_pages|55653|NULL|Numberofleafpagesintheindex|
|custom|orders|dpcz_FK|2022-02-2812:35:30|size|63864|NULL|Numberofpagesintheindex|
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
mysql>selectcount(distinctd_p_c_z_id) fromorders; 
+----------------------------------------------+
|count(distinctd_p_c_z_id)                   |
+----------------------------------------------+
|195|
+----------------------------------------------+

Bingo！从上面来看 表 orders 字段 d_p_c_z_id 的区分度(不一样的值的总数)为 195 。在信息统计表里面 dpcz_FK的 stat_value 值是 19498 ，显然这个值是不准确的并且比实际值大的多，100倍 。索引的 state_value 值应该等于这个字段的在表里面的区分度。

如果使用正确的 索引 dpcz_FK 的值 stat_value 195 去重新评估执行计划的成本，我们将得到执行计划1 的结果 32508150/195=166708 ，并且执行计划预估的扫描的行数应该是 (194*10%)*166708*(1*4.23%)=136804。因为该值是10倍于执行计划2 的值 11045 。MySQL 在没有使用force index的情况下就能走到正确的执行计划 。

这个sql的问题解决了，但是为什么 MySQL 的统计信息会计算错误，我们如何修复它呢？

回答这个问题之前，我们先了解一下 MySQL 是如何收集统计信息以及哪些参数控制 这个动作。

InnoDB 是如何收集表的统计信息

我们可以通过显式的方式或者系统自动采集表的统计信息 。

通过开启参数innodb_stats_auto_recalc =on (默认也是打开的) 以便在表的数据发生重大变化以后来自动收集表的统计信息。比如当表中的10% 的行发生变化 ，InnoDB 将重新计算统计信息。或者我们可以使用ANALYZE TABLE显式地重新计算统计信息。

InnoDB 使用随机采样技术的方法采集统计信息– 随机抽取索引页，估计索引的基数。参数innodb_stats_persistent_sample_pages 控制采样页面的数量。参考​​https://dev.mysql.com/doc/refman/5.7/en/innodb-persistent-stats.html​​

根据代码和描述，随机抽样并不是完全随机的。采样页面实际上是根据采样算法选择的。最终，不同键值的总数，即索引的 stat_value 将通过以下公式计算
N * R * N_DIFF_AVG_LEAF。其中

N : 叶页数
R : levelLA上不同key值的个数与levelLA上记录总数的比值
`N_DIFF_AVG_LEAF`：在所有A叶页中找到的不同键值的平均数。

采样算法代码的详细信息可以在链接中找到：​​https://github.com/mysql/mysql-server/blob/6846e6b2f72931991cc9fd589dc9946ea2ab58c9/storage/innobase/dict/dict0stats.cc​​

基于上面的介绍，我们知道当一个表的索引发生分裂时，无论是叶子页数（N），还是 层LA 上不同键值的个数占 层LA 总记录数的比值（R ) 变得越来越不准确，因此 stat_value 的计算可能不正确。一旦发生这种情况，除非更改参数innodb_stats_persistent_sample_pages或重建索引，否则显式重新计算（手动运行 ANALYZE TABLE）将无法生成正确的 stat_value。

解决方法

我们怎么修正表的统计信息 ，并且阻止这类情况进一步发生。

经过前面的分析和讨论，我们知道 有两个因素影响数据库收集表的统计信息 ，

innodb_stats_persistent_sample_pages: A索引的组织方式

为了能够让 InnoDB 得到正确的 统计信息，我们需要 调整innodb_stats_persistent_sample_pages 或者重建索引 。
1 通过命令 analyze table 不重建的方式，保持
innodb_stats_persistent_sample_pages =128，stat_value 略微更改为 19582，接近原始不正确的 19498，仍然关闭。索引中的叶子页数从 55653 略微更改为 55891，索引中的页数也从 63864 略微更改为 64248

mysql>showvariables='innodb_stats_persistent_sample_pages;
+--------------------------------------+-------+
|Variable_name|Value|
+--------------------------------------+-------+
|innodb_stats_persistent_sample_pages|128|
+--------------------------------------+-------+
mysql>analyzetableorders;
+---------------+---------+----------+----------+
|Table|Op|Msg_type|Msg_text|
+---------------+---------+----------+----------+
|custom.orders|analyze|status|OK|
+---------------+---------+----------+----------+
mysql>select*frommysql.innodb_index_statswheredatabase_name='custom'andtable_name='orders'andindex_name='dpcz_FK';
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
|database_name|table_name|index_name|last_update|stat_name|stat_value|sample_size|stat_description|
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
|custom|orders|dpcz_FK|2022-03-0321:58:18|n_diff_pfx01|19582|50|d_p_c_z_id|
|custom|orders|dpcz_FK|2022-03-0321:58:18|n_diff_pfx02|32425512|128|d_p_c_z_id,id|
|custom|orders|dpcz_FK|2022-03-0321:58:18|n_leaf_pages|55891|NULL|Numberofleafpagesintheindex|
|custom|orders|dpcz_FK|2022-03-0321:58:18|size|64248|NULL|Numberofpagesintheindex|
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+

2 ANALYZE TABLE 不重建，但将innodb_stats_persistent_sample_pages 从 128 增加到 512，使 stat_value 到192非常接近实际基数 195。索引中的叶页数发生了很大变化，从 55653 到 44188。索引中的页数也从也发生了巨大变化，从 63864 变为 50304。

mysql>showvariableslike'%persistent_sample%';
+--------------------------------------+-------+
|Variable_name|Value|
+--------------------------------------+-------+
|innodb_stats_persistent_sample_pages|512|
+--------------------------------------+-------+
mysql>analyzetableorders;
+---------------+---------+----------+----------+
|Table|Op|Msg_type|Msg_text|
+---------------+---------+----------+----------+
|custom.orders|analyze|status|OK|
+---------------+---------+----------+----------+
mysql>select*frommysql.innodb_index_statswheredatabase_name='custom'andtable_name='orders'andindex_name='dpcz_FK';
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
|database_name|table_name|index_name|last_update|stat_name|stat_value|sample_size|stat_description|
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
|custom|orders|dpcz_FK|2022-03-0906:54:29|n_diff_pfx01|192|179|d_p_c_z_id|
|custom|orders|dpcz_FK|2022-03-0906:54:29|n_diff_pfx02|31751321|512|d_p_c_z_id,id|
|custom|orders|dpcz_FK|2022-03-0906:54:29|n_leaf_pages|44188|NULL|Numberofleafpagesintheindex|
|custom|orders|dpcz_FK|2022-03-0906:54:29|size|50304|NULL|Numberofpagesintheindex|
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+

3 重建表，保持innodb_stats_persistent_sample_pages 为128，同样得到了正确的 stat_value 187，接近真实基数195。索引中的叶子页数大幅变化，从55653变为43733，索引中的页数也从63864变化到 50111。

mysql>showvariables='innodb_stats_persistent_sample_pages';
+--------------------------------------+-------+
|Variable_name|Value|
+--------------------------------------+-------+
|innodb_stats_persistent_sample_pages|128|
+--------------------------------------+-------+
mysql>altertableordersengine=innodb;
QueryOK, 0rowsaffected (11min16.37sec)
mysql>select*frommysql.innodb_index_statswheredatabase_name='custom'andtable_name='orders'andindex_name='dpcz_FK';
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
|database_name|table_name|index_name|last_update|stat_name|stat_value|sample_size|stat_description|
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
|custom|orders|dpcz_FK|2022-03-0718:44:43|n_diff_pfx01|187|128|d_p_c_z_id|
|custom|orders|dpcz_FK|2022-03-0718:44:43|n_diff_pfx02|31531493|128|d_p_c_z_id,id|
|custom|orders|dpcz_FK|2022-03-0718:44:43|n_leaf_pages|43733|NULL|Numberofleafpagesintheindex|
|custom|orders|dpcz_FK|2022-03-0718:44:43|size|50111|NULL|Numberofpagesintheindex|
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+

在更正表统计数据后，MySQL 优化器也会选择正确的执行计划：

mysql>explain
SELECTcount(con.id)          ,
MAX(DAYNAME(con.date)) ,
now()                  ,
pcz.type,
pcz.c_c
FROMconAScon
joinordersooncon.order_id=o.id
JOINp_c_zASpczONo.d_p_c_z_id=pcz.id
leftjoincconcon.c_id=c.id
WHEREcon.date=current_date()
andpcz.type="T_D"
GROUPBYcon.date, pcz.c_c,  pcz.type;
+----+-------------+-------+------------+--------+-------------------+----------+---------+---------------------------------------+------+----------+---------------------------------+
|id|select_type|table|partitions|type|possible_keys|key|key_len|ref|rows|filtered|Extra|
+----+-------------+-------+------------+--------+-------------------+----------+---------+---------------------------------------+------+----------+---------------------------------+
|1|SIMPLE|con|NULL|ref|FK_order,IDX_date|IDX_date|3|const|3074|100.00|Usingtemporary; Usingfilesort|
|1|SIMPLE|c|NULL|eq_ref|PRIMARY|PRIMARY|8|custom.con.c_id|1|100.00|Usingindex|
|1|SIMPLE|o|NULL|eq_ref|PRIMARY,dpcz_FK|PRIMARY|8|custom.con.order_id|1|100.00|Usingwhere|
|1|SIMPLE|pcz|NULL|eq_ref|PRIMARY|PRIMARY|8|custom.o.d_p_c_z_id|1|10.00|Usingwhere|
+----+-------------+-------+------------+--------+-------------------+----------+---------+---------------------------------------+------+----------+---------------------------------+
4rowsinset, 1warning (0.01sec)

结论

MySQL优化器依赖于表的统计信息的准确性来选择最优的执行计划。我们可以通过更改参数innodb_stats_persistent_sample_pages 来控制系统采集表统计信息的准确性。

我们还可以选择通过在对索引进行碎片整理的同时重建/重建表来强制重新计算表统计信息，这有助于提高表统计信息的准确性。重构表，我们可以直接用 alter table xx; 修改表或者使用 pt-online-schema-change 达到同样的效果。

文章来源网络，作者：管理，如若转载，请注明出处：https://shuyeidc.com/wp/308425.html<

赞 (0)
管理的头像管理
00
上一篇2025-05-27 14:08
下一篇 2025-05-27 14:09

相关推荐

  • jsp空间购买和交换数据空间怎么买，有哪些注意事项？技术资讯

    jsp空间购买和交换数据空间怎么买，有哪些注意事项？

    购买JSP空间时，是否考虑过数据交换空间的性能？简米科技（2003年始创，23年行业沉淀）与酷番云（工信部一类增值电信全牌照）这类持牌自营机房的服务商，能确保数据交换的高效稳定，是值得优先选择的合作伙伴，为什么JSP空间需要搭配独立的数据交换空间从JSP应用特性看数据交换需求JSP基于Java技术,常用于企业级……

    管理的头像管理
    2026-08-11
    0
  • 建网站用香港空间效果怎么样，香港空间稳定吗？技术资讯

    建网站用香港空间效果怎么样，香港空间稳定吗？

    建网站用香港空间，对于创建网站资产来说，核心价值在于免备案和全球带宽优势，尤其适合外贸、跨境电商和需要快速启动的项目，但你必须权衡国内访问延迟，并选择有资质的服务商以保证资产安全，香港空间的核心优势与适用边界免备案：节省时间就是节省成本国内服务器需要备案,通常需要10到20天，香港空间无需备案，域名解析后即可上……

    管理的头像管理
    2026-08-11
    0
  • Java连接云数据库的方法是什么，如何操作技术资讯

    Java连接云数据库的方法是什么，如何操作

    Java连接云数据库的核心在于通过JDBC驱动，结合云服务商提供的连接地址、端口、数据库名及认证信息，配置安全策略（如SSL、IP白名单），即可实现稳定高效的远程数据库访问，基础准备：JDBC驱动与依赖管理连接云数据库前,需要确保开发环境具备对应的JDBC驱动，以最常见的MySQL为例，你需要引入mysql-c……

    管理的头像管理
    2026-08-11
    0
  • 建网站公安联网备案必须使用数据码吗，备案流程是什么技术资讯

    建网站公安联网备案必须使用数据码吗，备案流程是什么

    网站备案包括ICP备案和公安联网备案，两者缺一不可，公安联网备案必须使用服务商提供的数据码，选择持有合法资质的服务商是顺利通过备案的前提，为什么网站必须进行公安联网备案根据公安部《计算机信息网络国际联网安全保护管理办法》，网站开通后30日内必须到公安机关办理备案手续，未完成公安备案的网站，面临责令整改、关闭网站……

    管理的头像管理
    2026-08-10
    0
  • 建一个企业网站大概需要多少钱？，怎么收费？技术资讯

    建一个企业网站大概需要多少钱？，怎么收费？

    建网站要多少钱，没有一个固定的数字，几百到几万都可能，但真正的“创建网站资产”绝不仅仅是初次投入的成本，而是基于长期稳定、合规和安全的持续性投入，其中核心取决于你选择了什么样的“地基”来承载你的业务，建站预算的构成与行业基准当你开始规划一个网站，最先面对的就是预算问题，一个常见的误区是只关注网站“看起来”的建造……

    管理的头像管理
    2026-08-10
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注