数据库水平切分的实现原理解析

LZ写道：
基于此就有如下三种分库的方式和规则：（当然还可以有其他的方式）
按号段分：
(1) user_id为区分，1～1000的对应DB1，1001～2000的对应DB2，以此类推；
优点：可部分迁移
缺点：数据分布不均

(2)hash取模分：
对user_id进行hash（或者如果user_id是数值型的话直接使用user_id的值也可），然后用一个特定的数字，比如应用中需要将一个数据库切分成4个数据库的话，我们就用4这个数字对user_id的hash值进行取模运算，也就是user_id%4,这样的话每次运算就有四种可能：结果为1的时候对应DB1；结果为2的时候对应DB2；结果为3的时候对应DB3；结果为0的时候对应DB4，这样一来就非常均匀的将数据分配到4个 DB中。
优点：数据分布均匀
缺点：数据迁移的时候麻烦，不能按照机器性能分摊数据
(3)在认证库中保存数据库配置
就是建立一个DB，这个DB单独保存user_id到DB的映射关系，每次访问数据库的时候都要先查询一次这个数据库，以得到具体的DB信息，然后才能进行我们需要的查询操作。
优点：灵活性强，一对一关系
缺点：每次查询之前都要多一次查询，性能大打折扣
以上就是通常的开发中我们选择的三种方式，有些复杂的项目中可能会混合使用这三种方式。通过上面的描述，我们对分库的规则也有了简单的认识和了解。当然还会有更好更完善的分库方式，还需要我们不断的探索和发现。
________________________________________________________________
楼上的大牛很多，只提醒一点不成熟的意见：你的三种方式或其它的实现方式，是不是要考虑一下对代码的侵入是否严重？。
另LZ提到：
数据切分也可以是数据库内的，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中，比如将article分为article_001,article_002等子表，若干个子表水平拼合有组成了逻辑上一个完整的article表。。。。

你这个不叫设计了，准确的说应该是具体应用的设计方案了吧？？ 不可能人家做个项目用你的框架还要根据你框架的特色做一些特殊的设计吗？个人觉得一个出色的框架最起码有二点要注意的。1.最少侵入。2最少干扰（数据设计）。所以有关“数据切分也可以是数据库内的”这一观点是不是不太可取？说得不对请指正。

我这里所说的数据库内的也就是说分表的应用场景
至于侵入性，如果对程序没有一点侵入性的话，我想就只有通过在数据库服务端去做了吧。。。
是的，用这个框架就是要有牺牲，甚至牺牲的更多，比如不能有join等，还会有反范式的数据库设计。。。

Lz排版再好点就好了

确实...有点眼花

这段时间比较忙 也没有时间去写后续的。。。等空下来之后一定接着写下去 排版肯定也要注意了
嘿嘿

2哥我等着你的更详细的设计思路，学习学习。

言简意赅的文章比较好~

希望能快点把后续写完，对很少有这样实际经验的人来说，是难得的资料，lz辛苦了！

说的很有道理，楼主宏观概念介绍的很详细了，但请不要忘记“细节决定成败”一些貌似完美的设计往往因为某些“细微”问题无法得到好的解决导致整个产品的失败。建议楼主在续完这篇文章后针对水平切分数据库的几个细节问题再进行论证：1.什么情况下需要水平切分？（而不适合使用分区表）。2.多数据库应用（包含水平切分）的事务控制问题。3.数据备份和容灾问题。

后续的 可能要等一段时间了  这段时间很忙。。。这个个框架现在已经投入实际的使用了。。稳定性需要考验啊