关于数据库的架构选择

    注：这篇文章里面的数据库以mysql为例。

    从最基础的单库开始讲，一般地，单表不要超过一千万条记录，多了会出各种各样的问题。如果数据库读相对超出较多，则可以使用读写分离方案，读写分离基于binlog实现，里面的一条记录对应着表的每一个动作，可以看成是原子操作，主库里每一次更新操作都会记在binlog中，并且会更新到从库。当然，伴随着主从复制（读写分离）的是主主复制，主主复制用来增强数据库的可用性，当一个数据库挂了另一台主和它的从库会接着跟上（切库的过程中会伴随着几秒钟的数据丢失，这个损失无法解决），主主之间也是通过binlog来同步数据，程序和数据库之间只能同时和一个库进行交互，否则会出现数据混乱（同一条记录连续更新而同步却来不及跟上就会出现），值得一提的是不管是主从复制还是主主复制都无法提高写的并发量。

    随着公司业务发展，单台服务器无法支撑系统运行了，这时候就要考虑分片了。分片过程中一张表会被分成多个表结构完全相同的表，无论这多个表是在同一个schema当中还是在多个schema当中都可以称为分片，如果业务量增长有限，这样不用考虑以后因为数据增长加schema导致数据混乱的问题，可以在程序里面对多个表进行逻辑处理，逻辑处理过程中要注意不要写含有join的sql了，而是要分别对多个库进行处理，再代码里面进行整合（必要的时候异步优化），冗余的逻辑处理比较占用资源可以另起单独的服务器进行处理。

    分片过程中如果业务增长无法预估，最好还是用分布式数据库中间件mycat，它可以支持随时增加新的数据库应对增长的业务。具体的mycat怎么处理留给下一章