因为性能问题，对数据表进行了水平切分。切分方案如下：
一个大的用户表user表，按user_id的值进行切分，
user_id%3=0(数据库0)
user_id%3=1(数据库1)
user_id%3=2(数据库2)
user_id被3求模后分别存放到3个数据库中。这样做的好处是减轻了单表大数据量引起的性能问题。但是随之遇到一些问题，
1.对于批量删除有什么好的方案。
1）删除指定user_id范围的数据，比如user_id>302 and user_id<3400;这样的需求如何处理高效，难道必须要循环范围内每个id，然后算出其存放在哪个数据库，然后删除之。或者先在这个范围内统计出3个数据库的id列表，然后执行三次批量删除。总感觉这些方案效率都不高。
2）删除某个条件的数据，比如delete user where user.name like '%ggg%' and .. 这里可能有更复杂的过滤条件。这就比较麻烦了。。
2.对于更新数据有类似删除一样的问题。
1）类似update user set name='aa' where user_id>302 and user_id<3400的处理。
2）类似于删除。。
3.查询问题：
1）根据用户id范围查询，比如select * from user where user_id>302 and user_id<3400
2）根据其他条件查询。以上的这些问题，我想是很通用的问题，任何做数据水平切分处理的时候都会遇到，大家有没有好的解决方案，一起探讨下。
一个大的用户表user表，按user_id的值进行切分，
user_id%3=0(数据库0)
user_id%3=1(数据库1)
user_id%3=2(数据库2)
user_id被3求模后分别存放到3个数据库中。这样做的好处是减轻了单表大数据量引起的性能问题。但是随之遇到一些问题，
1.对于批量删除有什么好的方案。
1）删除指定user_id范围的数据，比如user_id>302 and user_id<3400;这样的需求如何处理高效，难道必须要循环范围内每个id，然后算出其存放在哪个数据库，然后删除之。或者先在这个范围内统计出3个数据库的id列表，然后执行三次批量删除。总感觉这些方案效率都不高。
2）删除某个条件的数据，比如delete user where user.name like '%ggg%' and .. 这里可能有更复杂的过滤条件。这就比较麻烦了。。
2.对于更新数据有类似删除一样的问题。
1）类似update user set name='aa' where user_id>302 and user_id<3400的处理。
2）类似于删除。。
3.查询问题：
1）根据用户id范围查询，比如select * from user where user_id>302 and user_id<3400
2）根据其他条件查询。以上的这些问题，我想是很通用的问题，任何做数据水平切分处理的时候都会遇到，大家有没有好的解决方案，一起探讨下。
不管你你delete/update的数据是否在制定的数据库，都要在这个些数据库中执行一次SQL,如果分的数据库多了可能要牺牲点性能。另外，我突然想起来一个分表的问题：
以前有个项目，在同一个数据库中，对同一表进行分表处理，由于该表数据量相当大，每天都400万数据，这样我们采取的方案是每天生成一个表存储。
这种情况下的删除/更新/查询就比较麻烦，因为不可能对这个N个表都执行一次SQL吧。每天一个表是很多的。
先在删除/更新/查询的范围内统计出3个数据库的id列表，然后执行三次批量SQL，是这样吗，我也只能想到这个办法。但是对于条件不是user_id的处理好像这样就不行。比如类似：where user.name like '%ggg%' and ..
相同处：都是对同一数据表中的数据按一定的分隔规则分成多个数据表保存。
不同处：
1.存放的数据库不一样：
数据水平切分：将分开的数据表放在不同的数据库中。
分表处理：将分开的数据表放在原来的数据库中。
2.数据表的表名处理不同。
数据水平切分：分开的数据表表名跟原来的表名一样。
分表处理：分开的数据表表名不一样，一般以某字段的值的范围命名，如按日期命名，user_20091021
3.选择方案的背景不同：
数据水平切分：一般采取这个方案有2个目的：1)为了解决单表数据量大引起的性能问题，这个与分表的背景一样，2）为了分担单个数据库压力。
分表处理：主要是解决单表数据量大引起的性能问题，而此时整个数据库的压力并不大。以上是本人的个人观点，希望大家一起探讨。