Day26-MySQL中

title: Day26-MySQL中
date: 2020-08-13 10:25:50
author: 子陌

MySQL - 中

MySQL的体系结构

整个MySQL Server由以下组成

Connection Pool：连接池组件
Management Services & Utilities：管理服务和工具组件
SQL Interface：SQL接口组件
Parser：查询分析器组件
Optimizer：优化器组件
Caches & Buffers：缓冲池组件
Pluggable Storage Engines：存储引擎
File System：文件系统

连接层

最上层是一些客户端和链接服务，包含本地sock通信和大多数基于客户端/服务端工具实现的类似于TCP/IP的通信。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念，为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于SSL的安全链接。服务器也会为安全接入的每个客户端验证它所具有的操作权限。
服务层

第二层架构主要完成大多数的核心服务功能，如SQL接口，并完成缓存的查询，SQL的分析和优化，部分内置函数的执行。所有跨存储引擎的功能也在这一层实现，如过程、函数等。在该层，服务器会解析查询并创建相应的内部解析树，并对其完成相应的优化如确定表的查询的顺序，是否利用索引等，最后生成相应的执行操作。如果是select语句，服务器还会查询内部的缓存，如果缓存空间足够大，这样在解决大量读操作的环境中能够很好的提升系统的性能。
引擎层

存储引擎层，存储引擎真正的负责了MySQL中数据的存储和提取，服务器通过API和存储引擎进行通信。不同的存储引擎具有不同的功能，这样我们可以根据自己的需要，来选取合适的存储引擎。
存储层

数据存储层，主要是将数据存储在文件系统之上，并完成与存储引擎的交互。

和其他数据库相比，MySQL有点与众不同，它的架构可以在多种不同场景中应用并发挥良好作用。主要体现在存储引擎上，插件式的存储引擎架构，将查询处理和其他的系统任务以及数据的存储提取分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎。

MySQL体系结构

存储引擎

概述

和大多数的数据库不同，MySQL中有一个存储引擎的概念，针对不同的存储需求可以选择最优的存储引擎。
存储引擎就是存储数据，建立索引，更新查询数据等等技术的实现方式。**存储引擎是基于表的，而不是基于库的。**所以存储引擎也可被称为表类型。
Oracle，SqlServer等数据库只有一种存储引擎。MySQL提供了插件式的存储引擎架构。所以MySQL存在多种存储引擎，可以根据需要使用相应引擎，或者编写存储引擎。
MySQL5.0支持的存储引擎包含：InnoDB、MyISAM、BDB、MEMORY、MERGE、EXAMPLE、NDB Cluster、ARCHIVE、CSV、BLACKHOLE、FEDERATED等，其中InnoDB和BDB提供事务安全表，其他存储引擎是非事务安全表。

查看存储引擎：show engines 或者 show variables like ‘%storage_engine%’

各种存储引擎的特性

特点	InnoDB	MyISAM	MEMORY	MERGE	NDB
存储限制	64TB	有	有	没有	有
事务安全	支持
锁机制	行级锁（适合高并发）	表级锁	表级锁	表级锁	行级锁
B树索引	支持	支持	支持	支持	支持
哈希索引			支持
全文索引	支持（5.6版本之后）	支持
集群索引	支持
数据索引	支持		支持		支持
索引缓存	支持	支持	支持	支持	支持
数据可压缩		支持
空间使用	高	低	N/A	低	低
内存使用	高	低	中等	低	高
批量插入速度	低	高	高	高	高
支持外键	支持

注意：常用的两种存储引擎：InnoDB、MyISAM

InnoDB

InnoDB存储引擎是Mysql的默认存储引擎。InnoDB存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全。但是对比MyISAM的存储引擎，InnoDB写的处理效率差一些，并且会占用更多的磁盘空间以保留数据和索引。

事务：
- start transaction：开启事务
- commit：提交事务
- rollback：回滚事务
外键：
- ON DELETE RESTRICT：删除主表数据时，如果有关联记录，不删除
- ON UPDATE CASCADE：更新主表时，如果子表有关联记录，更新子表记录
存储方式：

InnoDB存储表和索引有以下两种方式：
① 使用共享表空间存储，这种方式创建的表的表结构保存在.frm文件中，数据和索引保存在innodb_data_home_dir和innodb_data_file_path定义的表空间中，可以是多个文件。
② 使用多表空间存储，这种方式创建的表的表结构仍然存在.frm文件中，但是每个表的数据和索引单独保存在.ibd中。

MyISAM

MyISAM不支持事务、也不支持外键，其优势是访问的速度快，对事务的完整性没有要求或者以SELECT、INSERT为主的应用基本上都可以使用这个引擎来创建表。有以下两个比较重要的特点：

不支持事务
文件存储方式

每个MyISAM在磁盘上存储成3个文件，其文件名都和表名相同，但拓展名分别是：
.frm（存储表定义）
.MYD(MYData，存储数据)
.MYI(MYIndex，存储索引)

MEMORY

Memory存储引擎将表的数据存放在内存中。每个MEMORY表实际对应一个磁盘文件，格式是.frm，该文件中只存储表的结构，而其数据文件，都是存储在内存中，这样有利于数据的快速处理，提高整个表的效率。MEMORY类型的表访问非常地快，因为他的数据是存放在内存中的，并且默认使用HASH索引，但是服务一旦关闭，表中的数据就会丢失。

MERGE

MERGE存储引擎是一组MylSAM表的组合，这些MyISAM表必须结构完全相同，MERGE表本身并没有存储数据，对MERGE类型的表可以进行查询、更新、删除操作，这些操作实际上是对内部的MyISAM表进行的。
对于MERGE类型表的插入操作是通过INSERT_METHOD子句定义插入的表，可以有3个不同的值，使用FIRST或LAST值使得插入操作被相应地作用在第一或者最后一个表上，不定义这个子句或者定义为NO，表示不能对这个MERGE表执行插入操作。
可以对MERGE表进行DROP操作，但是这个操作只是删除MERGE表的定义，对内部的表是没有任何影响的。

merge

create table user_1(
    id int,
    name varchar(20),
    age int,
    primary key(id)
)engine=myisam default charset=utf8;
create table user_2(
    id int,
    name varchar(20),
    age int,
    primary key(id)
)engine=myisam default charset=utf8;
-- 使用MERGE组合user 1和2
create table user_all(
    id int,
    name varchar(20),
    age int,
    primary key(id)
)engine=merge union = (user_1, user_2) INSERT_METHOD=LAST default charset=utf8;

存储引擎的选择

在选择存储引擎时，应该根据应用系统的特点选择合适的存储引擎。对于复杂的应用系统，还可以根据实际情况选择多种存储引擎进行组合。以下是几种常用的存储引擎的使用环境。

InnoDB：是Mysq|的默认存储引擎，用于事务处理应用程序，支持外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询意外，还包含很多的更新、删除操作，那么InnoDB存储引擎是比较合适的选择。InnoDB存储引擎除了有效的降低由于删除和更新导致的锁定，还可以确保事务的完整提交和回滚，对于类似于计费系统或者财务系统等对数据准确性要求比较高的系统，InnoDB是最合适的选择。
MyISAM：如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么选择这个存储引擎是非常合适的。
MEMORY：将所有数据保存在RAM中，在需要快速定位记录和其他类似数据环境下，可以提供几块的访问。MEMORY的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，其次是要确保表的数据可以恢复，数据库异常终止后表中的数据是可以恢复的。MEMORY表通常用于更新不太频繁的小表，用以快速得到访问结果。
MERGE：用于将一系列等同的MyISAM表以逻辑方式组合在一起，并作为一个对象引用他们。MERGE表的优点在于可以突破对单个MyISAM表的大小限制，并且通过将不同的表分布在多个磁盘上，可以有效的改善MERGE表的访问效率。这对于存储诸如数据仓储等VLDB环境十分合适。

优化SQL步骤

查看SQL执行频次

查看当前连接：show status like 'Com_______'
查看全局连接：show global status like 'Com_______'
查看Innodb连接：show status like 'Innodb_rows_%'

sql执行频率参数

Com_***：这些参数对于所有存储引擎的表操作都会进行累计
Innodb_***：这些参数只是针对InnoDB存储引擎的，累加的算法略有不同

定位低效率执行SQL

可以通过以下两种方式定位执行效率较低的SQL语句

慢查询日志：通过慢查询日志定位那些执行效率较低的SQL语句，用–log-slow-queries[=file_ name]选项启动时，mysqld写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件。
show processlist：慢查询日志在查询结束以后才纪录，所以在应用反映执行效率出现问题的时候查询慢查询日志并不能定位问题，可以使用show processlist命令查看当前MySQL在进行的线程，包括线程的状态、是否锁表等，可以实时地查看SQL的执行情况，同时对一些锁表操作进行优化。

Id | User | Hos             | db   | Command | Time | State  | Info			   |
---|------|-----------------|------|---------|------|--------|------------------|
10 | root | localhost:60787 | game | Query   | 0    | (NULL) | show processlist |
# 1. id列		：用户登录mysql时，系统分配的connection_id，可以使用函数connection_id()查看
# 2. user列		：显示当前用户。如果不是root，这个命令就只能显示用户权限范围的sql语句
# 3. host列		：显示这个语句是从哪个ip的哪个端口上发的，可以用来跟踪出现问题语句的用户
# 4. db列 		：显示这个进程目前连接的是哪个数据库
# 5. command列	：显示当前连接的执行的命令，一般取值为休眠（sleep），查询（query），连接（connect）等
# 6. time列		：显示这个状态持续的时间，单位秒
# 7.state列		：显示当前连接sql语句的状态，state描述的是语句执行中的某一个状态。一个sql语句，以查询为例，可能需要经过copying to tmp table、					 sorting result、sending data等状态才可以完成
# 8.into列		：显示这个sql语句

explain分析执行计划

通过以上步骤查询到效率低的SQL语句后，可以通过EXPLAIN或者DESC命令获取MySQL如何执行SELECT语句的信息，包括在SELECT语句执行过程中表如何连接和连接的顺序。

查询SQL语句执行计划：explain select * from tb_item where id = 1

explain - id：id字段是select查询的序列号，是一组数字，表示的是查询中执行select子句或者是操作表的顺序。

id情况有三种：
1. id相同表示加载表的顺序从上到下
2. id不同id值越大，优先级越高，越先被执行
3. id有相同也有不同，同时存在。id相同的可以认为是一组，从上往下顺序执行；在所有的组中，id的值越大，优先级越高，越先执行。

explain - select_type：表示select的类型，常见的取值如下：

select_type	含义
SIMPLE	简单的select查询，查询中不包含子查询或者UNION
PRIMARY	查询中若包含任何复杂的子查询，最外层查询标记为该标识
SUBQUERY	在SELECT或WHERE列表中包含了子查询
DERIVED	在FROM列表中包含的子查询，被标记为DERIVED(衍生)MYSQL会递归执行这些子查询，把结果放在临时表中
UNION	若第二个SELECT出现在UNION之后，则标记为UNION；若UNION包含在FROM子句的子查询中，外层SELECT将被标记为: DERIVED
UNION RESULT	从UNION表获取结果的SELECT

explain - table：展示这一行的数据是关于哪一张表的

explain - type：type显示访问类型，可取值为：

type	含义
NULL	MySQL不访问任何表，索引，直接返回结果
system	表只有一行记录(等于系统表)，这是const类型的特例，一般不会出现
const	表示通过索引一次就找到了，const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快。如将主键置于where列表中，MySQL就能将该查询转换为一个常量。const于将"主键"或"唯一"索引的所有部分与常量值进行比较
eq_ref	类似ref，区别在于使用的是唯一索引，使用主键的关联查询，关联查询出的记录只有一条。常见于主键或唯一索引扫描
ref	非唯一性索引扫描，返回匹配某个单独值的所有行。本质上也是一种索引访问，返回所有匹配某个单独值的所有行(多个)
range	只检索给定返回的行，使用一个索引来选择行。where之后出现between，<，>，in等操作。
index	index与ALL的区别为index类型只是遍历了索引树，通常比ALL快，ALL是遍历数据文件。
all	将遍历全表以找到匹配的行

一般来说，我们查询至少达到range级别，最好达到ref

explain - key：
- possible_keys：显示可能应用在这张表的索引，一个或多个
- key：实际使用的索引，如果为NULL，则没有使用索引
- key_len：表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下，长度越短越好
explain - rows：扫描行的数量

explain - extra：其他的额外的执行计划信息，在该列展示

extra	含义
using filesort	说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取，称为"文件排序"
using temporary	使用了临时表保存中间结果，MySQL在对查询结果排序时使用临时表。常见于order by和group by
using index	表示相应的select操作使用了覆盖索引，避免访问表的数据行，效率不错。

如果出现using filesort和using temporary需要进行优化操作

show profile分析SQL

Mysq|从5.0.37版本开始增加了对show profiles和show profile语句的支持。show profiles能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。

通过have_profiling参数，能够查看MySQL是否支持profile

select @@have_profiling
默认profiling是关闭的，可以通过set语句在Session级别开启profiling：

select @@profiling
开启profile

set profiling = 1
查看分析

show profiles
查看具体某一项消耗信息

show profile for query Query_Id

profiles-query

注意：Sending data 状态表示MySQL线程开始访问数据行并把结果返回给客户端，而不仅仅是返回个客户端。由于在Sending data状态下，MySQL线程往往需要做大量的磁盘读取操作，所以经常是整个查询中耗时最长的状态。

在获取到最消耗时间的线程状态后，MySQL支持进一步选择all、cpu、block io、context switch、page faults等明细类型类查看MySQL在使用什么资源上耗费了过高的时间。例如，选择查看CPU的耗费时间：

show profile cpu for query 6

profiles-cpu

trace分析优化器执行计划

MySQL5.6提供了对SQL的跟踪trace，通过trace文件能够进一步了解为什么优化器选择A计划，而不是选择B计划。
打开trace，设置格式为JSON，并设置trace最大能够使用的内存大小，避免解析过程中因为默认内存过小而不能够完整展示。

SET optimizer_trace = "enabled=on", end_markers_in_json=on;		# 开启
set optimizer_trace_max_mem_size=1000000;	# 设置最大占用

-- 执行查询语句
select * from tablename where id = num;

# 检查information_schema.optimizer_trace就可以知道MySQL是如何执行SQL的
select * from information_schema.optimizer_trace\G;

索引的使用

索引是数据库优化最常用也是最重要的手段之一，通过索引通常可以帮助用户解决大多数的MySQL的性能优化问题。

验证索引提升查询效率

假设tb_item表中有300w条数据，使用普通查询要花费很长时间查询，而索引查询只要花费几十毫秒

验证索引执行效率

索引的使用

环境数据：索引值为name，status，address

环境数据

避免索引失效
1. 全值匹配：对索引中多有列都执行具体值
  
  该情况下，索引生效，执行效率高
  
  explain select * from tb_seller where name = '小米科技' and status = '1' and address = '北京市';
2. 最左前缀法则：如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始，并且不跳过索引中的列。
  
  不走索引：explain select * from tb_seller where status = '1' and address = '北京市';
  
  不走索引：explain select * from tb_seller where address = '北京市';
  
  走索引：explain select * from tb_seller where name = '小米科技' and status = '1';
  
  走索引，但是只有name索引生效：explain select * from tb_seller where name = '小米科技' address = '北京市';
3. 范围查询右边的列，不能使用索引
  
  走索引，但范围status后面address索引失效explain select * from tb_seller where name = '小米科技' and status > '1' and address = '北京市';
4. 不要再索引上进行运算操作，索引将失效
  
  索引失效：explain select * from tb_seller where substring(name,3,2) = '科技';
5. 字符串不加单引号，索引失效，底层对数据进行了隐士转换运算，违反了4的规则
  
  走索引，单status失效：explain select * from tb_seller where name = '小米科技' and status = 1;
6. 尽量使用覆盖索引，避免使用select *回表查询
  - 尽量使用覆盖索引（只访问索引的查询（索引列完全包含查询列）），减少select *
  - 如果查询列，超出了索引列，也会降低性能
  tip：
  - using index：使用覆盖索引时会出现
  - using where：在查找使用索引的情况下，需要回表去查询所需的数据
  - using index condition：查找使用了索引，但是需要回表查询数据
  - using index；using where：查找使用了索引，但是需要的数据都在索引列中能找到，所以不需要回表查询数据
7. 用or分割开的条件，如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。
  
  不走索引：explain select * from tb_seller where name = '小米科技' or nickname = '小米官方旗舰店';
8. 以%开头的Like模糊查询，索引失效。
  
  如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效。
9. 如果MySQL评估使用索引比全表更慢，则不适用索引
10. is NULL， is NOT NULL 有时索引失效
  
  如果大部分数据是null，is not null 走索引，而is null不走索引
  
  如果小部分数据是null，is not null 不走索引，而is null走索引
11. in 走索引，not in 索引失效
12. 单例索引和复合索引
  
  尽量使用复合索引，而少使用单列索引。
```
# 创建复合索引
create index idx_name_sta_address on tbl_name(name, statu, address)
-- 相当于创建了三个索引:
	1. name
	2. name + statu
	3. name + statu + address
	
# 创建单例索引
create index idx_name on tbl_name(name)
create index idx_name on tbl_name(statu)
create index idx_name on tbl_name(address)
```
  如果多个单列索引一起用时，数据库会选择一个最优索引（辨识度最高的）来使用，并不会使用全部索引

查看索引使用情况

查看当前连接索引：show status like 'Handler_read%';
查看全局连接索引：show global status like 'Handler_read%';

变量名	描述
Handler_read_first	索引中第一条被读的次数。如果较高，表示服务器正执行大量全索引扫描(这个值越低越好)。
Handler_read_key	如果索引正在工作，这个值代表一个行被索引值读的次数，如果值越低，表示索引得到的性能改善不高，因为索引不经常使用（这个值越高越好）
Handler_read_next	按照键顺序读下一行的请求数。如果你用范围约束或如果执行索引扫描来查询索引列，该值增加。
Handler_read_prev	按照键顺序读前一行的请求数。该读方法主要用于优化ORDER BY … DESC。
Handler_read_rnd	根据固定位置读一行的请求数。如果你正执行大量查询并需要对结果进行排序该值较高。你可能使用了大量需要MySQL扫描整个表的查询或你的连接没有正确使用键。这个值较高，意味着运行效率低，应该建立索引来补救。
Handler_read_rnd_next	在数据文件中读下一行的请求数。如果你正进行大量的表扫描，该值较高。通常说明你的表索引不正确或写入的查询没有利用索引

SQL优化

大批量插入数据

当使用load命令导入数据的时候，适当的设置可以提高导入的效率

语法：load data local infile '/root/sql.log' into table 'tb_user' fields terminated by ',' lines terminated by '\n';

对于InnoDB类型的表，有以下几种方式提高导入的效率：

主键顺序插入

因为InnoDB类型的表是按照主键的顺序保存的，所以将导入的数据按照主键的顺序排列，可以有效的提高导入数据的效率。如果InnoDB表没有主键，那么系统会自动默认创建一个内部列作为主键，所以如果可以给表创建一个主键，将可以利用这点，来提高导入数据的效率。
- 主键有序：sql1 load tb_user1 100w约 20s
- 主键无序：sql2 load tb_user2 100w约 1m50s
关闭唯一性校验

在导入数据前关闭唯一性校验，在导入结束后恢复唯一性校验，可以提高导入的效率。
- 关闭唯一性校验：SET UNIQUE CHECKS=0
- 开启唯一性校验：SET UNIQUE CHECKS=1
手动提交事务

如果应用使用自动提交的方式，建议在导入前关闭自动提交，导入结束后打开自动提交，也可以提高导入的效率。
- 关闭自动提交：SET AUTOCOMMIT=0`
- 打开自动提交：SET AUTOCOMMIT=1`

优化Insert语句

当使用insert操作时，可以考虑使用以下几个优化方案：

如果需要同时对一张表插入很多行数据时，应该尽量使用多个值表的insert语句，这种方式将大大的缩减客户端与数据库之间的连接、关闭等消耗。使得效率比分开执行的单个insert语句快。
```
# 原方式
    insert into tb_user value (1, 'zhangsan');
    insert into tb_user value (2, 'lisi');
    insert into tb_user value (3, 'wangwu');
# 优化方式
	insert into tb_user values (1, 'zhangsan'),(2, 'lisi'),(3, 'wangwu');
```

在事务中进行数据插入

# 事务提交改为手动提交
start transaction;
    insert into tb_user value (1, 'zhangsan');
    insert into tb_user value (2, 'lisi');
    insert into tb_user value (3, 'wangwu');
commit;

数据有序插入

# 原方式
    insert into tb_user value (3, 'wangwu');
    insert into tb_user value (1, 'zhangsan');
    insert into tb_user value (2, 'lisi');
# 优化方式
    insert into tb_user value (1, 'zhangsan');
    insert into tb_user value (2, 'lisi');
    insert into tb_user value (3, 'wangwu');

优化Order By语句

两种排序方式：filesort、using index

第一种是通过对返回数据进行排序，也就是通常说的filesort排序，所有不是通过索引直接返回排序结果的排序都叫FileSort排序。

如果返回结果有一项不含有索引，则都是filesort
第二种通过有序索引顺序扫描直接返回有序数据，这种情况即为using index，不需要额外排序，操作效率高。

如果返回值都是索引字段，则是using index

多字段排序：
- 最好全部升序或者全部降序：using index
- 如果多字段排序：符合索引没按照顺序：using index；filesort
- 如果一个升序一个降序：using index；filesort

了解了MySQL的排序方式，优化目标就清晰了：尽量减少额外的排序，通过索引直接返回有序数据。where 条件和Order by使用相同的索引，并且Order By的顺序和索引顺序相同，并且Order by 的字段都是升序，或者都是降序。否则肯定需要额外的操作，这样就会出现FileSort。

FileSort的优化

通过创建合适的索引，能够减少Filesort的出现，但是在某些情况下，条件限制不能让Filesort消失，那就需要加快Filesort的排序操作。对于Filesort，MySQL有两种排序算法：

两次扫描算法：MySQL4.1之前，使用该方式排序。首先根据条件取出排序字段和行指针信息，然后在排序区sort buffer中排序，如果sort buffer不够，则在临时表temporary table中存储排序结果。完成排序之后，再根据行指针回表读取记录，该操作可能会导致大量随机I/O操作。
一次扫描算法：一次性取出满足条件的所有字段，然后在排序区sort buffer中排序后直接输出结果集。排序时内存开销较大，但是排序效率比两次扫描算法要高。

MySQL通过比较系统变星max_length_for_sort_data的大小和Query语句取出的字段总大小，来判定是否那种排序算法，如果max_length_for_sort_data更大，那么使用第二种优化之后的算法；否则使用第一种。

可以适当提高sort_buffer_size和max_length_for_sort_data系统变量，来增大排序区的大小，提高排序的效率。

优化Group By语句

由于GROUP BY实际上也同样会进行排序操作，而且与ORDER BY相比，GROUP BY要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函数的计算。所以，在GROUP BY的实现过程中，与ORDER BY一样也可以利用到索引。

如果查询包含group by但是用户想要避免排序结果的消耗，则可以执行order by null禁止排序。如下：

drop index idx_emp_age_salary on emp;
# 优化前
	explain select age, count(*) from emp group by age;		-- using temporary;using filesort
# 优化后
	explain select age, count(*) from emp group by age order by null;	-- using temporary;
# 创建索引再优化
create index idx_emp_age_salary on emp(age,salary);
	explain select age, count(*) from emp group by age order by null;	-- using index;

优化嵌套查询

Mysq|4.1版本之后，开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询是可以被更高效的连接( JOIN )替代。

## 查找有角色的所有的用户信息
# 优化前
	explain select * from t_user where id in (select user_id from user_role)
# 优化后
	explain select * from t_user u, user_role r where u.id = r.user_id

优化or条件

对于包含OR的查询子句，如果要利用索引，则OR之间的每个条件列都必须用到索引，而且不能使用到复合索引；如果没有索引，则应该考虑增加索引。

建议使用union替换or：

# emp 索引 primary:id      idx_emp_age_salary:age,salary
-- 优化前
	explain select * from emp where id = 1 or name = 'zimo';	-- 索引失效
	explain select * from emp where age = 1 or salary = 350;	-- 索引失效
	
	explain select * from emp where id = 1 or id = 10;		    -- 索引生效:PRIMARY  type:range 
	explain select * from emp where id = 1 or age = 20;			-- 索引生效:idx_emp_age_salary  type:index_merge 
-- 优化后  const > range     ref > index_merge
	explain select * from emp where id = 1 union select * from emp where id = 10;	-- 索引生效:PRIMARY  type:const/const
	explain select * from emp where id = 1 union select * from emp where age = 20;	-- 索引生效:idx_emp_age_salary  type:const/ref

通过对比：差别在于type 和 ref两项

type：显示的是访问类型，好坏排序

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
UNION语句的type值为ref，OR语句的type值为range，可以看到这是一个很明显的差距
UNION语句的ref值为const，OR语句的type值为null，const表示是常量值引用，非常快

这两项的差距就说明了UNION要优于OR。

优化分页查询

一般分页查询时，通过创建覆盖索引能够比较好地提高性能。一个常见又非常头疼的问题就是limit 2000000，10，此时需要MySQL排序前2000010记录，仅仅返回2000000~2000010的记录，其他记录丢弃，查询排序的代价非常大。

select * from tb_item limit 2000000,10

优化思路一：在索引上完成排序分页操作，最后根据主键关联回原表查询所需要的其他列内容。

先通过主键取出查询的主键，再通过主键关联查询原表数据

select * from tb_item t, (select id from tb_item order by id limit 2000000,10) a where t.id = a.id;
该方案适用于主键自增的表，可以把Limit查询转换成某个位置的查询。

select * from tb_item where id > 2000000 limit 10;

使用SQL提示

SQL提示，是优化数据库的一个重要手段，简单来说，就是在SQL语句中加入一些人为的提示来达到优化操作的目的。

USE INDEX

在查询语句中表名的后面，添加use index来提供希望MySQL去参考的索引列表，就可以让MySQL不再考虑其他可用的索引。

create index idx_name on tb_user(name)
create index idx_name_age_addr on tb_user(name,age,addr)
-- USE INDEX 指定一种索引，不一定生效
explain select * from tb_user use index(idx_name_age_addr) where name = 'zimo'; # 使用idx_name_age_addr索引查询

IGNORE INDEX

如果用户只是单纯的想让MySQL忽略一个或者多个索引，则可以使用ignore index作为hint。

create index idx_name on tb_user(name)
create index idx_name_age_addr on tb_user(name,age,addr)
-- IGNORE INDEX 忽略一种索引
explain select * from tb_user ignore index(idx_name_age_addr) where name = 'zimo'; # 使用idx_name索引查询

FORCE INDEX

为强制MySQL使用一个特定的索引，可在查询中使用force index作为hint。

create index idx_addr on tb_user(addr)
create index idx_name_age_addr on tb_user(name,age,addr)
-- IGNORE INDEX 即使全表扫描比索引快，强制使用
explain select * from tb_user force index(idx_name_age_addr) where addr = '北京'; # 全表扫描比索引快

MySQL - 中

MySQL的体系结构

存储引擎

概述

各种存储引擎的特性

InnoDB

MyISAM

MEMORY

MERGE

存储引擎的选择

优化SQL步骤

查看SQL执行频次

定位低效率执行SQL

explain分析执行计划

show profile分析SQL

trace分析优化器执行计划

索引的使用

验证索引提升查询效率

索引的使用

查看索引使用情况

SQL优化

大批量插入数据

优化Insert语句

优化Order By语句

FileSort的优化

优化Group By语句

优化嵌套查询

优化or条件

优化分页查询

使用SQL提示

USE INDEX

IGNORE INDEX

FORCE INDEX

猜你喜欢