Rails中使用MySQL分区表一个提升性能的方法
MySQL的分区表是一种简单有效的处理极大数据表的特性，通过它可以使应用程序几乎很少改动就能达成对极大数据表的高效处理，但由于RailsActiveRecord设计上一些惯例，可能导致一些数据处理不能利用分区表特性，反而变得很慢，在使用分区表过程中一定要多加注意。
下面以一个例子来说明。在light系统中，有一张数据表是diet_items,主要字段是id,schedule_id,meal_orderfood_id,weight,calory等等，它的每一条记录表示为用户生成每日的减肥计划（减肥食谱+运动计划）中的一条饮食项，平均一条的计划有10多条数据，数据量非常大，预计每天生成数据会超过100万条，所以对其做了分表处理，根据schedule_idhash分成60张表，也就是数据将动态分到60张表中。分表后diet_items的建表语句如下所示：
CREATETABLE`diet_items`( `id`int(11)NOTNULLAUTO_INCREMENT, `schedule_id`int(11)NOTNULL, `meals_order`int(11)NOTNULL, `food_id`int(11)DEFAULTNULL, .... KEYid(`id`), UNIQUEKEY`index_diet_items_on_schedule_id_and_id`(`schedule_id`,`id`) ) PARTITIONBYHASH(schedule_id) PARTITIONS60;
分表之后，所有查询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_itemupdate操作ActiveRecord生成的sql语句类似于updatediet_itemsset…whereid=<id>。diet_itemdestroy生成的语句类似于deletediet_itemswhereid=<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条件，从而避免了扫描全部的分区表，性能提升立竿见影。