这里笔者推荐一个比较靠谱的过渡技术–“表分区”。主流的关系型数据库中基本都支持。不同的分区在逻辑上仍是一张表，但是物理上却是分开的，能在一定程度上提高查询性能，而且对应用程序透明，无需修改任何代码。笔者曾经负责优化过一个系统，主业务表有大约8000W左右的数据，考虑到成本问题，当时就是采用“表分区”来做的，效果比较明显，且系统运行的很稳定。
小结
最后，有很多读者都想了解当前社区中有没有开源免费的分库分表解决方案，毕竟站在巨人的肩膀上能省力很多。当前主要有两类解决方案：
基于应用程序层面的DDAL(分布式数据库访问层)
比较典型的就是淘宝半开源的TDDL，当当网开源的Sharding-JDBC等。分布式数据访问层无需硬件投入，技术能力较强的大公司通常会选择自研或参照开源框架进行二次开发和定制。对应用程序的侵入性一般较大，会增加技术成本和复杂度。通常仅支持特定编程语言平台(Java平台的居多)，或者仅支持特定的数据库和特定数据访问框架技术(一般支持MySQL数据库，JDBC、MyBatis、Hibernate等框架技术)。
数据库中间件，比较典型的像mycat(在阿里开源的cobar基础上做了很多优化和改进，属于后起之秀，也支持很多新特性)，基于Go语言实现kingSharding，比较老牌的Atlas(由360开源)等。这些中间件在互联网企业中大量被使用。另外，MySQL 5.x企业版中官方提供的Fabric组件也号称支持分片技术，不过国内使用的企业较少。
中间件也可以称为“透明网关”，大名鼎鼎的mysql_proxy大概是该领域的鼻祖(由MySQL官方提供，仅限于实现“读写分离”)。中间件一般实现了特定数据库的网络通信协议，模拟一个真实的数据库服务，屏蔽了后端真实的Server，应用程序通常直接连接中间件即可。而在执行SQL操作时，中间件会按照预先定义分片规则，对SQL语句进行解析、路由，并对结果集做二次计算再最终返回。引入数据库中间件的技术成本更低，对应用程序来讲侵入性几乎没有，可以满足大部分的业务。增加了额外的硬件投入和运维成本，同时，中间件自身也存在性能瓶颈和单点故障问题，需要能够保证中间件自身的高可用、可扩展。
总之，不管是使用分布式数据访问层还是数据库中间件，都会带来一定的成本和复杂度，也会有一定的性能影响。所以，还需读者根据实际情况和业务发展需要慎重考虑和选择。