【问题标题】:rows in mysql explain bigger than real rowsmysql 中的行解释比实际行大
【发布时间】:2017-04-30 15:16:08
【问题描述】:

数据库:Mysql 5.6, Innodb,

解释结果:

真实数据:

我很困惑 16462900 是从哪里来的。当我设置 6 wave_no 时,解释结果中的行数为 6:

【问题讨论】:

标签: mysql performance explain


【解决方案1】:

EXPLAIN 输出中rows 的值是对将要检查的行数的估计值。

这只是一个估计,基于计算出的统计数据。

参考资料:

http://dev.mysql.com/doc/refman/5.6/en/explain-output.html

http://dev.mysql.com/doc/refman/5.6/en/innodb-persistent-stats.html

【讨论】:

  • 但真正的行是 360408,有没有可能解释的行比真正的行大得多?
  • @Cedric:是的,EXPLAIN 输出中为rows 报告的值可能大于(或小于)表中的行数。这不是 准确 的行数。优化器估计要检查的行数。 (估计有很多不同的原因有很多......统计信息不是最新的,InnoDB 用于统计的页面上的键值分布等。)你问的问题是“[行在哪里EXPLAIN 输出中的值] 来自?”它来自优化器,基于表/索引统计信息。
  • “索引不起作用”是什么意思? EXPLAIN 输出显示执行计划将使用IDX_COM_WAVE 索引。
【解决方案2】:

使用此“复合”索引来提高性能:

INDEX(com_uid, exchange_state, wave_no)

并删除FORCE

统计数据有时相差甚远。如果有 TEXTBLOB 列存储在其他地方,则尤其会发生这种情况,从而弄乱了算术。不用担心。

可以执行ANALYZE TABLE 重新计算统计数据,但这可能不会改善统计数据。

【讨论】:

    【解决方案3】:

    我的大学说是因为表格碎片,你可以去谷歌搜索一下,这里是one

    MySQL 表,包括 MyISAM 和 InnoDB 这两种最常见的类型,在随机插入和删除数据时会出现碎片。碎片会在您的桌子上留下大洞,扫描桌子时必须阅读这些块。因此,优化您的表可以提高全表扫描和范围扫描的效率。

    这是官方网站的article

    【讨论】:

      猜你喜欢
      • 2021-09-01
      • 1970-01-01
      • 2020-01-06
      • 2021-06-11
      • 1970-01-01
      • 2019-09-13
      • 2013-05-18
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多