MySQL 的分區(qū)表是一種簡(jiǎn)單有效的處理極大數(shù)據(jù)表的特性，通過(guò)它可以使應(yīng)用程序幾乎很少改動(dòng)就能達(dá)成對(duì)極大數(shù)據(jù)表的高效處理，但由于 Rails ActiveRecord 設(shè)計(jì)上一些慣例，可能導(dǎo)致一些數(shù)據(jù)處理不能利用分區(qū)表特性，反而變得很慢，在使用分區(qū)表過(guò)程中一定要多加注意。

下面以一個(gè)例子來(lái)說(shuō)明。在 light 系統(tǒng)中，有一張數(shù)據(jù)表是 diet_items, 主要字段是 id, schedule_id, meal_order food_id, weight, calory 等等，它的每一條記錄表示為用戶(hù)生成每日的減肥計(jì)劃（減肥食譜 + 運(yùn)動(dòng)計(jì)劃）中的一條飲食項(xiàng)，平均一條的計(jì)劃有 10 多條數(shù)據(jù)，數(shù)據(jù)量非常大，預(yù)計(jì)每天生成數(shù)據(jù)會(huì)超過(guò) 100 萬(wàn)條，所以對(duì)其做了分表處理，根據(jù) schedule_id hash 分成 60 張表，也就是數(shù)據(jù)將動(dòng)態(tài)分到 60 張表中。分表后 diet_items 的建表語(yǔ)句如下所示：

分表之后，所有查詢(xún) diet_items 的地方都要求帶上 schedule_id，比如獲取某一個(gè) schedule 的所有 diet_items，通過(guò) schedule. diet_items，獲取某一個(gè) id 的 diet_item 也是通過(guò) schedule.diet_items.find(id) 進(jìn)行。生成 diet_item 也沒(méi)有問(wèn)題，因?yàn)樯?diet_item 都是通過(guò) schedule.diet_items.build(data) 方式，在生成的時(shí)候都是帶了 schedule_id 的。

觀察 newrelic 日志，發(fā)現(xiàn) diet_item 的 update 和 destroy 相關(guān)的請(qǐng)求特別慢，仔細(xì)分析后，發(fā)現(xiàn)這兩種操作非常忙是由于 ActiveRecord 生成的 sql 并沒(méi)有帶 schedule_id 導(dǎo)致。 diet_item update 操作 ActiveRecord 生成的 sql 語(yǔ)句類(lèi)似于 update diet_items set … where id = <id>。 diet_item destroy 生成的語(yǔ)句類(lèi)似于 delete diet_items where id = <id> 因?yàn)闆](méi)有帶 schedule_id，導(dǎo)致這兩種語(yǔ)句都需要 mysql 掃描 60 張分區(qū)表才能夠完成一個(gè)語(yǔ)句執(zhí)行，非常慢！

知道原因之后就好辦了，把原來(lái)的 update 和 destroy 調(diào)用改為自定義版本的 update 和 destroy 調(diào)用就可以了。

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 條件，從而避免了掃描全部的分區(qū)表，性能提升立竿見(jiàn)影。

最新評(píng)論