MySQL性能管理及架构设计（一）

作者: Mracale | 来源:发表于2021-04-09 09:45 被阅读0次

一、什么影响了数据库查询速度

1.1 影响数据库查询速度的四个因素

2883854064-5aa255739353a_fix732.png

1.2 风险分析

QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

Tips：最好不要在主库上数据库备份，大型活动前取消这样的计划。

效率低下的sql：超高的QPS与TPS。
大量的并发：数据连接数被占满（max_connection默认100，一般把连接数设置得大一些）。
并发量:同一时刻数据库服务器处理的请求数量
超高的CPU使用率：CPU资源耗尽出现宕机。
磁盘IO：磁盘IO性能突然下降、大量消耗磁盘性能的计划任务。解决：更快磁盘设备、调整计划任务、做好磁盘维护。

1.3 网卡流量：如何避免无法连接数据库的情况

减少从服务器的数量（从服务器会从主服务器复制日志）
进行分级缓存（避免前端大量缓存失效）
避免使用select * 进行查询
分离业务网络和服务器网络

1.4 大表带来的问题（重要）

1.4.1 大表的特点

记录行数巨大，单表超千万
表数据文件巨大，超过10个G

1.4.2 大表的危害

慢查询：很难在短时间内过滤出需要的数据
查询字区分度低 -> 要在大数据量的表中筛选出来其中一部分数据会产生大量的磁盘io -> 降低磁盘效率
对DDL影响：

建立索引需要很长时间：

MySQL -v<5.5 建立索引会锁表
MySQL -v>=5.5 建立索引会造成主从延迟（mysql建立索引，先在组上执行，再在库上执行）
修改表结构需要长时间的锁表：会造成长时间的主从延迟('480秒延迟')

1.4.3 如何处理数据库上的大表

分库分表把一张大表分成多个小表

难点：

分表主键的选择
分表后跨分区数据的查询和统计

1.5 大事务带来的问题（重要）

1.5.1 什么是事务

653073296-5aa390f74db47_fix732.png

1.5.2事务的ACID属性

原子性（atomicity)：全部成功，全部回滚失败。银行存取款。
一致性（consistent)：银行转账的总金额不变。
隔离性（isolation)：
隔离性等级：

未提交读(READ UNCOMMITED) 脏读,两个事务之间互相可见；-- 存在脏读、不可重复读、幻读的问题
已提交读(READ COMMITED)符合隔离性的基本概念,一个事务进行时，其它已提交的事物对于该事务是可见的，即可以获取其它事务提交的数据（不可重复读）。-- 解决脏读的问题，存在不可重复读、幻读的问题。
可重复读(REPEATABLE READ) InnoDB的默认隔离等级。事务进行时，其它所有事务对其不可见，即多次执行读，得到的结果是一样的！ -- mysql 默认级别，解决脏读、不可重复读的问题，存在幻读的问题。使用 MVCC（多版本并发控制，提高并发，不加锁）机制实现可重复读。But，MySQL在可重复读级别已经解决幻读，插不进数据，有间隙锁。
可串行化（SERIALIZABLE）在读取的每一行数据上都加锁，会造成大量的锁超时和锁征用，严格数据一致性且没有并发是可使用。 -- 解决脏读、不可重复读、幻读，可保证事务安全，但完全串行执行，性能最低。

不可重复读：事务A首先读取了一条数据，然后执行逻辑的时候，事务B将这条数据改变了，然后事务A再次读取的时候，发现数据不匹配了，就是所谓的不可重复读了。

也就是说，当前事务先进行了一次数据读取，然后再次读取到的数据是别的事务修改成功的数据，导致两次读取到的数据不匹配，也就照应了不可重复读的语义。

幻读：事务A首先根据条件索引得到N条数据，然后事务B改变了这N条数据之外的M条或者增添了M条符合事务A搜索条件的数据，导致事务A再次搜索发现有N+M条数据了，就产生了幻读。

也就是说，当前事务读第一次取到的数据比后来读取到数据条目少。

不可重复读和幻读比较：

两者有些相似，但是前者针对的是update或delete，后者针对的insert。

查看系统的事务隔离级别：show variables like '%iso%';
开启一个新事务：begin;
提交一个事务：commit;
修改事物的隔离级别：set session tx_isolation='read-committed';

持久性(DURABILITY)：从数据库的角度的持久性，磁盘损坏就不行了

2728609336-5aa3a6c87bf08_fix732.png

redo log机制保证事务更新的一致性和持久性

1.5.3 大事务

运行时间长，操作数据比较多的事务；

风险：锁定数据太多，回滚时间长，执行时间长。

锁定太多数据，造成大量阻塞和锁超时；
回滚时所需时间比较长，且数据仍然会处于锁定；
如果执行时间长，将造成主从延迟，因为只有当主服务器全部执行完写入日志时，从服务器才会开始进行同步，造成延迟。

解决思路：

避免一次处理太多数据，可以分批次处理；
移出不必要的SELECT操作，保证事务中只有必要的写操作。

二、什么影响了MySQL性能（非常重要）

2.1 影响性能的几个方面

服务器硬件。
服务器系统（系统参数优化）。
存储引擎。
MyISAM：不支持事务，表级锁。
InnoDB: 支持事务，支持行级锁，事务ACID。
数据库参数配置。
数据库结构设计和SQL语句。（重点优化）

2.2 MySQL体系结构

分三层：客户端->服务层->存储引擎

550276287-5aa5dce29909b_fix732.png

MySQL是插件式的存储引擎，其中存储引擎分很多种。只要实现符合mysql存储引擎的接口，可以开发自己的存储引擎!
所有跨存储引擎的功能都是在服务层实现的。
MySQL的存储引擎是针对表的，不是针对库的。也就是说在一个数据库中可以使用不同的存储引擎。但是不建议这样做。

2.3 InnoDB存储引擎

MySQL5.5及之后版本默认的存储引擎：InnoDB。

2.3.1 InnoDB使用表空间进行数据存储。

show variables like 'innodb_file_per_table'

如果innodb_file_per_table 为 ON 将建立独立的表空间，文件为tablename.ibd；

如果innodb_file_per_table 为 OFF 将数据存储到系统的共享表空间，文件为ibdataX（X为从1开始的整数）；

.frm ：是服务器层面产生的文件，类似服务器层的数据字典，记录表结构。

2.3.2 (MySQL5.5默认)系统表空间与(MySQL5.6及以后默认)独立表空间

1.1 系统表空间无法简单的收缩文件大小，造成空间浪费，并会产生大量的磁盘碎片。

1.2 独立表空间可以通过optimeze table 收缩系统文件，不需要重启服务器也不会影响对表的正常访问。

2.1 如果对多个表进行刷新时，实际上是顺序进行的，会产生IO瓶颈。

2.2 独立表空间可以同时向多个文件刷新数据。

强烈建立对Innodb 使用独立表空间，优化什么的更方便，可控。

2.3.3 系统表空间的表转移到独立表空间中的方法

1、使用mysqldump 导出所有数据库数据（存储过程、触发器、计划任务一起都要导出 ）可以在从服务器上操作。

2、停止MYsql 服务器，修改参数（my.cnf加入innodb_file_per_table），并删除Inoodb相关文件（可以重建Data目录）。

3、重启MYSQL，并重建Innodb系统表空间。

4、 重新导入数据。

或者 Alter table 同样可以的转移，但是无法回收系统表空间中占用的空间。

2.4 InnoDB存储引擎的特性

2.4.1 特性一：事务性存储引擎及两个特殊日志类型：Redo Log 和 Undo Log

Innodb 是一种事务性存储引擎。
完全支持事务的ACID特性。
支持事务所需要的两个特殊日志类型：Redo Log 和Undo Log

Redo Log：实现事务的持久性(已提交的事务)。
Undo Log：未提交的事务，独立于表空间，需要随机访问，可以存储在高性能io设备上。

Undo日志记录某数据被修改前的值，可以用来在事务失败时进行rollback；Redo日志记录某数据块被修改后的值，可以用来恢复未写入data file的已成功事务更新的数据。

2.4.2 特性二：支持行级锁

InnoDB支持行级锁。
行级锁可以最大程度地支持并发。
行级锁是由存储引擎层实现的。

2.5 什么是锁

2.5.1 锁

111.png

2.5.2 锁类型

222.png

S锁（读锁）： select ... lock in share mode
X锁（写锁）：select ... for update (update、delete、)

2.5.3 锁的粒度

MySQL的事务支持不是绑定在MySQL服务器本身，而是与存储引擎相关

[图片上传失败...(image-a45820-1617932500551)] 

将**table_name**加表级锁命令：`lock table table_name write`; **`写锁会阻塞其它用户对该表的‘读写’操作，直到`**写锁被释放：`unlock tables`；

锁的开销越大，粒度越小，并发度越高。
表级锁通常是在服务器层实现的。
行级锁是存储引擎层实现的。innodb的锁机制，服务器层是不知道的

2.5.4 锁的分类

（1）悲观锁

总是假设最坏的情况，每次拿数据都认为别人会修改数据，所以要加锁，别人只能等待，直到我释放锁才能拿到锁；数据库的行锁、表锁、读锁、写锁都是这种方式，java中的synchronized和ReentrantLock也是悲观锁的思想。

（2）乐观锁

总是假设最好的情况，每次拿数据都认为别人不会修改数据，所以不会加锁，但是更新的时候，会判断在此期间有没有人修改过；一般基于版本号机制实现。

（3）使用场景

乐观锁适用于读多写少的情况，即冲突很少发生；如果是多写的情况，应用会不断重试，反而会降低系统性能，这种情况最好用悲观锁，因为等待到锁被释放后，可以立即获得锁进行操作。

拓展：
(1)图解悲观锁和乐观锁
 (2)什么是乐观锁与悲观锁？

2.5.4 阻塞和死锁

（1）阻塞是由于资源不足引起的排队等待现象。
（2）死锁是由于两个对象在拥有一份资源的情况下申请另一份资源，而另一份资源恰好又是这两对象正持有的，导致两对象无法完成操作，且所持资源无法释放。

2.6 如何选择正确的存储引擎

**参考条件：**

事务
备份(Innobd免费在线备份)
崩溃恢复
存储引擎的特有特性

总结:****Innodb大法好。
注意:尽量别使用混合存储引擎，比如回滚会出问题在线热备问题。

2.7 配置参数

2.7.1 内存配置相关参数

确定可以使用的内存上限。

内存的使用上限不能超过物理内存，否则容易造成内存溢出；（对于32位操作系统，MySQL只能试用3G以下的内存。）

确定MySQL的每个连接单独使用的内存。

sort_buffer_size #定义了每个线程排序缓存区的大小，MySQL在有查询、需要做排序操作时才会为每个缓冲区分配内存（直接分配该参数的全部内存）；
join_buffer_size #定义了每个线程所使用的连接缓冲区的大小，如果一个查询关联了多张表，MySQL会为每张表分配一个连接缓冲，导致一个查询产生了多个连接缓冲；
read_buffer_size #定义了当对一张MyISAM进行全表扫描时所分配读缓冲池大小，MySQL有查询需要时会为其分配内存，其必须是4k的倍数；
read_rnd_buffer_size #索引缓冲区大小，MySQL有查询需要时会为其分配内存，只会分配需要的大小。

**`注意：`**以上四个参数是为一个线程分配的，如果有100个连接，那么需要×100。

MySQL数据库实例：

①MySQL是单进程多线程（而oracle是多进程），也就是说MySQL实例在系统上表现就是一个服务进程，即进程；

②MySQL实例是线程和内存组成，实例才是真正用于操作数据库文件的；

一般情况下一个实例操作一个或多个数据库；集群情况下多个实例操作一个或多个数据库。

**如何为缓存池分配内存：**
`Innodb_buffer_pool_size`，定义了Innodb所使用缓存池的大小，对其性能十分重要，必须足够大，但是过大时，使得Innodb 关闭时候需要更多时间把脏页从缓冲池中刷新到磁盘中；

总内存-（每个线程所需要的内存*连接数）-系统保留内存

`key_buffer_size`，定义了MyISAM所使用的缓存池的大小，由于数据是依赖存储操作系统缓存的，所以要为操作系统预留更大的内存空间；

select sum(index_length) from information_schema.talbes where engine='myisam'

**注意：**即使开发使用的表全部是Innodb表，也要为MyISAM预留内存，因为MySQL系统使用的表仍然是MyISAM表。

`max_connections` 控制允许的最大连接数， 一般2000更大。
**不要使用外键约束保证数据的完整性。**

2.8 性能优化顺序

**从上到下：**

333.png

MySQL性能管理及架构设计（二）