提高仅增长表的计数记录性能（不删除）

Question

我已经阅读了很多关于计数记录性能的答案，例如https://stackoverflow.com/a/1332730/7906257，并且都说没有简单的解决方案。我使用 InnoDB 并且有 CL_GAME 表和 PK 主键。最重要的是我有一个特殊的用例，它绝对可以优化：记录永远不会从表中删除，而只会添加。是否可以说 MySQL 在计算记录时跳过内部验证（如上面链接中所述）：

SELECT COUNT(pk) FROM CL_GAME WHERE pk <= 1072370;

有些想法并不完美：

1. 一个明显的技巧是规范化表并消除pk之间的任何间隙。所以 pk 反映了之前的记录数。但这看起来很危险，因为某些还原的事务可能会破坏它（好吧，有一些不平凡的解决方案，例如https://www.percona.com/blog/2011/11/29/avoiding-auto-increment-holes-on-innodb-with-insert-ignore/）

2. 另一个想法是有一个额外的表，其中包含对 其中 count 是 pk pk 来自对 的记录数。因此，可以只计算表的一部分并使用预先计算的值。但我更愿意避免任何额外的结构/缓存，因为实现、验证和支持它们需要时间

Answer 1

最后我决定计数的精度并不重要。所以有几种解决方案：

1. TABLE STATUS - 不好，因为 对于 InnoDB，这个值是一个近似值，可能与实际值相差 40% 到 50%
2. 保持缓存的count 值和pk 为其计算了计数。插入新记录后，计算插入记录的旧 pk (pk_old) 和 pk (pk_new) 之间的记录。任何一种这样的实现都存在问题：由于回滚当前事务，或者另一个事务在 pk_old 和 pk_new 之间插入了一条记录，但尚未提交，计数和实际计数之间的差异可以无限增加
3. 每次插入后增加缓存count。在服务器重新启动之前，事务可能会回滚并且计数会出错

我选择了方法#3，因为它既简单又最快（服务器启动时只有一个 sql 查询）

Answer 2

您预计有多少行？多久需要一次COUNT？这个数字需要有多精确？

• 如果不需要准确的答案，请参阅TABLE STATUS 中的Rows。
• InnoDB 将使用“最小”索引进行计数，因此添加这样一个索引。 “最小”二级索引可能是最小列（PK 中的第一列除外）上的索引。 TINYINT，如果你有的话，只有 1 个字节。
• TRIGGER 可以进行计数。
• 如果稍微陈旧的计数足够好，那么存储在某处的定期COUNT(*) 就可以了。
• 或者您可以将其视为数据仓库应用程序中“汇总表”的一个简单特例。这可能有每日计数；那么您需要计算今天的行数才能完成总数。 （看到SHOW CREATE TABLE 会有所帮助。然后我可以更具体。）

Answer 3

您可以稍微改进您的第二个选项。您不需要用于 pk->count 匹配的持久表。您将只使用该表中的最新记录。

您可以将此值保存在内存/服务中并定期更新它们，而不是表。它仍然需要一些额外的编码工作，但您将避免为计算旧记录而进行过多的表扫描。

请记住，未提交的事务可能会插入其他事务不可见的记录。换句话说，为这个 pk->count 匹配保留的 pk 值应该小于活动事务中的任何 pk。