我試圖在 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”字符集與其他程序不兼容，它所謂的“”，可能真的是一坨……
大連割包皮醫院××× http://bp.39552222.com/
大連割包皮醫院 http://bp.84211111.com/
大連最好的×××醫院 http://mobile.dlbhnk.com/