MySQL分區表是處理最大數據表的一個簡單有效的特性，通過使用這個應用程序可以在很少更改的情況下高效地處理最大數據表，下面就跟著武林技術頻道小編的步伐來學習Rails之MySQL分區表提升性能的方法，一起來看看吧！

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

?

?

分表之后，所有查詢 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 條件，從而避免了掃描全部的分區表，性能提升立竿見影。

看了上面的介紹，相信大家對于Rails之MySQL分區表提升性能的方法，已經有了自己的認識，希望大家有任何疑問可以在武林技術頻道小編進行留言。