选择重复项会使每个查询的结果计数不同

Question

我目前正在尝试删除MySQL 5.7（InnoDB）中的重复行，并正在通过运行mediumtext检查以查看我对SELECT COLUMN, COUNT(*) FROM TABLE GROUP BY COLUMN HAVING COUNT(*) > 1列有多少重复。最新查询返回：

[results]
31620 rows in set (17.98 sec)

如果稍后再运行完全相同的查询，则会得到：

[results]
31594 rows in set (17.35 sec)

以此类推。我几乎每次都得到不同的结果。查询期间没有任何写入数据库的操作。 它仅通过此查询进行； SELECT COUNT(*) FROM TABLE，SELECT COUNT(*) FROM TABLE WHERE COLUMN LIKE <VALUE>等，都产生一致的结果。 执行SELECT COLUMN, COUNT(*) FROM TABLE GROUP BY COLUMN HAVING COUNT(*) > 0 时也不会发生此错误。

我不确定要提供什么其他代码来帮助回答这个问题，因为这是我正在运行的唯一查询，并且我正在控制台中执行。我正在尝试考虑可能导致这种情况的原因。鉴于我在同一个数据库中曾经使用过other problems，我想知道是否有损坏的东西。

编辑：我已经运行了1000个查询来对结果进行采样，结果如下所示：

最常见的结果是33991的上限。

表的字符集为utf8mb4，要聚合的列的排序规则为utf8mb4_general_ci。

使用MyISAM时EXPLAIN SELECT COLUMN, COUNT(*) FROM COLUMN GROUP BY COLUMN HAVING COUNT(*) > 1;的输出：

+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+---------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows   | filtered | Extra                           |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+---------------------------------+
|  1 | SIMPLE      | TABLE  | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 788685 |   100.00 | Using temporary; Using filesort |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+---------------------------------+

InnoDB的结果：

+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+---------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows   | filtered | Extra                           |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+---------------------------------+
|  1 | SIMPLE      | TABLE  | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 769501 |   100.00 | Using temporary; Using filesort |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+---------------------------------+

到目前为止，我在评论中建议的尝试：

• Memtest，使用memtest Linux程序包并运行memtest 15G 2（系统具有16G内存，可用内存为15.4，正在使用约0.4。这是一台云计算机，我无法使用Memtest引导，尽管我已向提供商提出要求，以查看他们是否可以。
• 启用常规日志，该日志显示查询之间没有其他活动在运行。
• 使用OPTIMIZE TABLE。
• 删除并重新添加索引。
• 将表引擎从InnoDB更改为MyISAM，这似乎有所帮助，因为在经过几次查询后，查询现在达到了最大限制，但对于最初的少数查询仍然会反弹。

Answer 1

我对mysql的有限了解触发了我对TEXT类型列的幻想，我认为在TEXT类型列中，表中的默认存储大小为256，其余文本大小存储在某些内部临时mysql表中。并且由于mysql客户端和mysql服务器的“ max_allowed_pa​​cket”属性是不同的，所以我认为每当mysql服务器向您的客户端发送整个文本的不同子集时，就有这种可能性。

您应该能够为mysql客户端增加“ max_allowed_pa​​cket”属性，并验证您是否确实获得了一致的结果。

Answer 2

POSSIBLE KEYS  |   KEY
NULL          |  NULL

它表示执行分组依据时，您没有使用任何索引。 在该列上添加特定的索引。