本文已参与「新人创作礼」活动，一起开启掘金创作之路。

为什么要优化

系统的吞吐量瓶颈往往出现在数据库的访问速度上随着应用程序的运行，数据库的中的数据会越来越

多，处理时间会相应变慢数据是存放在磁盘上的，读写速度无法和内存相比优化原则：减少系统瓶颈，

减少资源占用，增加系统的反应速度。

数据库结构优化

一个好的数据库设计方案对于数据库的性能往往会起到事半功倍的效果。

需要考虑数据冗余、查询和更新的速度、字段的数据类型是否合理等多方面的内容。

将字段很多的表分解成多个表对于字段较多的表，如果有些字段的使用频率很低，可以将这些字段分离

出来形成新表。

因为当一个表的数据量很大时，会由于使用频率低的字段的存在而变慢。

增加中间表对于需要经常联合查询的表，可以建立中间表以提高查询效率。

通过建立中间表，将需要通过联合查询的数据插入到中间表中，然后将原来的联合查询改为对中间表的

查询。

增加冗余字段设计数据表时应尽量遵循范式理论的规约，尽可能的减少冗余字段，让数据库设计看起来

精致、优雅。但是，合理的加入冗余字段可以提高查询速度。

表的规范化程度越高，表和表之间的关系越多，需要连接查询的情况也就越多，性能也就越差。

注意：

冗余字段的值在一个表中修改了，就要想办法在其他表中更新，否则就会导致数据不一致的问题

读写分离是依赖于主从复制，而主从复制又是为读写分离服务的。因为主从复制要求slave不能写只能读

（如果对slave执行写操作，那么show slave status将会呈现Slave_SQL_Running=NO，此时你需要按

照前面提到的手动同步一下slave）。

方案一

使用mysql-proxy代理

优点：直接实现读写分离和负载均衡，不用修改代码，master和slave用一样的帐号，mysql官方不建议

实际生产中使用缺点：降低性能，不支持事务方案二

使用AbstractRoutingDataSource+aop+annotation在dao层决定数据源。如果采用了mybatis，可以

将读写分离放在ORM层，比如mybatis可以通过

mybatis plugin拦截sql语句，所有的insert/update/delete都访问master库，所有的select 都访问salve

库，这样对于dao层都是透明。 plugin实现时可以通过注解或者分析语句是读写方法来选定主从库。不

过这样依然有一个问题，也就是不支持事务，所以我们还需要重写一下

DataSourceTransactionManager，将read-only的事务扔进读库，其余的有读有写的扔进写库。

方案三使用AbstractRoutingDataSource+aop+annotation在service层决定数据源，可以支持事务. 缺点：类

内部方法通过this.xx()方式相互调用时，aop不会进行拦截，需进行特殊处理