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

Question

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

[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 |
+----+-------------+-------+------------+------+---------------+------+---------+------+--------+----------+---------------------------------+

到目前为止，我已经尝试过 cmets 中的建议：

• 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

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