InnoDB如何为information_schema计算table_rows？

Question

背景

所以，我理解，对于InnoDB表，来自table_rows的{​​{1}}“只是一个粗略估计”，并且由于事务的原因，计算确切的行数是非常重要的。

但是我有一些表information_schema在真实计数的几个百分点内，有些表是这样的：

table_rows

我认为你必须非常慷慨地称之为“粗略估计”。

没有公开交易;我没有偷偷删除几亿行;我运行mysql> SELECT table_rows FROM information_schema.tables WHERE table_name="__unit_previews"; +------------+ | table_rows | +------------+ | 226992266 | +------------+ 1 row in set (0.03 sec) mysql> SELECT COUNT(*) FROM __unit_previews; +----------+ | COUNT(*) | +----------+ | 144156 | +----------+ 1 row in set (0.14 sec) 以确保信息架构是最新的。

我正在运行MySQL 5.6.13（analyze table也说5.6.13），此表有@@innodb_version，每行有大约400kB的blob属性。 row_format=dynamic还报告information_schema为58020446208，data_length为255。

问题

那么InnoDB如何为avg_row_length计算table_rows？

可能相关：它如何确定information_schema.tables和data_length？这是否包括“外部”blob存储（即关闭B树页但仍由InnoDB管理）？

如果在SQL优化中使用avg_row_length，我是否应该担心它会被关闭3个数量级？

是否有更好的方法来估算table_rows中可用属性的行数？

Answer 1

您所做的DELETE会产生影响。

InnoDB确切地知道Data_length的价值。从探针（旧版本中的8个），它有一些感觉（授予，非常差的感觉）的东西分布。我认为估计值为Avg_row_length，然后除以table_rows。

再次运行ANALYZE;第一个数字将保持不变;另外两个会改变。

TEXT和BLOB字段（等）以不同的方式存储在块外存储中，具体取决于ROW_FORMAT。这增加了混乱和计算。

较新的版本（自5.6.6起？）做得稍好一些。

被关闭1000倍是非常糟糕的。我很少看到超过2倍（任一方向）。

我刚尝试了一张与你相似的桌子，并得到了7分。呵呵 - ANALYZE让行数远离真相。 OPTIMIZE让它变得更好，但仍然是5倍。哦，好吧。

建议您在http://bugs.mysql.com上发布错误。