Question

我有一个21.000.000行和13列的InnoDB表。包括此表在内的所有查询都很长;索引列的SELECT，例如：

SELECT SQL_NO_CACHE COUNT(id) FROM t;
1 row in set (29.86 sec)

我进行了一些搜索（例如"SELECT COUNT(*)" is slow, even with where clause），同一问题的所有答案都是：我的表格是碎片化的。但是当我看到这些信息时，它不喜欢如此分散：

> SELECT * FROM information_schema.tables WHERE TABLE_NAME="t" AND table_schema="s"\G;
    DATA_LENGTH: 1726447616
   INDEX_LENGTH: 3371892736
      DATA_FREE: 8388608

这给了我（使用http://meinit.nl/optimize-only-fragmented-tables-mysql方法）一个非常低的碎片值：

8388608/(1726447616+3371892736) = 0.16%

我唯一的解决方案是：

运行OPTIMIZE TABLE，但它会锁定表格，目前在生产模式下这是不可接受的（评估为5小时锁定）
运行ALTER TABLE t ENGINE=InnoDB（来自https://dba.stackexchange.com/questions/16341/how-do-you-remove-fragmentation-from-innodb-tables），它只会锁定read，但出于同样的原因无法接受。

在我以维护模式进行生产之前，您还有其他解决方案吗？

Mysql COUNT执行时间太长

0 个答案: