你好，你有一份MySQL性能管理及架构设计指南待领取

时间 2019-11-30

标签你好一份 mysql 性能管理架构设计指南待领栏目 MySQL 繁體版

原文原文链接

1、什么影响了数据库查询速度前端

一、影响数据库查询速度的四个因素mysql

二、风险分析程序员

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

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

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

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

三、网卡流量：如何避免没法链接数据库的状况安全

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

四、大表带来的问题性能优化

1）大表的特色服务器

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

2）大表的危害网络

①慢查询：很难在短期内过滤出须要的数据

查询字区分度低 -> 要在大数据量的表中筛选出来其中一部分数据会产生大量的磁盘io -> 下降磁盘效率

②对DDL影响：

创建索引须要很长时间：

MySQL -v<5.5 创建索引会锁表
MySQL -v>=5.5 创建索引会形成主从延迟（mysql创建索引，先在组上执行，再在库上执行）

修改表结构须要长时间的锁表：会形成长时间的主从延迟('480秒延迟')

3）如何处理数据库上的大表

分库分表把一张大表分红多个小表。

难点：

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

五、大事务带来的问题

1）什么是事务

2）事务的ACID属性

①原子性（atomicity)：所有成功，所有回滚失败。银行存取款。

②一致性（consistent)：银行转帐的总金额不变。

③隔离性（isolation)：

隔离性等级：

未提交读(READ UNCOMMITED) 脏读，两个事务之间互相可见；
已提交读(READ COMMITED)符合隔离性的基本概念，一个事务进行时，其它已提交的事物对于该事务是可见的，便可以获取其它事务提交的数据。
可重复读(REPEATABLE READ) InnoDB的默认隔离等级。事务进行时，其它全部事务对其不可见，即屡次执行读，获得的结果是同样的！
可串行化（SERIALIZABLE）在读取的每一行数据上都加锁，会形成大量的锁超时和锁征用，严格数据一致性且没有并发是可以使用。

查看系统的事务隔离级别：show variables like '%iso%';

开启一个新事务：begin;

提交一个事务：commit;

修改事物的隔离级别：set session tx_isolation='read-committed';

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

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

3）大事务

运行时间长，操做数据比较多的事务。

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

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

解决思路：

避免一次处理太多数据，能够分批次处理；
移出没必要要的SELECT操做，保证事务中只有必要的写操做。

2、什么影响了MySQL性能

一、影响性能的几个方面

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

二、MySQL体系结构

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

MySQL是插件式的存储引擎，其中存储引擎分不少种。只要实现符合mysql存储引擎的接口，能够开发本身的存储引擎。
全部跨存储引擎的功能都是在服务层实现的。
MySQL的存储引擎是针对表的，不是针对库的。也就是说在一个数据库中可使用不一样的存储引擎。可是不建议这样作。

三、InnoDB存储引擎

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

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）(MySQL5.5默认)系统表空间与(MySQL5.6及之后默认)独立表空间

系统表空间没法简单的收缩文件大小，形成空间浪费，并会产生大量的磁盘碎片。
独立表空间能够经过optimeze table 收缩系统文件，不须要重启服务器也不会影响对表的正常访问。
若是对多个表进行刷新时，其实是顺序进行的，会产生IO瓶颈。
独立表空间能够同时向多个文件刷新数据。

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

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

使用mysqldump 导出全部数据库数据（存储过程、触发器、计划任务一块儿都要导出）能够在从服务器上操做。
中止MYsql服务器，修改参数（my.cnf加入innodb_file_per_table），并删除Inoodb相关文件（能够重建Data目录）。
重启MYSQL，并重建Innodb系统表空间。
从新导入数据。

或者Alter table一样能够的转移，可是没法回收系统表空间中占用的空间。

四、InnoDB存储引擎的特性

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

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

Redo Log：实现事务的持久性(已提交的事务)。

Undo Log：未提交的事务，独立于表空间，须要随机访问，能够存储在高性能io设备上。

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

2）特性二：支持行级锁

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

五、什么是锁

1）锁

2）锁类型

3）锁的粒度

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

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

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

4）阻塞和死锁

阻塞是因为资源不足引发的排队等待现象。
死锁是因为两个对象在拥有一份资源的状况下申请另外一份资源，而另外一份资源刚好又是这两对象正持有的，致使两对象没法完成操做，且所持资源没法释放。

六、如何选择正确的存储引擎

参考条件：

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

总结：Innodb大法好。

注意：尽可能别使用混合存储引擎，好比回滚会出问题在线热备问题。

七、配置参数

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实例是线程和内存组成，实例才是真正用于操做数据库文件的；
通常状况下一个实例操做一个或多个数据库；集群状况下多个实例操做一个或多个数据库。

2）如何为缓存池分配内存

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更大。不要使用外键约束保证数据的完整性。

八、性能优化顺序

从上到下：

3、数据库结构优化

一、数据库结构优化目的

减小数据冗余：（数据冗余是指在数据库中存在相同的数据，或者某些数据能够由其余数据计算获得），注意，尽可能减小不表明彻底避免数据冗余；
尽可能避免数据维护中出现更新，插入和删除异常：

总结：要避免异常，须要对数据库结构进行范式化设计。
节约数据存储空间。
提升查询效率。

二、数据库结构设计步骤

需求分析：全面了解产品设计的存储需求、数据处理需求、数据安全性与完整性；
逻辑设计（重要）：设计数据的逻辑存储结构。数据实体之间的逻辑关系，解决数据冗余和数据维护异常。数据范式能够帮助咱们设计；
物理设计：表结构设计，存储引擎与列的数据类型；
维护优化：索引优化、存储结构优化。

三、数据库范式设计与反范式化

可参考“数据库逻辑设计之三大范式通俗理解，一看就懂，书上说的太晦涩”

四、物理设计

可参考“MySQL中字段类型与合理的选择字段类型；int(11)最大长度是多少？，varchar最大长度是多少”

4、高可用架构设计

一、读写分离

5、数据库索引优化

一、两种主要数据结构：B-tree和Hash

1）B-tree结构

B-tree索引的限制：

2）Hash结构

Hash索引的限制：

Hash索引必须进行二次查找
Hash索引没法用于排序
Hash索引不支持部分索引查找也不支持范围查找
Hash索引中Hash码的计算可能存在Hash冲突，不适合重复值很高的列，如性别，身份证比较合适。

3）MySQL常见索引和各类索引区别

PRIMARY KEY（主键索引） ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )

UNIQUE(惟一索引) ALTER TABLE `table_name` ADD UNIQUE (`column`)

INDEX(普通索引) ALTER TABLE `table_name` ADD INDEX index_name ( `column` )

FULLTEXT(全文索引) ALTER TABLE `table_name` ADD FULLTEXT ( `column` )

组合索引 ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )

普通索引：最基本的索引，没有任何限制
惟一索引：与"普通索引"相似，不一样的就是：索引列的值必须惟一，但容许有空值。
主键索引：它是一种特殊的惟一索引，不容许有空值。
全文索引：仅可用于 MyISAM 表，针对较大的数据，生成全文索引很耗时好空间。
组合索引：为了更多的提升mysql效率可创建组合索引，遵循“最左前缀”原则。

二、使用索引好处和索引缺陷

1）为何要使用索引

索引大大减小了存储引擎须要扫描的数据量；
索引能够帮助咱们进行排序以免使用临时表；
索引能够把随机I/O变为顺序I/O。

2）索引不是越多越好

索引会增长写操做的成本；
太多的索引会增长查询优化器的选择时间。

索引就比如一本书的目录，它会让你更快的找到内容，显然目录（索引）并非越多越好，假如这本书1000页，而有500页是目录，它固然效率低，目录是要占纸张的,而索引是要占磁盘空间的。

三、索引优化策略

1）索引列上不能使用表达式和函数

2）前缀索引和索引列的选择性

Innodb索引列最大宽度为667个字节(utf-8 差很少255个字符)，MyIsam索引类宽度最大为1000个字节，因而出现前缀索引，索引的选择性。

对于列的值较长，好比BLOB、TEXT、VARCHAR，就必须创建前缀索引，即将值的前一部分做为索引。这样既能够节约空间，又能够提升查询效率。但没法使用前缀索引作 ORDER BY 和 GROUP BY，也没法使用前缀索引作覆盖扫描。

语法： ALTER TABLE table_name ADD KEY(column_name(prefix_length))

如何选择索引列的顺序：

常常会被使用到的列优先（选择性差的列不适合，如性别，查询优化器可能会认为全表扫描性能更好）；
选择性高的列优先；
宽度小的列优先（一页中存储的索引越多，下降I/O，查找越快）；

3）组合/联合索引策略

若是索引了多列，要遵照最左前缀法则。指的是查询从索引的最左前列开始而且不跳过索引中的列。

4）覆盖索引策略

跟组合索引有点相似，若是索引包含全部知足查询须要的数据的索引则成为覆盖索引(Covering Index)，也就是平时所说的不须要回表操做。即索引的叶子节点上面包含了他们索引的数据(hash索引不能够)。

判断标准：使用explain，能够经过输出的extra列来判断，对于一个索引覆盖查询，显示为using index,MySQL查询优化器在执行查询前会决定是否有索引覆盖查询。

优势：

能够优化缓存,减小磁盘IO操做；
能够减小随机IO,变随机IO操做变为顺序IO操做；
能够避免对InnoDB主键索引的二次查询；
能够避免MyISAM表进行系统调用；

没法使用覆盖索引的状况：

存储引擎不支持覆盖索引；
查询中使用了太多的列（如SELECT * ）；
使用了双%号的like查询（底层API所限制）；

5）SQL索引优化总结口诀（套路重点）

全值匹配我最爱，最左前缀要遵照；

带头大哥不能死，中间兄弟不能断；

索引列上不计算，范围以后全失效；

LIKE百分写最右，覆盖索引不写 *；

不等空值还有or，索引失效要少用；

字符单引不可丢，SQL高级也不难；

四、使用索引来优化查询

1）利用索引排序

group by 实质是先排序后分组，遵守索引的最佳左前缀；
索引中全部列的方向(升序、降序)和Order By子句彻底一致；
当没法使用索引列，增大max_length_for_sort_data参数的设置+增大sort_buffer_size参数的设置；
若是最左列使用了范围，则排序会失效；
where 高于having，能写在where限定的条件就不要去having去限定了

五、索引的维护和优化

1）删除重复索引

注：主键约束至关于(惟一约束 + 非空约束)

一张表中最多有一个主键约束,若是设置多个主键,就会出现以下提示：Multiple primary key defined!!!

2）删除冗余索引

检查工具：pt-duplicate-key-checker

Using where：表示优化器须要经过索引回表查询数据；
Using index：表示直接访问索引就足够获取到所须要的数据，不须要经过索引回表，如覆盖索引；

6、SQL查询优化

一、获取有性能问题SQL的三种方式

经过用户反馈获取存在性能问题的SQL；
经过慢查日志获取存在性能问题的SQL；
实时获取存在性能问题的SQL；

1）慢查日志分析工具