一、数据库性能瓶颈-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 代理
标签：二十二,订阅,快照,性能,查询,发布,服务器,优化,数据库 From： https://www.cnblogs.com/duyao/p/18159951