我是如何用2個Unix命令給SQL提速的

我試圖在 mariadb（mysql）上執行乙個簡單的連線查詢，但效能簡直糟糕透了。下面將介紹我是如何通過兩個簡單的 unix 命令，將查詢時間從 380 小時降到 12 小時以下的。

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 的輸出看出來。

/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 , 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 命令就可以解決這個問題。

英文原文：

延展閱讀

永遠不要在 mysql 中使用「utf8」

最近我遇到了乙個 bug，我試著通過 rails 在以「utf8」編碼的 mariadb 中儲存乙個 utf-8 字串，然後出現了乙個離奇的錯誤：

incorrect string value: 『\\xf0\\x9f\\x98\\x83

我用的是 utf-8 編碼的客戶端，伺服器也是 utf-8 編碼的，資料庫也是，就連要儲存的這個字串「

問題的癥結在於，mysql 的「utf8」實際上不是真正的 utf-8。

「utf8」只支援每個字元最多三個位元組，而真正的 utf-8 是每個字元最多四個位元組。

mysql 一直沒有修復這個 bug，他們在 2010 年發布了乙個叫作「utf8mb4」的字符集，繞過了這個問題。

當然，他們並沒有對新的字符集廣而告之（可能是因為這個 bug 讓他們覺得很尷尬），以致於現在網路上仍然在建議開發者使用「utf8」，但這些建議都是錯誤的。

簡單概括如下：

我要在這裡澄清一下：所有在使用「utf8」的 mysql 和 mariadb 使用者都應該改用「utf8mb4」，永遠都不要再使用「utf8」。

mysql 的「utf8」字符集與其他程式不相容，它所謂的「」，可能真的是一坨……

今日薦文

我是如何用2個Unix命令給SQL提速的

我是如何用2個Unix命令給SQL提速的

我是如何用Worktile進行敏捷開發的

我是如何用 redis 做實時訂閱推送的

我是如何用2個Unix命令給SQL提速的

我是如何用2個Unix命令給SQL提速的

我是如何用Worktile進行敏捷開發的

我是如何用 redis 做實時訂閱推送的

相關推薦