三国讲：话说天下大势，分久必合，合久必分；我们的数据库优化也需要这个“分”字。
当我们的数据量很小的时候，我们会把用户表，博客表，论坛表，闪存表等等都砸在一个库里，我们的业务增长的很好，在不久之后我们尽力的优化了查询，但是效果依然不佳，这时候用分字诀的时机到了。
如果你有先见之明的话，会给表名，存储过程的名字加上前缀，例如论坛表命名为BBS_xxx，博客表命名为BLOG_xxx；这样的话在分表处理时会比较容易一些。说到这儿也许你会想到外键约束怎么办，我的博客表，论坛帖子表都有用了User表的主键做外键呀。这个很容易处理，我们需要当机立断的删掉外键，这个当机立断可能会带来一些麻烦，我们来分析下可能会遇到一些什么问题：
1. 分成多个库，没了外键了以前的inner join操作要跨库吗？
假定场景：博客表有对用户表的外键引用，我们需要在首页显示博客列表，博客列表需要显示用户名和用户id的信息
之前用户表，博客表在一个库里面的时候我们可以通过外键inner join来取得用户的关联信息，现在用户库和博客库被拆成了两个库，我想对跨库做inner join说no；为什么呢，因为这不适合扩展，假如有一天我们的业务量又增长了我们就需要把用户库挪到另外一台机器上，这要导致inner join跨服务器了，这显然不是一个好办法，那该怎么办呢？ 我有两种方案，大家评判好坏：
1）做违反范式的设计，将用户的不变信息用户名和用户id一起存在博客表中，让用户名冗余吧，这样做可以保证取博客数据连带用户名时是非常高效率的
2）我们不再从数据库中取用户名的信息，改从缓存中取，我们可以在缓存中形成一个最近活跃的用户数据池，当我们需要用户名时从这个缓存区中去取。
目前在我的应用中用的是第一种方案，第二种更有伸缩性，第一种存冗余数据只能存用户名，有时候只存用户名就够了，有时候可能会出现不够的问题。
2. 如果用到了根据外键做的级联删除，那这是一个噩梦
对付这个问题，我的方案是修改程序，如果需要级联删除，在程序逻辑中完成，不要在数据库做级联删除了，级联删除是一种隐含在数据库中的逻辑，是一种不好的设计方案。
3. 触发器也可能带来和外键做级联删除同样的麻烦，同样的也是修改程序逻辑，代替这种数据库级别的隐含逻辑。
也许你会说分库之后一定会带来性能的提高吗？这个问题得具体分析，这要看你的服务器性能如何，如果分库之后数据库的cpu，io，内存的压力依然很大；那么您可以将分库之后的其中某一个库迁移到另外一台服务器上，让两台服务器分摊数据访问的压力，肯定会提升性能的。
最后说下，分库分与不分是由数据量、性能要求决定的。下篇分表敬请期待！