在现在读写分离已经是不奇怪了,>
其实读写分离最稳定的做法就是直接嵌入到程序中，通过业务程序来直接做判断哪些SQL需要访问哪个库。但是往往对于一个开放团队来说，在一个已有的项目中应入读写分离，其实工作量还是有的。特别是在一个公司如果没有一个很好的程序设计的人员，做读写分离将会是无趣找代码、cpoy代码并且让代码变的维护性变的更差。
插曲：如果有一个比较强的程序设计人员可以将重构读写分离的程序达到一两行代码搞定(这边使用程序编程的装饰器和工厂模式配合将会比较合适,当然肯定有更合适的方法)。
当然现在能做的读写分离的中间件很多，Maxscale就能够胜任这样的工作，Maxscale的Hint解析分发SQL能见读写分离做的更加灵活。最主要的是使用Maxscale的Hint最代码的改造将会减少很多。
注意：这边有的人会有疑问Maxscale天生不就是做读写分离么，为啥还要用到Hint，别急下面会说道’正确的使用读写分离'(可能你的业务默认使用Maxscale读写分离就能满足了)。
做读写分离其实在前期和开发沟通是主要一方面，要不断引导他们如何去做读写分离。毕竟一个公司里面不都是经验丰富的开发0-2年工作经验的偏多。
在一个新项目开始的时候基本上是以功能为核心，以功能多并且还比较好来抢占市场，来积累一定的用户，是不稳定的。因为他们在一点点的快速摸索迭代中，过早的引入读写分离，会在一定程度上拉长项目的进度(当然这个阶段如果有DBA最基本的规范优化还是要有的)。
如果有项目需要重构>
当然如果对项目的的未来有个比较好的预测，那从项目的开始就使用读写分离降低之后接入读写分离的成本这是一个正确的做法。比如现在阿里、移动、电信又要搞一个产品那我觉得可以把读写分离提前就搞上，毕竟他们有用户基础，只要产品出来稍微推广一下压力就上来了。
要正确的使用读写分离，那就必须和实际情况和业务相结合了。
这边先说使用普通读写分离的一个现象：直接通过中间件使用读写分离，让读都走>
所以一般在查询列表的时候可以读slave，但是在精确查找的时候应该是读master的。当然比较普遍的复杂查询也放在slave是比较明智的。
二话不说在之前环境的基础上来做接下来的实验。直接上配置文件：
主要配置
