17.sqlserver数据库使用规则、二八原则、数据库查询集群数据库读写分离多种实现、数据库配置读写分离（by朝夕）

1 数据库使用规则
2 二八原则
3 数据库查询集群–数据库读写分离多种实现
4.数据库配置读写分离

Microsoft SQL Server Management Studio 18 2012以上&＃xff1b;

1. 通常&＃xff0c;我们的&＃xff08;添加、修改、删除&＃xff09;操作&＃xff0c;在数据库中&＃xff0c;只占有百分之二十的一部分。而剩下百分之80的操作&＃xff0c;都是进行查询。
2. 我们根据这个原则&＃xff0c;可以对我们数据库进行读写分离。

好处&＃xff1a;

1. 数据是网站的生命&＃xff0c;读写分离通过主从备份数据&＃xff0c;保证了系统的冗余&＃xff0c;保护了珍贵的数据。 通过将
   “读”操作和“写”操作分离到不同的数据库服务器上&＃xff0c;降低对主服务器的CPU、内存、存储、网络资源的争
   用&＃xff1b;
2. 主服务器的增删改进行时&＃xff0c;不影响查询服务器的查询&＃xff0c;降低阻塞的发生&＃xff0c;提高了并发性&＃xff1b;
3. 在应用程序提交了报表请求、不合理的查询请求时&＃xff0c;不会导致长时间的锁表&＃xff1b;
4. 建立容灾副本甚至实现异地容灾&＃xff0c;在发生灾难时&＃xff0c;可以减少数据的损失&＃xff1b;

绝大部分的企业内部应用&＃xff0c;可能不需要上图那么庞大的架构&＃xff0c;一台主数据库服务器和一台查询服务器通常能满足读写分离的要求。而且应用程序调整起来非常方便&＃xff1a;

1. 在应用程序的配置文件中设置两个数据库连接字符串&＃xff0c;一个指向主服务器&＃xff0c;一个指向查询服务器&＃xff1b;
2. 增删改或者实时性查询使用指向主服务器的连接字符串&＃xff1b;
3. 允许非实时的查询及报表请求使用指向查询服务器的连接字符串。

适用场景&＃xff1a;

1. 网站初期想要缓解数据负载最简单可行的方案。
2. 服务器面对的是读远大于写的场景&＃xff0c;并且业务能够允许时间上一些延迟。
   主从复制&＃xff0c;是用来建立一个和主数据库完全一样的数据库环境&＃xff0c;称为从数据库&＃xff1b;
   二是可在从数据库作备份、数据统计等工作&＃xff0c;这样不影响主数据库的性能&＃xff1b;
   当一个从服务器连接主服务器时&＃xff0c;它通知主服务器从日志中读取最后一次成功更新的位置。
   从服务器接收从那时起发生的任何更新&＃xff0c;并在本机上执行相同的更新。然后封锁并等待主服务器通知新
   的更新。
   从服务器执行备份不会干扰主服务器&＃xff0c;在备份过程中主服务器可以继续处理更新

快照发布&＃xff1a;

介绍&＃xff1a;数据库快照就想象成相机就可以了&＃xff0c;就是将数据库拍下来&＃xff0c;拍摄个一模一样的。做一次备份
优势&＃xff1a;类似一个人成长&＃xff0c;有很多张照片&＃xff0c;例如你每年拍一张&＃xff0c;那么以后查看起来是非常方便的。
劣势&＃xff1a;这个无法做到实时备份&＃xff0c;只能是某一刻的一个备份&＃xff0c;很多需求会不满足&＃xff0c;而且如果数据量非常
大&＃xff0c;那么对性能也有一定的的消耗

事务发布&＃xff1a;

介绍&＃xff1a;也是两个库&＃xff0c;一个主库一个从库&＃xff0c;主从库之间是一种发布订阅的关系&＃xff0c;就是我修改了通知你&＃xff0c;
或者你时时来读取我&＃xff0c;看看我是否修改了&＃xff0c;就这么简单
优势&＃xff1a;他是读取的日志文件&＃xff0c;根据日志文件达到同步的&＃xff0c;所以基本可以满足同步&＃xff0c;并且我粗略的测试
了一下&＃xff0c;除非服务器堵塞&＃xff0c;否则性能还是很高的&＃xff0c;百万数据同步几秒钟就可以完成&＃xff0c;足见其效率了。
劣势&＃xff1a;发布者和订阅者之间并非实时同步的&＃xff0c;所以经常会有延时&＃xff0c;这个就属于不定性因素的&＃xff0c;而且消
耗>数据库镜像 .
详细操作地址
https://blog.csdn.net/hello_mr_anan/article/details/118093045

对等发布&＃xff1a;

介绍&＃xff1a;

合并发布&＃xff1a;

介绍&＃xff1a;合并发布是相当于两台都是主服务器&＃xff0c;都可以对数据进行更新修改等操作&＃xff0c;然后定时将发布服
务器上的内容与订阅服务器上的内容进行合并&＃xff0c;并根据配置保留相应内容&＃xff0c;此种很少用。
图片总结&＃xff1a;

读写分离以后&＃xff0c;其实是把查询动作分摊到不同的数据库中去了&＃xff1b;提高性能

本质是通过增加硬件&＃43;数据的读写法分离机制&＃xff1b;如何通过纯技术手段来解决数据库性能瓶颈呢&＃xff1f;

场景&＃xff1a;应用于海量数据&＃xff1b;数据一旦太多&＃xff0c;基本上性能优化的套路都失效&＃xff1b;
把数据分摊&＃xff1a;把数据库切分&＃xff1a;

1. 垂直拆分&＃xff1a;按照需求拆分&＃xff1a;电商系统----一个数据&＃61;&＃61;&＃61;&＃61;多个数据库&＃xff0c;每个数据库负责一个模块&＃xff1b;拆分以后&＃xff0c;每个数据库的数量减少了&＃xff0c;数据操作来说提高性能&＃xff1b;
   特点&＃xff1a;每个数据库的表结构都不同&＃xff1b;
   局限&＃xff1a;拆分后关联查询复杂----建议如果遇到关联查询比较多&＃xff0c;就不要拆开—根据具体场景来做&＃xff1b;
2. 水平拆分
   特点&＃xff1a;每个数据库的结构都一致&＃xff0c;数据不一致&＃xff1b;&＃xff08;区域/时间/类别/随机&＃xff08;定义一套规则----存入数据的时
   候确定是哪个数据库&＃xff0c;查询数据的时候&＃xff0c;还是通过这个规则确定是哪个数据&＃xff09;&＃xff09;
   劣势&＃xff1a;数据操作的时候&＃xff0c;不方便&＃xff0c;需要程序来支持&＃xff1b;

1. 垂直分&＃xff1a;
   表和表示一对一的关系&＃xff1b;
   一个表存在字段&＃xff0c;用多个表成列&＃xff08;建议大家把常用的字段分在一个表&＃xff09;&＃xff1b;
   文章表&＃xff1a;20字段&＃43;很长的文章内容字段&＃61;&＃61;垂直拆分&＃xff0c;20个字段一个表&＃xff0c;文章内容&＃43;外键一个表
2. 水平分&＃xff1a;
   表结构一致&＃xff0c;数据不一致&＃xff1b;
   拆分建议&＃xff1a;时间/类别/区域

1. 程序需要支持&＃xff1b;
   建议&＃xff1a;大家一定要按照场景需求来&＃xff0c;
   房产----城市拆分
   电商&＃xff1a;时间来拆分
   追求平均&＃xff1a;保存数据的时候&＃xff0c;如果有ID &＃xff0c;如果来十个表存储&＃xff1b;通过Id/10 取余数确定到哪个表&＃xff0c;定
   义规则&＃xff0c;保存需要按照规则保存&＃xff0c;查询自然要要按照规则查询&＃xff1b;
2. 更多的也是建议&＃xff0c;如果大家有自己的想法&＃xff0c;有更好的方案&＃xff0c;也欢迎大家提出来
3. 如果频繁使用&＃xff0c;频繁关联的内容&＃xff0c;尽量聚在一起个表&＃xff08;一个数据库&＃xff09;