一、数据库性能瓶颈-IO瓶颈
第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询会产生大量的IO，降低查询速度
第二种：网络IO瓶颈，请求的数据太多，网络带宽不够
二、数据库性能瓶颈-CPU瓶颈
第一种：SQl问题：如SQL中包含join,group by, order by，非索引字段条件查询等，增加CPU运算的操作->SQL优化，建立合适的索引，在业务Service层进行业务计算（不建议在数据库中对数据进行操作）。
第二种：单表数据量太大，查询时扫描的行太多，SQl效率低，增加CPU运算的操作。
选择性处理，没有一劳永逸的方案。需要结合业务的诉求来支持。某一个业务支持的查询快，侧重于去做查询额。某一块业务要求增删改要快，侧重于做增伤改的提高性能。
增删改查四项；
两大项： 读取【查询】和写入【增删改】。
三、数据库操作二八原则
数据库二八原则：80%的数据库操作是查询，20%的数据库操作是增删改；
结合业务，有限解决查询的问题，让跟多的服务器来承担查询功能。
读写分离：把数据库的写入【增删改】，读取【查询】分开处理。查询操作占大部分。独立出来让更多
的服务器参与查询。
1、主从库之间，参与做主从复制的数据表的结构必然一致
2、主从库，保存的数据量也算是一致
3、通过数据库的【日志】、【快照】来恢复
4、必然不是通过Sql语句~
5、数据同步—必然有延迟~~【有解决方案~】
四、读写分离的四种方式
1、快照发布：发布服务器按预定的时间间隔向订阅服务器发送已发布数据的快照。
2、事务发布【比较常见的，实时性会好些，也会延迟】：在订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。
3、对等发布：对等发布支持多主复制。发布服务器将事务流式传输到拓扑中的所有对等方。所有对等节点可以读取和写入更改，且所有更改将传播到拓扑中的所有节点。
4、合并发布：在订阅服务器收到已发布数据的初始快照后，发布服务器和订阅服务器可以独立更新已发布数据。更改会定期合并。Microsoft SQL Server Compact Edition 只能订阅合并发布
五、配置实操和注意事项
1、参与发布订阅的数据库表必须包含主键
2、只能在局域网内做发布订阅
3、如果使用SqlServer代理，则必须设置代理为自动启动
4、发布快照的文件夹必须要共享、权限放开
快照发布配置
事务发布配置
对等发布配置
要求：
1、数据表必须有主键--有住建才能参与数据同步
2、需要开启Sql Server Browser 和 Sql Server 代理
