优化解决 MySQL 查询速度慢与性能差

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

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

1.2 风险分析

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

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 什么是事务

事务是数据库系统区别于其余一切文件系统的重要特性之一

事务是一组具备原子性的SQL语句，或是一个独立的工做单元

事务要求符合：原子性、一致性、隔离性、持久性

1.5.2事务的 ACID属性

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

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

三、隔离性（isolation)：

隔离性等级：

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

查看系统的事务隔离级别： 

show variables like'%iso%';

开启一个新事务： 

begin;

提交一个事务： 

commit;

修改事物的隔离级别： 

setsession tx_isolation='read-committed';

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

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

1.5.3 大事务

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

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

一、锁定太多数据，形成大量阻塞和锁超时；

二、回滚时所需时间比较长，且数据仍然会处于锁定；

三、若是执行时间长，将形成主从延迟，由于只有当主服务器所有执行完写入日志时，从服务器才会开始进行同步，形成延迟。

解决思路：

一、避免一次处理太多数据，能够分批次处理；

二、移出没必要要的 SELECT操做，保证事务中只有必要的写操做。

什么影响了MySQL性能（很是重要）

2.1 影响性能的几个方面

一、服务器硬件。

二、服务器系统（系统参数优化）。

三、存储引擎。MyISAM：不支持事务，表级锁。InnoDB: 支持事务，支持行级锁，事务 ACID

四、数据库参数配置。

五、 数据库结构设计和SQL语句。（重点优化）

2.2 MySQL体系结构

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

一、 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及之后默认)独立表空间

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

二、独立表空间能够经过 optimeze table 收缩系统文件，不须要重启服务器也不会影响对表的正常访问。

三、若是对多个表进行刷新时，其实是顺序进行的，会产生IO瓶颈。

四、独立表空间能够同时向多个文件刷新数据。

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

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

一、使用mysqldump 导出全部数据库数据（存储过程、触发器、计划任务一块儿都要导出 ）能够在从服务器上操做。

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

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

四、 从新导入数据。

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

2.4 InnoDB存储引擎的特性

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

一、 Innodb 是一种事务性存储引擎。

二、彻底支持事务的 ACID特性。

三、支持事务所须要的两个特殊日志类型：RedoLog 和 UndoLog

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

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

2.4.2 特性二：支持行级锁

一、InnoDB支持行级锁。

二、行级锁能够最大程度地支持并发。

三、行级锁是由存储引擎层实现的。

2.5 什么是锁

2.5.1 锁

锁的主要做用是管理共享资源的并发访问

锁用于实现事务的隔离性

2.5.2 锁类型

2.5.3 锁的粒度

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

• 表级锁
• 行级锁

将table_name加表级锁命令：

locktable table_name write; 写锁会阻塞其它用户对该表的‘读写’操做，直到写锁被释放：unlock tables；

一、锁的开销越大，粒度越小，并发度越高。

二、表级锁一般是在服务器层实现的。

三、行级锁是存储引擎层实现的。innodb的锁机制，服务器层是不知道的

2.5.4 阻塞和死锁

一、阻塞是因为资源不足引发的排队等待现象。

二、死锁是因为两个对象在拥有一份资源的状况下申请另外一份资源，而另外一份资源刚好又是这两对象正持有的，致使两对象没法完成操做，且所持资源没法释放。

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

参考条件：

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

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

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所使用的缓存池的大小，因为数据是依赖存储操做系统缓存的，因此要为操做系统预留更大的内存空间；

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

注意：即便开发使用的表所有是Innodb表，也要为MyISAM预留内存，由于MySQL系统使用的表仍然是MyISAM表。

max_connections

控制容许的最大链接数， 通常2000更大。不要使用外键约束保证数据的完整性

2.8 性能优化顺序

• 库结构设计和SQL语句
• 数据库存储引擎的选择和参数配置
• 系统选择及优化
• 硬件升级