我是如何用2个Unix命令给SQL提速的

Posted 2021-04-30 InfoQ

译者 | 薛命灯

我试图在 MariaDB（mysql）上运行一个简单的连接查询，但性能简直糟糕透了。下面将介绍我是如何通过两个简单的 Unix 命令，将查询时间从 380 小时降到 12 小时以下的。

下面就是这个查询，它是 GHTorrent 分析的一部分，我使用了关系在线分析处理框架 simple-rolap 来实现这个分析。

select distinct
  project_commits.project_id,
  date_format(created_at, '%x%v1') as week_commit
  from project_commits
  left join commits
  on project_commits.commit_id = commits.id;

两个连接字段都有索引。不过，MariaDB 是通过对 project_commits 进行全表扫描和对 commits 进行索引查找来实现连接的。这可以从 EXPLAIN 的输出看出来。

这两个表中的记录比较多：project_commits 有 50 亿行记录，commits 有 8.47 亿行记录。服务器的内存比较小，只有 16GB。所以很可能是因为内存放不下那么大的索引，需要读取磁盘，因此严重影响到了性能。从 pmonitor 对临时表的分析结果来看，这个查询已经运行半天了，还需要 373 个小时才能运行完。

/home/mysql/ghtorrent/project_commits#P#p0.MYD 6.68% ETA 373:38:11

在我看来，这个太过分了，因为排序合并连接（sort-merge join）所需的 I/O 时间应该要比预计的执行时间要低一个数量级。我在 dba.stackexchange.com 上寻求帮助，有人给出了一些建议让我尝试，但我没有信心它们能够解决我的问题。我尝试了第一个建议，结果并不乐观。尝试每个建议都需要至少半天的时间，后来，我决定采用一种我认为可以有效解决这个问题的办法。

我将这两个表导出到文件中，使用 Unix 的 join 命令将它们连接在一起，将结果传给 uniq，把重复的行移除掉，然后将结果导回到数据库。导入过程（包括重建索引）从 20:41 开始，到第二天的 9:53 结束。以下是具体操作步骤。

1. 将数据库表导出为文本文件

我先导出连接两个表需要用到的字段，并按照连接字段进行排序。为了确保排序顺序与 Unix 工具的排序顺序兼容，我将字段转换为字符类型。

我将以下 SQL 查询的输出保存到文件 commits_week.txt 中。

select cast(id as char) as cid,
  date_format(created_at, '%x%v1') as week_commit
  from commits
  order by cid;

然后将以下 SQL 查询的输出保存到 project_commits.txt 文件中：

select cast(commit_id as char) as cid, project_id
  from project_commits
  order by cid;

这样就生成了以下两个文件。

-rw-r--r-- 1 dds dds  15G Aug  4 21:09 commits_week.txt
-rw-r--r-- 1 dds dds  93G Aug  5 00:36 project_commits.txt

为了避免内存不足，我使用 --quick 选项来运行 mysql 客户端，否则客户端会在输出结果之前尝试收集所有的记录。

2. 使用 Unix 命令行工具处理文件

接下来，我使用 Unix 的 join 命令来连接这两个文本文件。这个命令线性扫描两个文件，并将第一个字段相同的记录组合在一起。由于文件中的记录已经排好序，因此整个过程完成得很快，几乎就是 I/O 的速度。我还将连接的结果传给 uniq，用以消除重复记录，这就解决了原始查询中的 distinct 问题。同样，在已经排好序的输出结果上，可以通过简单的线性扫描完成去重。

这是我运行的 Unix 命令。

join commits_week.txt project_commits.txt | uniq >joined_commits.txt

经过一个小时的处理，我得到了想要的结果。

-rw-r--r-- 1 dds dds 133G Aug  5 01:40 joined_commits.txt

3. 将文本文件导回数据库

最后，我将文本文件导回数据库。

create table half_life.week_commits_all (
  project_id INT(11) not null,
  week_commit CHAR(7)) ENGINE=MyISAM;

load data local infile 'joined_commits.txt'
  into table half_life.week_commits_all
  fields terminated by ' ';




结   语

理想情况下，MariaDB 应该支持排序合并连接，并且在预测到备用策略的运行时间过长时，优化器应该使用排序合并连接。但在此之前，使用 70 年代设计的 Unix 命令就可以解决这个问题。

英文原文：

https://www.spinellis.gr/blog/20180805/

延展阅读

永远不要在 MySQL 中使用“utf8”

最近我遇到了一个 bug，我试着通过 Rails 在以“utf8”编码的 MariaDB 中保存一个 UTF-8 字符串，然后出现了一个离奇的错误：

Incorrect string value: ‘\xF0\x9F\x98\x83 <…’ for column ‘summary’ at row 1

我用的是 UTF-8 编码的客户端，服务器也是 UTF-8 编码的，数据库也是，就连要保存的这个字符串“ <…”也是合法的 UTF-8。

问题的症结在于，MySQL 的“utf8”实际上不是真正的 UTF-8。

“utf8”只支持每个字符最多三个字节，而真正的 UTF-8 是每个字符最多四个字节。

MySQL 一直没有修复这个 bug，他们在 2010 年发布了一个叫作“utf8mb4”的字符集，绕过了这个问题。

当然，他们并没有对新的字符集广而告之（可能是因为这个 bug 让他们觉得很尴尬），以致于现在网络上仍然在建议开发者使用“utf8”，但这些建议都是错误的。

简单概括如下：

• MySQL 的“utf8mb4”是真正的“UTF-8”。

• MySQL 的“utf8”是一种“专属的编码”，它能够编码的 Unicode 字符并不多。

我要在这里澄清一下：所有在使用“utf8”的 MySQL 和 MariaDB 用户都应该改用“utf8mb4”，永远都不要再使用“utf8”。

MySQL 的“utf8”字符集与其他程序不兼容，它所谓的“”，可能真的是一坨……

今日荐文

RocketMQ 4.3 正式发布

---