mysql常见知识点总结-参考:架构师之路

2022-07-26 17:20:12

参考：

微信公众号:架构师之路

数据库究竟该怎么垂直拆？

什么是数据库水平切分，垂直拆分？当数据库的数据量非常大时，水平切分和垂直拆分都是常见的降低库空间，提升库性能的方法。
太抽象，能不能举个例子？假设有用户表：

user(

uid bigint,

name varchar(16),

pass varchar(16),

age int,

sex tinyint,

flag tinyint,

sign varchar(64),

intro varchar(256)

…);

什么是水平切分？以某个字段为依据（例如uid），按照一定规则（例如取模），将一个库（表）上的数据拆分到多个库（表）中，以降低单库（表）大小，达到提升性能的目的的方法。
水平切分后，各个库（表）有什么特点？（1）每个库（表）的结构都一样；（2）每个库（表）的数据都不一样，没有交集；（3）所有库（表）的并集是全量数据； 什么是垂直拆分？垂直拆分是指，将一个属性较多，一行数据较大的表，将不同的属性拆分到不同的库（表）中，以降低单库（表）大小，达到提升性能的目的的方法。
垂直拆分后，各个库（表）有什么特点？（1）每个库（表）的结构都不一样；（2）每个库（表）的属性至少有一列交集，一般是主键；（3）所有库（表）的并集是全量数据；
以上文提到的用户表为例，垂直拆分结果可能是这样的：

user_base(

uid bigint,

name varchar(16),

pass varchar(16),

age int,

sex tinyint,

flag tinyint,

…);

user_ext(

uid bigint,

sign varchar(64),

intro varchar(256)

…);

当一个表属性很多时，如何来进行垂直拆分呢？主要依据以下几点：（1）将长度较短，访问频率较高的属性尽量放在一个表里，这个表暂且称为主表；（2）将字段较长，访问频率较低的属性尽量放在一个表里，这个表暂且称为扩展表；（3）经常一起访问的属性，也可以放在一个表里；
画外音：优先考虑1和2。
另，如果属性过多，可以有多个扩展表。画外音：一般来说，只有1个主表。 为何要将字段短，访问频率高的属性放到一个表内？为何这么垂直拆分可以提升性能？（1）数据库有自己的内存缓冲池，会将磁盘上的数据load到缓冲池里；画外音：详见《数据库缓冲池，这次彻底懂了！》。（2）数据库缓冲池，以row为单位缓存数据；（3）在内存有限的情况下，在数据库缓冲池里缓存短row，就能缓存更多的数据；（4）在数据库缓冲池里缓存高频访问row，就能提升缓存命中率，减少磁盘的访问； 能不能举个例子？假设数据库内存缓冲池为1G，未拆分的user表1行数据大小为1k，那么只能缓存100w行数据。
如果垂直拆分成user_base和user_ext，其中：（1）user_base访问频率高，一行大小为0.1k；画外音：例如uid, name, passwd, 以及一些flag等。（2）user_ext访问频率低，一行大小为0.9k；画外音：例如签名, 个人介绍等。那边缓冲池就就能缓存近乎1000w行user_base的记录，访问磁盘的概率会大大降低，数据库访问的时延会大大降低，吞吐量会大大增加。总结（1）水平拆分和垂直拆分都是降低数据量大小，提升数据库性能的常见手段；（2）垂直拆分的依据，尽量把长度较短，访问频率较高的属性放在主表里；

动静分离架构，究竟是啥？

什么是动静分离架构设计准则？动静分离是指，静态页面与动态页面解耦分离，用不同系统承载对应流量的架构设计方法。
什么是静态页面？静态页面，是指互联网架构中，几乎不变的页面（或者变化频率很低），例如：

首页等html页面
js/css等样式文件
jpg/apk等资源文件

静态页面，有与之匹配的技术架构来加速，例如：

CDN
nginx
squid/varnish

什么是动态页面？动态页面，是指互联网架构中，不同用户不同场景访问，都不一样的页面，例如：

百度搜索结果页
淘宝商品列表页
速运个人订单中心页

这些页面，不同用户，不同场景访问，大都会动态生成不同的页面。动态页面，有与之匹配的技术架构，例如：

分层架构
服务化架构
数据库，缓存架构

架构上，如何实施动静分离架构？静态页面与动态页面解耦分离，用不同系统承载对应流量的架构，如下图所示。

静态页面访问路径短，访问速度快，几毫秒
动态页面访问路径长，访问速度相对较慢(数据库的访问，网络传输，业务逻辑计算)，几十毫秒甚至几百毫秒，对架构扩展性的要求更高
静态页面与动态页面以不同域名区分

既然静态页面访问快，动态页面生成慢，有没有可能，将原本需要动态生成的站点提前生成好，使用静态页面加速技术来访问呢？可以，这就是互联网架构中的“页面静态化”优化技术。
什么是页面静态化技术？举个栗子，如下图，58同城的帖子详情页，原本是需要动态生成的：

（1）端访问/detail/12348888x.shtml 详情页；（2）web-server层从RESTful接口中，解析出帖子id是12348888；（3）service通过DAO层拼装SQL，访问数据库；（4）最终获取数据，拼装html返回浏览器；
而“页面静态化”是指，将帖子ID为12348888的帖子12348888x.shtml提前生成好，由静态页面相关加速技术来加速：这样的话，将极大提升访问速度，减少访问时间，提高用户体验。 页面静态化，适合什么业务场景？一切脱离业务的架构设计都是耍流氓，并不是所有的业务场景都适合页面静态化，滥用该技术，反而会降低系统性能。
页面静态化，适用于：总数据量不大，生成静态页面数量不多的业务。
举一些栗子：（1）快狗打车的城市页只有几百个，就可以用这个优化，只需提前生成几百个城市的“静态化页面”即可；（2）一些二手车业务，只有几万量二手车库存，也可以提前生成这几万量二手车的静态页面；（3）像58同城这样的信息模式业务，有几十亿的帖子量，就不太适合于静态化（碎片文件多，反而访问慢）； 简单总结（1）动静分离是指，静态页面与动态页面解耦分离，用不同系统承载流量的架构设计方法；（2）“页面静态化”是一种将原本需要动态生成的站点提前生成静态站点的优化技术；（3）总数据量不大，生成静态页面数量不多的业务，非常适合于“页面静态化”优化；

啥是数据库读写分离架构？

RD：数据量太大，数据库扛不住了，帮忙申请一个从库，读写分离。DBA：数据量多少？RD：5000w左右。DBA：读写吞吐量呢？RD：读QPS约200，写QPS约30左右。
额，数据库读写分离虽然不难，但并不是所有的“数据库扛不住”的场景，都应该用读写分离。今天花1分钟简单介绍下这个场景。
什么是数据库读写分离？一主多从，读写分离，主动同步，是一种常见的数据库架构，一般来说：