高性能MySQL(一) 如何做到高扩展性

吞吐量: 单位时间内处理的请求数

TPS: 每秒处理的事务数

QPS: 每秒处理的查询次数

三个方法论

1.Shared Everthing

针对单个系统，完全共享CPU,Memory，磁盘系统，这样并行处理能力最差，比如SQLServer

2.Shared Nothing

不存在共享资源，并行和扩展能力更好，比如hadoop

3.Shared Disk

各个处理单元，使用私有的CPU，Memory，但是使用共公有的disk

纵向扩展:

扩展一个点的能力支撑更多的请求，类似于螳臂当车:

两种方式:

1. 提升硬件性能 

比如CPU,内存大小，更好性能的网卡

2. 提升单机架构性能

读多写少，用cache；读少写多，使用消息队列，异步更新，比如kafka，RMQ

使用无锁算法，比如CAS

分区就是PARTITION, RANGE分区，就是比如把表的数据按时间分成，70年代，80年代，90年代的数据，HASH分区，就是把表的数据根据HASH值的不同分成不同的区

横向扩展

用更多的节点支撑更大的请求，类似于蚂蚁搬家，主要有4种方式:

1.主从复制

主库用来读写，从库用来读，提升读性能

2.分库分表 (数据分片 sharding)

分库、分表、达到线性扩展的目的

关于分库分表，可参考博客 什么时候进行MySQL分库和分表？ - 扁豆一号 - 博客园

分库和分表，是两个概念

分库

一开始是一个服务，一个数据库

然而这样会造成系统臃肿，很难维护，因此需要把服务拆分为多个服务，并且服务共用同一个数据库的

 但是这样的问题是，随着业务越来越大，I/O连接数过高会导致数据库访问的压力越来越大，因此需要分库，这样系统能承载更多的数据库连接，相对的并发量也就越高

分表

分表是，数据量变大时，查询会变慢，因此分表能提升查询效率，一般数据量超过500万，就要考虑分表，不过500万只是经验之谈

总的来说： 分库增加QPS并发量，分表提升查询性能

我的项目记得是，按时间来分库到sms_record_0 和 sms_record_1中，然后分表是用sharding来做的，就是插入数据用sharding来写，查询时也是根据sharding来查某个表，sharding到哪个表具体是根据手机号来决定的应该

商家和用户怎么分表的问题

算是比较经典的一个问题，具体解决方案是，根据商家id来分一次表，根据用户id再分一次表，相当于我们有一份冗余表，然后不同类型的查询走不同的表，通过分布式事务或是其他方式保证两个表的数据一致性

分页查询limit OFFSET = 1000000,  N = 10 时为什么会慢？

这是因为查询时 MySQL 并不是跳过 OFFSET 行，而是取 OFFSET+N 行，然后放弃前 OFFSET 行，最后返回 N 行，当 OFFSET 特别大的时候，效率就非常的低下。

in在哪种情况下走索引

参考 ​​​​​​https://segmentfault.com/a/1190000023825926

一句话，in里面的值太多，就不会走索引

3.数据库中间件

比如rmq，kafka，来达到读写分离的目的

4.集群

使用集群来弥补单机性能的不足(这里忽然想到分布式和集群的区别，分布式就是不同机器上面部署着不同的服务，而集群就是不同机器上面部署着相同的服务)

主从复制

是最常用的技术，可以扩展出很多的从库，从而减轻主库负担，能够实现读写分离

缺点：如果写过多，主库成为性能瓶颈，从库数据容易不一致

为了解决这个缺点，就得想办法做sharding

数据分片

1.垂直分片

其实就是按column列分片，某几列属于同一片，另外几列属于另一片，比如把一个表的12列(12个字段)分成3个小片，每片4列

 

2. 水平分片

就是不修改表结构，比如按时间来进行拆分，比如2021年1月1日之前的数据存在A库，之后的存在B库

虽然sharding很好用，但是这样会加大业务代码的复杂性，而且单个shard失效可能会导致整个系统不可用(这种情况，就得考虑主从复制，对每个shard都备份一个或者多个从库)

分区是库内的，分片是库外的 

数据库中间件

需要多注意，主从复制的各种小分类

不同主从复制的开启方法

 

 集群架构， 这个我真看不懂。。。。