MySQL 优化：DISTINCT 太慢答案

【问题标题】：MySQL Optimization: DISTINCT too slowMySQL 优化：DISTINCT 太慢
【发布时间】：2020-05-28 04:28:29
【问题描述】：

我有一个表格查询

SELECT COUNT(*)
FROM 
   table1, table2, table3, table4, table5, table6
where (several conditions to join the tables)

执行需要几分钟（结果计数为 20 亿）。

问题是当我在这里添加一个 DISTINCT 时：

SELECT COUNT(  DISTINCT field1, field2, field3, field4, field5   )
FROM 
   table1, table2, table3, table4, table5, table6
where (several conditions to join the tables)

执行时间超过 3 小时。

问题似乎出在 DISTINCT 操作上，因为两个版本的 JOIN 条件相同。有什么办法可以优化 DISTINCT 版本的执行？

谢谢！

【问题讨论】：

你没有使用正确的、明确的、标准 JOIN 语法吗？在几乎所有这样的情况下，问题在于 JOIN 条件设置不正确。
因为它是由专有的 ETL 生成的代码...
无论如何，如果de JOIN条件的问题，两个版本都会出现缓慢问题。
优化器怎么说。发表你的解释
您需要更具体地了解与 DISTINCT 进行比较的列。他们来自同一张桌子，不同的桌子吗？顺便说一句，对于 20 亿行的比较来说，3 小时听起来还不错）。

标签： mysql sql database mariadb database-administration

【解决方案1】：

执行需要几分钟（结果计数为 20 亿）。

为了处理count(distinct)，MySQL 必须对 20 亿行进行排序。这是很多数据。

这需要很多很多时间。对此您无能为力，除非您可以修改查询以使中间数据不那么大。

【讨论】：

【解决方案2】：

如果不更改 SQL 语句，或者不更改表的结构（例如，添加一些索引或一些新的中间汇总表），那么可能无法让 DISTINCT 版本的查询运行得更快。

就经过的时间而言，“大石头”很可能是“使用文件排序”操作。我们使用EXPLAIN查看查询执行计划；这是我们快速了解 MySQL 正在执行哪些操作、以什么顺序执行的第一步。

在 MySQL 和 MariaDB 中有一些系统参数可以调整，例如为临时集分配更多内存，以便在溢出到磁盘之前保存在 MEMORY 中；但不太可能有一个神奇的调整来解决 20 亿行的性能问题。并且总是可以选择使用更多更好的硬件来解决问题。

如果您愿意更改 SQL 语句或运行多条语句，那么可能会有调整的机会。

【讨论】：

【解决方案3】：

您是否尝试过使用新的选择语句进行左连接，这些语句仅具有不同的单词？

【讨论】：

在 MySQL 中，外部连接不能使用老式的逗号连接语法。并且 OP 没有提供尝试重写 SQL 文本的证据，因此我可以非常肯定地假设您的问题的答案是“否”。