MySQL-索引优化与查询优化2

最新推荐文章于 2023-05-22 07:45:00 发布
最新推荐文章于 2023-05-22 07:45:00 发布
阅读量792 收藏
点赞数
分类专栏： MySQL 文章标签： mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/cheng1877/article/details/126687611
版权
本文详细探讨了MySQL中的关联查询优化，通过举例展示了左外连接和内连接的优化策略。实验表明，为被驱动表的JOIN字段创建索引、选择小表作为驱动表以及减少不必要的字段查询能显著提升查询效率。此外，还介绍了Nested Loop Join、Index Nested Loop Join和Block Nested Loop Join三种JOIN算法的工作原理及其优缺点。
摘要由CSDN通过智能技术生成

个人学习笔记
源自B站尚硅谷讲师宋红康的MySQL课程
B站地址：https://www.bilibili.com/video/BV1iq4y1u7vj

3.关联查询优化

3.1 数据准备
#分类
CREATE TABLE IF NOT EXISTS `type` (
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`id`)
);

#图书
CREATE TABLE IF NOT EXISTS `book` (
`bookid` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`bookid`)
);

#向分类表中添加20条记录
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));

#向图书表中添加20条记录
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
3.2 采用左外连接

下面开始EXPLAIN分析

EXPLAIN SELECT SQL_NO_CACHE * FROM `type` LEFT JOIN book ON type.card = book.card;

在这里插入图片描述
结论: type有All

添加索引优化

CREATE INDEX Y ON book(card); #【被驱动表】，可以避免全表扫描

EXPLAIN SELECT SQL_NO_CACHE * FROM `type` LEFT JOIN book ON type.card = book.card;

在这里插入图片描述
可以看到第二行的 type 变为了 ref，rows 也变成了优化比较明显。这是由左连接特性决定的。LEFT JOIN条件用于确定如何从右表搜索行，左边一定都有，所以 右边是我们的关键点,一定需要建立索引 。

CREATE INDEX X ON `type`(card);#【驱动表】，无法避免全表扫描

EXPLAIN SELECT SQL_NO_CACHE * FROM `type` LEFT JOIN book ON type.card = book.card;

在这里插入图片描述
接着：

DROP INDEX Y ON book;

EXPLAIN SELECT SQL_NO_CACHE * FROM `type` LEFT JOIN book ON type.card = book.card;

在这里插入图片描述

3.3 采用内连接
DROP INDEX X ON `type`;
DROP INDEX Y ON book; #（如果已经删除了可以不用再执行该操作）

换成 inner join（MySQL自动选择驱动表）

EXPLAIN SELECT SQL_NO_CACHE * FROM `type` INNER JOIN book ON type.card = book.card;

在这里插入图片描述

#添加索引
CREATE INDEX Y ON book(card);

EXPLAIN SELECT SQL_NO_CACHE * FROM `type` INNER JOIN book ON type.card = book.card;

在这里插入图片描述

CREATE INDEX X ON `type`(card);

#结论：对于内连接来说，查询优化器可以决定谁作为驱动表，谁作为被驱动表出现的
EXPLAIN SELECT SQL_NO_CACHE * FROM `type` INNER JOIN book ON type.card = book.card;

在这里插入图片描述
接着：

#删除索引
DROP INDEX Y ON book;

#结论：对于内连接来讲，如果表的连接条件中只能有一个字段有索引，则有索引的字段所在的表会被作为被驱动表出现。
EXPLAIN SELECT SQL_NO_CACHE * FROM `type` INNER JOIN book ON type.card = book.card;

在这里插入图片描述

CREATE INDEX Y ON book(card);
EXPLAIN SELECT SQL_NO_CACHE * FROM `type` INNER JOIN book ON type.card = book.card;

在这里插入图片描述
向type表中添加数据（20条数据）；

注意：这边目前情况是type作为驱动表的所以给它添加数据

#向type表中添加数据（20条数据）;注意：这边目前情况是type作为驱动表的所以给它添加数据
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO `type`(card) VALUES(FLOOR(1 + (RAND() * 20)));

#结论：对于内连接来说，在两个表的连接条件都存在索引的情况下，会选择小表作为驱动表。“小表驱动大表”
EXPLAIN SELECT SQL_NO_CACHE * FROM `type` INNER JOIN book ON type.card = book.card;

在这里插入图片描述

结论1：对于内连接来说，查询优化器可以决定谁来作为驱动表，谁作为被驱动表出现

结论2：对于内连接来讲，如果表的连接条件中只能有一个字段有索引，则有索引的字段所在的表会被作为被驱动表

结论3：对于内连接来说，在两个表的连接条件都存在索引的情况下，会选择小表作为驱动表。小表驱动大表

3.4 JOIN语句原理

join方式连接多个表，本质就是各个表之间数据的循环匹配。MySQL5.5版本之前，MySQL只支持一种表间关联方式，就是嵌套循环(Nested Loop Join)。如果关联表的数据量很大，则join关联的执行时间会非常长。在MySQL5.5以后的版本中，MySQL通过引入BNLJ算法来优化嵌套执行。

1.驱动表和被驱动表

驱动表就是主表，被驱动表就是从表、非驱动表。

  • 对于内连接来说:
SELECT * FROM A JOIN B ON ...

A一定是驱动表吗?不一定，优化器会根据你查询语句做优化，决定先查哪张表。先查询的那张表就是驱动表，反之就是被驱动表。通过explain关键字可以查看。

  • 对于外连接来说:
SELECT * FROM A LEFT JOIN B ON ...
#或
SELECT * FROM B RIGHT JOIN A ON ...

通常，大家会认为A就是驱动表，B就是被驱动表。但也未必。测试如下:


CREATE TABLE a(f1 INT, f2 INT, INDEX(f1))ENGINE=INNODB;

CREATE TABLE b(f1 INT, f2 INT)ENGINE=INNODB;


INSERT INTO a VALUES(1,1),(2,2),(3,3),(4,4),(5,5),(6,6);

INSERT INTO b VALUES(3,3),(4,4),(5,5),(6,6),(7,7),(8,8);


#测试1,实际测试发现b作为了驱动表，情况是优化器把这条SQL的左外连接改成了内连接的方式
EXPLAIN SELECT * FROM a LEFT JOIN b ON(a.f1=b.f1) WHERE (a.f2=b.f2);

#测试2
EXPLAIN SELECT * FROM a LEFT JOIN b ON(a.f1=b.f1) AND (a.f2=b.f2);

#测试3
EXPLAIN SELECT * FROM a JOIN b ON(a.f1=b.f1) WHERE (a.f2=b.f2);

测试1：实际测试发现b作为了驱动表，情况是优化器把这条SQL的左外连接改成了内连接的方式
在这里插入图片描述
测试2：
在这里插入图片描述

测试3：
在这里插入图片描述

2.Simple Nested-Loop Join(简单嵌套循环连接)

算法相当简单，从表A中取出一条数据1，遍历表B，将匹配到的数据放到result…以此类推，驱动表A中的每一条记录与被驱动表B的记录进行判断:
在这里插入图片描述
可以看到这种方式效率是非常低的，以上述表A数据100条，表B数据1000条计算，则A*B= 10万次。开销统计如下:

开销统计SNLJ
外表扫描次数:1
内表扫描次数:A
读取记录数:A+B*A
JOIN比较次数:B*A
回表读取记录次数:0

当然mysql肯定不会这么粗暴的去进行表的连接，所以就出现了后面的两种对Nested-Loop Join优化算法。

3. lndex Nested-Loop Join(索引嵌套循环连接)

Index Nested-Loop Join其优化的思路主要是为了 减少内层表数据的匹配次数，所以要求被驱动表上必须 有索引 才行。通过外层表匹配条件直接与内层表索引进行匹配，避免和内层表的每条记录去进行比较，这样极大的减少了对内层表的匹配次数。

在这里插入图片描述
驱动表中的每条记录通过被驱动表的索引进行访问，因为索引查询的成本是比较固定的，故mysql优化器都倾向于使用记录数少的表作为驱动表（外表)。

开销统计SNLJINLJ
外表扫描次数:11
内表扫描次数:A0
读取记录数:A+B*AA+B(match)
JOIN比较次数:B*AA*Index(Height)
回表读取记录次数:0B(match) (if possible)

如果被驱动表加索引，效率是非常高的，但如果索引不是主键索引，所以还得进行一次回表查询。相比，被驱动表的索引是主键索引，效率会更高。

4.Block Nested-Loop Join(块嵌套循环连接)

如果存在索引，那么会使用index的方式进行join，如果join的列没有索引，被驱动表要扫描的次数太多了。每次访问被驱动表，其表中的记录都会被加载到内存中，然后再从驱动表中取一条与其匹配，匹配结束后清除内存，然后再从驱动表中加载一条记录，然后把被驱动表的记录在加载到内存匹配，这样周而复始，大大增加了IO的次数。为了减少被驱动表的IO次数，就出现了Block Nested-Loop Join的方式。

不再是逐条获取驱动表的数据，而是一块一块的获取，引入了 join buffer缓冲区，将驱动表join相关的部分数据列(大小受join buffer的限制)缓存到join buffer中，然后全表扫描被驱动表，被驱动表的每一条记录一次性和join buffer中的所有驱动表记录进行匹配(内存中操作)，将简单嵌套循环中的多次比较合并成一次，降低了被驱动表的访问频率。

注意:

这里缓存的不只是关联表的列,select后面的列也会缓存起来。

在一个有N个join关联的sql中会分配N-1个join buffer。所以查询的时候尽量减少不必要的字段，可以让join buffer中可以存放更多的列。

在这里插入图片描述

开销统计SNLJINLJBNLJ
外表扫描次数:111
内表扫描次数:A0A* used_column_size / join_buffer_size+1
读取记录数:A+B*AA+B(match)A+B*(A * used_column_size / join_buffer_size)
JOIN比较次数:B*AA*Index(Height)B*A
回表读取记录次数:0B(match) (if possible)0

参数设置:

  • block_nested_loop

通过 show variables like '%optimizer_switch%' 查看 block_nested_loop 状态。默认是开启的。
在这里插入图片描述

  • join_buffer_size
    驱动表能不能一次加载完，要看join buffer能不能存储所有的数据，默认情况下 join_buffer_size=256k。
mysql> show variables like '%join_buffer%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| join_buffer_size | 262144 |
+------------------+--------+
1 row in set (0.00 sec)

join_buffer_size的最大值在32位系统可以申请4G，而在64位操做系统下可以申请大于4G的Join Buffer空间(64位Windows除外，其大值会被截断为4GB并发出警告)。

5.Join小结

1、整体效率比较:INLJ >BNLJ > SNLJ
2、永远用小结果集驱动大结果集(其本质就是减少外层循环的数据数量)(小的度量单位指的是表行*数每行大小)

#straight_join强制前面是驱动表，后面是被驱动表
#虽然t2被过滤了，但是选择了所有字段，导致t2的结果集实际还是比较大
#t1虽然没有被过滤，但是选择的只有字段b，最终生成的结果集就小，join Buffer就可以一次加载更多的数据量
select t1.b,t2.* from t1 straight_join t2 on (t1.b=t2.b) where t2.id<=100;#推荐

select t1.b,t2.* from t2 straight_join t1 on (t1.b=t2.b) where t2.id<=100;#不推荐

3、为被驱动表匹配的条件增加索引(减少内层表的循环匹配次数)

4、增大join buffer size的大小(一次缓存的数据越多，那么内层包的扫表次数就越少)

5、减少驱动表不必要的字段查询（字段越少，join buffer所缓存的数据就越多)

6.Hash Join

从MySQL的8.0.20版本开始将废弃BNLJ，因为从MySQL8.0.18版本开始就加入了hash join默认都会使用hash join

  • Nested Loop:

    对于被连接的数据子集较小的情况，Nested Loop是个较好的选择。

  • Hash Join是做 大数据集连接 时的常用方式，优化器使用两个表中较小(相对较小)的表利用Join Key在内存中建立 散列表，然后扫描较大的表并探测散列表，找出与Hash表匹配的行。

    • 这种方式适用于较小的表完全可以放于内存中的情况，这样总成本就是访问两个表的成本之和。
    • 在表很大的情况下并不能完全放入内存，这时优化器会将它分割成 若干不同的分区，不能放入内存的部分就把该分区写入磁盘的临时段，此时要求有较大的临时段从而尽量提高I/O的性能。
    • 它能够很好的工作于没有索引的大表和并行查询的环境中，并提供最好的性能。大多数人都说它是Join的重型升降机。Hash Join只能应用于等值连接(如WHERE A.COL1=B.COL2)，这是由Hash的特点决定的。
类别Nested LoopHash Join
使用条件任何条件等值连接(=)
相关资源CPU、磁盘I/O内存、临时空间
特点当有高选择性索引或进行限制性搜索时效率比较高，能够快速返回第一次的搜索结果。当缺乏索引或者索引条件模糊时，Hash Join比NestedLoop有效。在数据仓库环境下，如果表的纪录数多，效率高。
缺点当索引丢失或者查询条件限制不够时，效率很低;当表的纪录数多时，效率低。为建立哈希表，需要大量内存。第一次的结果返回较慢。
3.5小结

  • 保证被驱动表的JOIN字段已经创建了索引。

  • 需要JOIN的字段，数据类型保持绝对一致。

  • LEFT JOIN 时，选择小表作为驱动表，大表作为被驱动表 。减少外层循环的次数。

  • INNER JOIN时，MySQL会自动将 小结果集的表选为驱动表 。选择相信MySQL优化策略。

  • 能够直接多表关联的尽量直接关联，不用子查询。(减少查询的趟数)

  • 不建议使用子查询，建议将子查询sQL拆开结合程序多次查询，或使用JOIN来代替子查询。

  • 衍生表建不了索引。

cheng7736
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
MySQL高级知识-查询与索引优化分析
02-25
手写手写SQL顺序机读顺序总结-SQL解析顺序SQL解析SQLJOINs七种JOIN图解实验：练习1、A、B两表共有2、A、B两表共有+A的独有3、A、B两表共有+B的独有4、A的独有5、B的独有6、AB全有MySQLFullJoin的实现因为MySQL不支持...
MYSQL专题-查询优化-使用索引-安全隐患-事务与锁.docx
11-28
MYSQL专题-查询优化-使用索引-安全隐患-事务与锁 MYSQL专题中最重要的一环节就是查询优化，如何优化数据库查询以提高查询速度和数据库空间利用率变得尤为重要。本文将从多个方面对查询优化进行分析和讲解。 一、...
MySQL——关联查询优化
万里顾一程的博客
03-04 832
文章目录MySQL——关联查询优化1、数据准备2、外连接3、内连接4、小结 MySQL——关联查询优化 1、数据准备 建表 create table if not exists type ( id int(10) unsigned not null auto_increment, card int(10) unsigned not null, primary key (id) ); create table if not exists book ( bookid i
MySQL优化关联查询
学亮编程手记
01-09 328
①确保on或者using自居中的列上有索引，在创建索引的时候就要考虑到关联的顺序。 ②确保任何的group by和order by中的表达式只涉及到一个表中的列，这样MySQL才有可能使用索引来优化这个过程。 ...
mysql数据库sql优化（二）看这里之关联查询优化
qq_39746820的博客
03-30 2253
mysql数据库sql优化看这里之关联查询优化
关联查询和多次查询的点 以及 MySQL慢查询优化 EXPLAIN详解
scofen的博客
04-23 4122
A,B两个表数据规模十几万，数据规模都不大，单机MySQL够用了，在单机的基础上要关联两表的数据，先说一个极端情况，A,B两个表都没有索引，并且关联是笛卡尔积，那关联结果会爆炸式增长，可能到亿级别，这个时候网络IO成了瓶颈，这个时候两次十万行结果集的拉去可能远小于1次亿级别的结果集的拉取，那么将关联合并拉到service层做更快。但实际业务中一般不会有这么蠢的行为，一般关联会有连接条件，并且连接条...
MySQL高级篇——关联查询和子查询优化
最新发布
vincewm的博客
05-22 2836
左外连接：优先右表创建索引，连接字段类型要一致、内连接：驱动表由数据量和索引决定、 join语句原理、子查询优化：拆开查询或优化成连接查询
MySQL索引原理及慢查询优化
12-14
总的来说，优化MySQL的慢查询需要结合索引原理、查询优化技巧、数据库设计和运维实践。通过对业务需求的理解，我们可以制定合适的索引策略，改进SQL语句，从而提升数据库的整体性能，满足高并发、大数据量的业务需求...
mysql 多表关联查询如何改进
洪晓鸿
04-10 4375
在进行多表关联查询时，可以通过使用正确的连接类型、优化 WHERE 子句、为关联字段创建索引、减少查询的字段、考虑使用分布式查询、尽量避免子查询、优化连接顺序、利用 EXPLAIN 分析查询、分解复杂查询和使用视图或存储过程等方法来提高查询性能。
mysql优化（关联查询优化）
qq_1757537040的博客
03-12 2632
1.准备数据 #分类 CREATE TABLE IF NOT EXISTS `class` ( `id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, `card` INT(10) UNSIGNED NOT NULL, PRIMARY KEY (`id`) ); #图书 CREATE TABLE IF NOT EXISTS `book` ( `bookid` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, `card` INT(1
优化MySQL前缀索引
前者已逝，后者未至。
09-13 1万+
文章介绍如何如何创建MySQL前缀索引，以及计算索引的选择性，明确使用前置索引的场景。
MYSQL 多表连接查询优化
热门推荐
No_be_IT_movers的博客
07-12 3万+
本文转自：https://blog.csdn.net/Tim_phper/article/details/78344444概述：交代一下背景，这算是一次项目经验吧，属于公司一个已上线平台的功能，这算是离职人员挖下的坑，随着数据越来越多，原本的SQL查询变得越来越慢，用户体验特别差，因此SQL优化任务交到了我手上。 这个SQL查询关联两个数据表，一个是攻击IP用户表主要是记录IP的信息，如第一次攻击...
MySQL多表关联查询优化
岁月安然
11-28 5722
背景 最近在对运营报表导出进行优化，总结了一些多表关联查询优化的点记录一下。 避免临时表 通过 Explain 分析 SQL 语句，尽量不要使用到临时表。GROUP BY （Explain具体详解，可以看这篇博客） 最容易造成使用临时表，GROUP BY 与临时表的关系 : 　　1. 如果GROUP BY 的列没有索引,产生临时表. 　　2. 如果GROUP BY时,SELECT的列不止GROUP...
关于MySQL 性能优化，你需要知道这些！
鲸鱼的博客
05-07 2243
MySQL 性能优化 文章目录MySQL 性能优化SQL优化理论为什么要优化 SQLSQL 执行过程SQL查询语句的执行过程连接器查询缓存分析器优化器执行器数据库索引什么是索引？索引作用Btree 数据结构索引利弊索引的利索引的弊索引分类主键索引单列索引唯一索引复合索引Navicat for MySQL 操作索引MySQL 创建索引、删除索引、修改索引、查看索引SQL 执行计划查询优化器影响exp...
MySQL笔记：第10章_索引优化与查询优化
IAMLSL的博客
03-19 3204
都有哪些维度可以进行数据库调优?简言之: 索引失效、没有充分利用到索引―索引建立 关联查询太多JOIN（设计缺陷或不得已的需求)――SQL优化 服务器调优及各个参数设置（缓冲、线程数等）――调整my.cnf 数据过多――分库分表 关于数据库调优的知识点非常分散。不同的DBMS，不同的公司，不同的职位，不同的项目遇到的问题都不尽相同。这里我们分为三个章节进行细致讲解。 虽然SQL查询优化的技术有很多，但是大方向上完全可以分成物理查询优化和逻辑查询优化两大块： 物理查询优化是通过索引和表连接方式等技术来进
高性能MySql设计之查询优化
ruan_learning的博客
01-13 479
1.1     处理流程 当MYSQL 收到一条查询请求时，会首先通过关键字对SQL语句进行解析，生成一颗“解析树”，然后预处理器会校验“解析树”是否合法(主要校验数据列和表明是否存在，别名是否有歧义等)，当“解析树”被认为合法后，查询优化器会对这颗“解析树”进行优化，并确定它认为最完美的执行计划。   1.2     衡量标准 MYSQL查询优化器衡量某个执行计划是否完美
mysql关联数组查询_mark---[mysql多表关联查询的优化方法]
weixin_39753616的博客
01-25 657
对于一个网站来说，数据库的结构至关重要。即要利于存储(入库不阻塞)，又要利于查询(查询不锁表)。网站数据库优化经验是一个积累的过程。下面就对多表关联查询的优化方法，举例说明。现在社区分享类网站很火，就拿方维购物分享网站举例说明吧。也是对二次开发方维购物分享网站的一点总结，高手可以飞过。购物分享的关键表有：分享表、图片表、文件表、评论表、标签表、分类表等。围绕分享的表就么多，哇，那也不少啊。当我们查...
mysql多次join同一张表的处理
thunder-1
07-25 5540
场景： 商品表中有不同的商品分类id，一级商品分类id ，二级商品分类id，三级商品分类id 商品分类表中有分类id和分类名称 两张表要多次关联查询获取不同等级的分类名称 如果直接join是不行的，因为分类名称会重名，但是只要给商品分类表起个别名就可以解决这个问题。 select gc.goods_name, c.category_name,c1.category_name,c2.catego...
MySQL查询优化：索引、安全与事务处理
"MYSQL专题-查询优化-使用索引-安全隐患-事务与锁" 在MySQL数据库管理中，优化查询性能是提升系统效率的关键环节。本文件主要探讨了几个关键主题，包括选择合适的数据类型、使用索引、潜在的安全隐患以及事务与锁的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值