分表分库浅谈 - 数据库最佳实践系列
早在 Web 互联网时代，数据已经很庞大，到了移动互联时代，数据更大了，一个稍微知名的 App ，不到半年的光景，数据已经不是一台服务能装得下了，工作中，碰到了这样的事情，喜出望外之后，有点发愁了，数据日益剧增，小团队找不到更好的方案。
看了很多知名团队的方案，都如出一辙，基本原理就是数据库分布式架构，分表分库。
分表分库，其实是两个不同的策略，什么时候需要分表（或表分区）呢？个人认为，单表数据量很大，一张表接近千万条记录的时候，就应该做好分表的事情了，实际应用中，个人发现 MySQL 单表到了 300 万条，读写数据已经不是那么流畅了。
至于分库又是什么时候需要做的？分库通常是把数据库安装在一个以上的服务器上（也可以单机开多个数据库实例，前提服务器资源足够大，io 足够强），多个服务器上安装一样结构的数据库，分若干个主从库，保持数据同步，保证数据的一致性，更细致的话，需要读写分离。由此得知，分库是一个比较繁琐的事情，不得已不轻易用，只有到了整个数据库的请求响应时间很缓慢，已不能正常响应程序的大部分请求，才会考虑。请求响应时间缓慢也是有其他原因的，比如某些表数据量太大而缓慢，其他表都正常，这种不宜马上分库，优先考虑先局部分表。
如果分表分库，引发一些程序结构上的变化，那么就需要考虑该方案的合不合适了。分库，有时候也会影响程序事务的正常运转，搞不好，之前好好的程序，分库之后，一切就不那么正常了，比如事务，延时等等问题。
哇~~~ 竟然还没有评论！