MySQL——SQL优化

1.大批量插入数据

使用load 命令导入数据:


image.png

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

1) 主键顺序插入
image.png

无顺序:


image.png
2) 关闭唯一性校验

在导入数据前执行 SET UNIQUE_CHECKS=0,关闭唯一性校验,在导入结束后执行SET UNIQUE_CHECKS=1,恢复唯一性校验,可以提高导入的效率。

如果表中存在唯一性索引,那么在插入数据的时候数据库会维护这个唯一性索引,插入数据会花费更多的时间。

3) 手动提交事务

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

优化insert语句

1) 合并insert语句

原始:

insert into tb_test values(1,'Tom');
insert into tb_test values(2,'Cat');
insert into tb_test values(3,'Jerry');

优化后:

insert into tb_test values(1,'Tom'),(2,'Cat'),(3,'Jerry');
2) 使用事务手动提交
start transaction;
insert into tb_test values(1,'Tom');
insert into tb_test values(2,'Cat');
insert into tb_test values(3,'Jerry');
commit;

如果数据量比较大,分段提交。

3) 按照主键顺序插入

原始:

insert into tb_test values(4,'Tim');
insert into tb_test values(1,'Tom');
insert into tb_test values(3,'Jerry');
insert into tb_test values(5,'Rose');
insert into tb_test values(2,'Cat');

优化后:

insert into tb_test values(1,'Tom');
insert into tb_test values(2,'Cat');
insert into tb_test values(3,'Jerry');
insert into tb_test values(4,'Tim');
insert into tb_test values(5,'Rose');

3.优化order by语句

在MySQL中有两种排序方式,也就是在explain语句的时候EXTRA列可能出现的参数中的两种:


image.png
1)FileSort 排序

通过对返回数据进行排序,也就是通常说的 filesort 排序,所有不是通过索引直接返回排序结果的排序都叫 FileSort 排序。
新建的联合索引是age,salary,主键索引为id。


image.png

这种排序效率比较低。

2) using index排序

第二种通过有序索引顺序扫描直接返回有序数据,这种情况即为 using index,不需要额外排序,操作效率高。


image.png

在多字段排序时:
尽量减少额外的排序,通过索引直接返回有序数据。where 条件和Order by 使用相同的索引,并且Order By 的顺序和索引顺序相同
并且Order by 的字段都是升序,或者都是降序。否则肯定需要额外的操作,这样就会出现FileSort。

Filesort 的优化

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

1) 两次扫描算法

MySQL4.1 之前,使用该方式排序。首先根据条件取出排序字段和行指针信息,然后在排序区sort buffer 中排序,如果sort buffer不够,则在临时表 temporary table 中存储排序结果。完成排序之后,再根据行指针回表读取记录,该操作可能会导致大量随机I/O操作。

2)一次扫描算法

一次性取出满足条件的所有字段,然后在排序区 sort buffer 中排序后直接输出结果集。排序时内存开销较大,但是排序效率比两次扫描算法要高。

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

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

4.优化group by 语句

GROUP BY 实际上也会进行排序操作,而且与ORDER BY 相比,GROUP BY 主要只是多了排序之后的分组操作。
如果想要避免排序结果的消耗, 则可以执行order by null 禁止排序。
原始:
explain select age,count(*) from emp group by age;

image.png

优化后:
explain select age,count(*) from emp group by age order by null;
image.png

还可以创建索引来优化group by 语句:
create index idx_emp_age_salary on emp(age,salary);

image.png

5.优化嵌套查询

查找有角色的所有的用户信息 (使用嵌套查询子查询):


image.png

优化:
使用多表联查来替代子查询:


image.png

6.优化OR

对于包含OR的查询语句,如果要利用索引,则OR关联的各个字段都必须有索引 , 而且不能使用到复合索引,如果有一个字段没有索引,那么所有的字段的索引都会失效; 如果没有索引,则应该考虑增加索引。

id字段有主键索引,而name字段没有索引:


image.png

有联合索引,可以看到使用OR后没有使用联合索引:


image.png

创建索引来优化OR查询理论上是可行的,但是很多官方网站更推荐用union 替换 or。
查询id:


image.png

因为id有主键索引,所以查询的时候走了主键索引,但是type的类型是range,所以查询效率还可以再优化,使用union优化(union就是求并集):


image.png

const的查询效率远远高于range。

再举一个例子:
原始:


image.png

优化:


image.png

type 显示的是访问类型,结果值从好到坏依次是:

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge >
unique_subquery > index_subquery > range > index > ALL

7.优化分页查询

limit查询越往后,查询效率越低:
查询前面的值:


image.png

查询后面的值:


image.png

因为进行分页操作的时候,首先会进行排序操作。当查询从200w条记录开始,获取10条记录时,相当于要对前2000010条记录进行排序,排序后,仅仅返回2000000-2000010条记录,前2000000条数据就丢弃了,代价比较大。
优化思路1

在索引上排序,取到要返回结果的索引,再根据这个索引,到原来的表中查询全部结果。


image.png

根据主键关联回原表查询所需要的其他列内容:


image.png

比较:
image.png
优化思路2

适用于主键自增的表(而且不能出现断层),把limit查询转化成某个位置的查询。


image.png

8.使用SQL提示

USE INDEX

建议数据库考虑使用某个索引。


image.png
IGNORE INDEX
image.png
FORCE INDEX

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

如果时use index,只是让数据库考虑使用某个索引,数据库可以采用也可以不采用:


image.png

使用force index:


image.png

9.应用优化

1)使用数据库连接池

对于访问数据库来说,建立连接的代价是比较昂贵的,因为我们频繁的创建关闭连接,是比较耗费资源的,我们有必要建立 数据库连接池,以提高访问的性能。

2)减少对MySQL的访问

1.避免对数据进行重复检索
比如 ,需要获取书籍的id 和name字段 , 则查询如下:
select id , name from tb_book;
之后,在业务逻辑中有需要获取到书籍状态信息, 则查询如下:
select id , status from tb_book;
这样,就需要向数据库提交两次请求,数据库就要做两次查询操作。其实完全可以用一条SQL语句得到想要的结果。
select id, name , status from tb_book;

2.增加cache层
在应用中,我们可以在应用中增加 缓存 层来达到减轻数据库负担的目的。缓存层有很多种,也有很多实现方式,只要能达到降低数据库的负担又能满足应用需求就可以。
因此可以部分数据从数据库中抽取出来放到应用端以文本方式存储, 或者使用框架(Mybatis, Hibernate)提供的一级缓存/二级缓存,或者使用redis数据库来缓存数据 。

3)负载均衡
  1. 利用MySQL复制分流查询
    通过MySQL的主从复制,实现读写分离,使增删改操作走主节点,查询操作走从节点,从而可以降低单台服务器的读写压力。

2.采用分布式数据库架构
分布式数据库架构适合大数据量、负载高的情况,它有良好的拓展性和高可用性。通过在多台服务器之间分布数据,可以实现在多台服务器之间的负载均衡,提高访问效率。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,132评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,802评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,566评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,858评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,867评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,695评论 1 282
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,064评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,705评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,915评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,677评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,796评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,432评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,041评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,992评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,223评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,185评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,535评论 2 343