Rails中使用MySQL分區表一個提升效能的方法_ruby專題

MySQL 的分區表是一種簡單有效處理極大資料表的特性，通過它可以使應用程式幾乎很少改動就能達成對極大資料表的高效處理，但由於 Rails ActiveRecord 設計上一些慣例，可能導致一些資料處理不能利用分區表特性，反而變得很慢，在使用分區表過程中一定要多加註意。

下面以一個例子來說明。在 light 系統中，有一張資料表是 diet_items, 主要欄位是 id, schedule_id, meal_order food_id, weight, calory 等等，它的每一條記錄表示為使用者產生每日的減肥計劃（減肥食譜 + 運動計劃）中的一條飲食項，平均一條的計劃有 10 多條資料，資料量非常大，預計每天產生資料會超過 100 萬條，所以對其做了分表處理，根據 schedule_id hash 分成 60 張表，也就是資料將動態分到 60 張表中。分表後 diet_items 的建表語句如下所示：

複製代碼 代碼如下:

CREATE TABLE `diet_items` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `schedule_id` int(11) NOT NULL,
  `meals_order` int(11) NOT NULL,
  `food_id` int(11) DEFAULT NULL,
  ....
  KEY id (`id`),
  UNIQUE KEY `index_diet_items_on_schedule_id_and_id` (`schedule_id`,`id`)
)
PARTITION BY HASH (schedule_id)
PARTITIONS 60;

分表之後，所有查詢 diet_items 的地方都要求帶上 schedule_id，比如擷取某一個 schedule 的所有 diet_items，通過 schedule. diet_items，擷取某一個 id 的 diet_item 也是通過 schedule.diet_items.find(id) 進行。產生 diet_item 也沒有問題，因為產生 diet_item 都是通過 schedule.diet_items.build(data) 方式，在產生的時候都是帶了 schedule_id 的。

觀察 newrelic 日誌，發現 diet_item 的 update 和 destroy 相關的請求特別慢，仔細分析後，發現這兩種操作非常忙是由於 ActiveRecord 產生的 sql 並沒有帶 schedule_id 導致。 diet_item update 操作 ActiveRecord 產生的 sql 語句類似於 update diet_items set … where id = <id>。 diet_item destroy 產生的語句類似於 delete diet_items where id = <id> 因為沒有帶 schedule_id，導致這兩種語句都需要 mysql 掃描 60 張分區表才能夠完成一個語句執行，非常慢！

知道原因之後就好辦了，把原來的 update 和 destroy 調用改為自訂版本的 update 和 destroy 調用就可以了。

diet_item.update(attributes) 改成 DietItem.where(id: diet_item.id, schedule_id: diet_item.schedule_id).update_all(attributes)

diet_item.destroy 改成 DietItem.where(id: diet_item.id, schedule_id: diet_item.schedule_id).delete_all

這樣產生的 sql 都帶上 schedule_id 條件，從而避免了掃描全部的分區表，效能提升立竿見影。