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

最新推荐文章于 2024-11-01 21:52:14 发布
最新推荐文章于 2024-11-01 21:52:14 发布
阅读量336 收藏
点赞数
分类专栏： MySQL 文章标签： mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/cheng1877/article/details/126911905
版权

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

4. 子查询优化

MySQL从4.1版本开始支持子查询，使用子查询可以进行SELECT语句的嵌套查询，即一个SELECT查询的结果作为另一个SELECT语句的条件。 子查询可以一次性完成很多逻辑上需要多个步骤才能完成的SQL操作 。

子查询是MySQL的一项重要的功能，可以帮助我们通过一个SQL语句实现比较复杂的查询。但是，子查询的执行效率不高。

原因：

① 执行子查询时，MySQL需要为内层查询语句的查询结果 建立一个临时表 ，然后外层查询语句从临时表中查询记录。查询完毕后，再 撤销这些临时表 。这样会消耗过多的CPU和IO资源，产生大量的慢查询。

② 子查询的结果集存储的临时表，不论是内存临时表还是磁盘临时表都 不会存在索引 ，所以查询性能会受到一定的影响。

③ 对于返回结果集比较大的子查询，其对查询性能的影响也就越大。

在MySQL中，可以使用连接（JOIN）查询来替代子查询。 连接查询 不需要建立临时表 ，其 速度比子查询要快 ，如果查询中使用索引的话，性能就会更好。

举例1：查询学生表中是班长的学生信息

  • 使用子查询
#创建班级表中班长的索引
CREATE INDEX idx_monitor oN class( monitor) ;

#查询班长的信息
EXPLAIN SELECT * FROM student stu1
WHERE stu1.`stuno` IN (
SELECT monitor
FROM class c
WHERE monitor IS NOT NULL
);

在这里插入图片描述

  • 推荐：使用多表查询
EXPLAIN SELECT stu1.* FROM student stu1 JOIN class c
ON stu1.`stuno` = c.`monitor`
WHERE c.`monitor` IS NOT NULL;

在这里插入图片描述
举例2：取所有不为班长的同学。

  • 不推荐
EXPLAIN SELECT SQL_NO_CACHE a.* 
FROM student a
WHERE a.stuno NOT IN(
					SELECT monitor FROM class b
    				WHERE monitor IS NOT NULL);

在这里插入图片描述

  • 推荐
EXPLAIN SELECT SQL_NO_CACHE a.*
FROM student a LEFT OUTER JOIN class b
ON a.stuno = b.monitor
WHERE b .monitor IS NULL;

在这里插入图片描述
子查询：没有索引
在这里插入图片描述
JOIN查询：没有索引
在这里插入图片描述
子查询：只有monitor有索引
在这里插入图片描述
JOIN查询：只有monitor有索引
在这里插入图片描述
子查询：stuno和monitor都有索引
在这里插入图片描述
JOIN查询：stuno和monitor都有索引
在这里插入图片描述

此处两个举例子 实际跑起来时子查询的效率比连表查询效率高，

可能是子查询里也有用到索引且不用回表操作，效率就也比较高，

或者是此处的SQL优化器改写了传入的子查询SQL语句；

这个需要再测试，可能数据量等的影响，还是 以结论为准。

结论：尽量不要使用NOT IN 或者 NOT EXISTS，用LEFT JOlN xx ON x WHERE xx IS NULL替代

5. 排序优化

5.1 排序优化

问题： 在WHERE条件字段上加索引，但是为什么在ORDER BY字段上还要加索引呢?

回答：

在MysQL中，支持两种排序方式，分别是 FileSort 和 Index 排序。

  • Index排序中，索引可以保证数据的有序性，不需要再进行排序，效率更高。
  • FileSort排序则一般在 内存中 进行排序，占用 CPU较多。如果待排结果较大，会产生临时文件I/o到磁盘进行排序的情况，效率较低。

优化建议：

  1. SQL中，可以在WHERE子句和ORDER BY子句中使用索引，目的是在WHERE子句中 避免全表扫描 ，在ORDER BY子句 避免使用FileSort排序 。当然，某些情况下全表扫描，或者FileSort排序不一定比索引慢。但总的来说，我们还是要避免，以提高查询效率。
  2. 尽量使用Index完成ORDER BY排序。如果WHERE和ORDER BY后面是相同的列就使用单索引列;如果不同就使用联合索引。
  3. 无法使用Index时，需要对FileSort方式进行调优。

5.2测试

删除student表和class表中已创建的索引。

#方式1:
DROP INDEX idx_monitor ON class;
DROP INDEX idx_cid ON student;
DROP INDEX idx_age ON student;
DROP INDEX idx_name ON student ;
DROP INDEX idx_age_name_classid ON student;
DROP INDEX idx_age_classid_name ON student;

#方式2:
call proc_drop_index ( 'atguigudb2' , 'student' );
call proc_drop_index ( 'atguigudb2' , 'class' );

以下是否能使用到索引，能否去掉using filesort

过程一:

EXPLAIN SELECT SQL_NO_CACHE * FROM student ORDER BY age,classid;

在这里插入图片描述

EXPLAIN SELECT SQL_NO_CACHE * FROM student ORDER BY age,classid LIMIT 10;

在这里插入图片描述
过程二：order by时不limit，索引失效

#创建索引  
CREATE  INDEX idx_age_classid_name ON student (age,classid,NAME);

#不限制,索引失效,查询的*需要回表
EXPLAIN  SELECT SQL_NO_CACHE * FROM student ORDER BY age,classid;

在这里插入图片描述

#不限制但使用了索引，这个涉及到索引覆盖，查询的字段刚好都在索引上，理解B+Tree
EXPLAIN  SELECT SQL_NO_CACHE age,classid,name,id FROM student ORDER BY age,classid;

在这里插入图片描述

#增加limit过滤条件，使用上索引了。
#虽然查询的*，但是limit 10限制了数据量，最终使用索引固定数据量后再回表的成本就低了
EXPLAIN  SELECT SQL_NO_CACHE * FROM student ORDER BY age,classid LIMIT 10;

在这里插入图片描述
过程三：order by时顺序错误，索引失效

#创建索引age,classid,stuno
CREATE  INDEX idx_age_classid_stuno ON student (age,classid,stuno); 

#失效，不符合最左匹配原则，跳过了age
EXPLAIN  SELECT * FROM student ORDER BY classid LIMIT 10;
#失效，不符合最左匹配原则，跳过了age
EXPLAIN  SELECT * FROM student ORDER BY classid,NAME LIMIT 10; 
#生效，虽然*但是limit有限制数据量
EXPLAIN  SELECT * FROM student ORDER BY age,classid,stuno LIMIT 10;
#生效，虽然*但是limit有限制数据量，优化器选择了idx_age_classid_name
EXPLAIN  SELECT * FROM student ORDER BY age,classid LIMIT 10;
#生效，虽然*但是limit有限制数据量，优化器选择了idx_age_classid_name
EXPLAIN  SELECT * FROM student ORDER BY age LIMIT 10;

如下：

#失效，不符合最左匹配原则，跳过了age
EXPLAIN  SELECT * FROM student ORDER BY classid LIMIT 10;

在这里插入图片描述

#失效，不符合最左匹配原则，跳过了age
EXPLAIN  SELECT * FROM student ORDER BY classid,NAME LIMIT 10;

在这里插入图片描述

#生效，虽然*但是limit有限制数据量
EXPLAIN  SELECT * FROM student ORDER BY age,classid,stuno LIMIT 10;

在这里插入图片描述

#生效，虽然*但是limit有限制数据量，优化器选择了idx_age_classid_name
EXPLAIN  SELECT * FROM student ORDER BY age,classid LIMIT 10;

在这里插入图片描述

#生效，虽然*但是limit有限制数据量，优化器选择了idx_age_classid_name
EXPLAIN  SELECT * FROM student ORDER BY age LIMIT 10;

在这里插入图片描述

过程四：order by时规则不一致, 索引失效 （顺序错，不索引；方向反，不索引）

#失效，age字段DESC和默认的ASC冲突，最左失败
EXPLAIN  SELECT * FROM student ORDER BY age DESC, classid ASC LIMIT 10;
#失效，不符合最左匹配原则，跳过了age
EXPLAIN  SELECT * FROM student ORDER BY classid DESC, NAME DESC LIMIT 10;
#失效，age字段ASC，但是classid字段DESC，不符合索引里都是升序规则，导致索引没法在一个方向上排序
EXPLAIN  SELECT * FROM student ORDER BY age ASC,classid DESC LIMIT 10; 
#生效，虽然索引默认所有字段都是升序排列，但是此处都使用了DESC，索引只需要倒着来就可以了
EXPLAIN  SELECT * FROM student ORDER BY age DESC, classid DESC LIMIT 10;

如下：

#失效，age字段DESC和默认的ASC冲突，最左失败
EXPLAIN  SELECT * FROM student ORDER BY age DESC, classid ASC LIMIT 10;

在这里插入图片描述

#失效，不符合最左匹配原则，跳过了age
EXPLAIN  SELECT * FROM student ORDER BY classid DESC, NAME DESC LIMIT 10;

在这里插入图片描述

#失效，age字段ASC，但是classid字段DESC，不符合索引里都是升序规则，导致索引没法在一个方向上排序
EXPLAIN  SELECT * FROM student ORDER BY age ASC,classid DESC LIMIT 10;

在这里插入图片描述

#生效，虽然索引默认所有字段都是升序排列，但是此处都使用了DESC，索引只需要倒着来就可以了
EXPLAIN  SELECT * FROM student ORDER BY age DESC, classid DESC LIMIT 10;

在这里插入图片描述
过程五：无过滤，不索引

#生效，使用了部分索引，where过滤后剩余数据量不大时，可能会放弃使用后面的索引，因为直接排序可能更快
EXPLAIN  SELECT * FROM student WHERE age=45 ORDER BY classid;
#生效，使用了部分索引，where过滤后剩余数据量不大时，可能会放弃使用后面的索引，因为直接排序可能更快
EXPLAIN  SELECT * FROM student WHERE  age=45 ORDER BY classid,NAME; 
#失效，没有limit限制，要全部数据，不符合最左匹配原则，跳过了age
EXPLAIN  SELECT * FROM student WHERE  classid=45 ORDER BY age;
#生效，全部使用，这个type类型为index，有limit限制，数据量不大了就，使用索引覆盖排序后再回表
EXPLAIN  SELECT * FROM student WHERE  classid=45 ORDER BY age LIMIT 10;

#使用了新创建的索引
CREATE INDEX idx_cid ON student(classid);
EXPLAIN  SELECT * FROM student WHERE  classid=45 ORDER BY age;

如下：

#生效，使用了部分索引，where过滤后剩余数据量不大时，可能会放弃使用后面的索引，因为直接排序可能更快
EXPLAIN  SELECT * FROM student WHERE age=45 ORDER BY classid;

在这里插入图片描述

#生效，使用了部分索引，where过滤后剩余数据量不大时，可能会放弃使用后面的索引，因为直接排序可能更快
EXPLAIN  SELECT * FROM student WHERE  age=45 ORDER BY classid,NAME;

在这里插入图片描述

#失效，没有limit限制，要全部数据，不符合最左匹配原则，跳过了age
EXPLAIN  SELECT * FROM student WHERE  classid=45 ORDER BY age;

在这里插入图片描述

#生效，全部使用，这个type类型为index，有limit限制，数据量不大了就，使用索引覆盖排序后再回表
EXPLAIN  SELECT * FROM student WHERE  classid=45 ORDER BY age LIMIT 10;

在这里插入图片描述

#使用了新创建的索引
CREATE INDEX idx_cid ON student(classid);
EXPLAIN  SELECT * FROM student WHERE  classid=45 ORDER BY age;

在这里插入图片描述
小结：

INDEX a_b_c(a,b,c) 

order by 能使用索引最左前缀
- ORDER BY a
- ORDER BY a,b
- ORDER BY a,b,c
- ORDER BY a DESC,b DESC,c DESC 

如果WHERE使用索引的最左前缀定义为常量，则order by 能使用索引
- WHERE a = const ORDER BY b,c
- WHERE a = const AND b = const ORDER BY c
- WHERE a = const ORDER BY b,c
- WHERE a = const AND b > const ORDER BY b,c 

不能使用索引进行排序
- ORDER BY a ASC,b DESC,c DESC /* 排序不一致 */
- WHERE g = const ORDER BY b,c /*丢失a索引*/
- WHERE a = const ORDER BY c /*丢失b索引*/
- WHERE a = const ORDER BY a,d /*d不是索引的一部分*/
- WHERE a in (...) ORDER BY b,c /*对于排序来说，多个相等条件也是范围查询*/

5.3 案例实战

ORDER BY子句，尽量使用Index方式排序，避免使用FileSort方式排序。

执行案例前先清除student上的索引，只留主键：

DROP INDEX idx_age ON student; 
DROP INDEX idx_age_classid_stuno ON student; 
DROP INDEX idx_age_classid_name ON student; 

#或者 
call proc_drop_index('atguigudb2','student');

场景：查询年龄为30岁的，且学生编号小于101000的学生，按用户名称排序

EXPLAIN SELECT SQL_NO_CACHE * FROM student WHERE age = 30 AND stuno <101000 ORDER BY NAME;

在这里插入图片描述
查询结果如下：

mysql> SELECT SQL_NO_CACHE * FROM student WHERE age = 30 AND stuno <101000 ORDER BY NAME;
+-----+--------+--------+------+---------+
| id  | stuno  | name   | age  | classId |
+-----+--------+--------+------+---------+
| 852 | 100852 | EKMEMY |   30 |      39 |
| 660 | 100660 | fQNtCH |   30 |      49 |
| 297 | 100297 | gyaDTH |   30 |      29 |
| 726 | 100726 | hPDxDx |   30 |     583 |
| 906 | 100906 | KgAjwD |   30 |     223 |
| 519 | 100519 | kOpiVd |   30 |     768 |
| 700 | 100700 | qVJviJ |   30 |     109 |
| 990 | 100990 | rgHQjw |   30 |     703 |
|  71 | 100071 | SlDgZA |   30 |     438 |
| 174 | 100174 | TrafxZ |   30 |     976 |
| 789 | 100789 | tzpboo |   30 |     137 |
| 658 | 100658 | VmAPza |   30 |     922 |
| 433 | 100433 | VXcrBJ |   30 |      81 |
| 853 | 100853 | wcWBRJ |   30 |      63 |
| 816 | 100816 | yBnJJe |   30 |     668 |
| 598 | 100598 | ZjZtTm |   30 |     216 |
+-----+--------+--------+------+---------+
16 rows in set, 1 warning (0.11 sec)

结论: type是ALL，即最坏的情况。Extra里还出现了Using filesort,也是最坏的情况。优化是必须的。

优化思路:
方案一:为了去掉filesort我们可以把索引建成

CREATE INDEX idx_age_name ON student(age,NAME);

EXPLAIN SELECT SQL_NO_CACHE * FROM student WHERE age = 30 AND stuno <101000 ORDER BY NAME ;

在这里插入图片描述
这样我们优化掉了using filesort。

查询结果如下:

mysql> SELECT SQL_NO_CACHE * FROM student WHERE age = 30 AND stuno <101000 ORDER BY NAME ;
+-----+--------+--------+------+---------+
| id  | stuno  | name   | age  | classId |
+-----+--------+--------+------+---------+
| 852 | 100852 | EKMEMY |   30 |      39 |
| 660 | 100660 | fQNtCH |   30 |      49 |
| 297 | 100297 | gyaDTH |   30 |      29 |
| 726 | 100726 | hPDxDx |   30 |     583 |
| 906 | 100906 | KgAjwD |   30 |     223 |
| 519 | 100519 | kOpiVd |   30 |     768 |
| 700 | 100700 | qVJviJ |   30 |     109 |
| 990 | 100990 | rgHQjw |   30 |     703 |
|  71 | 100071 | SlDgZA |   30 |     438 |
| 174 | 100174 | TrafxZ |   30 |     976 |
| 789 | 100789 | tzpboo |   30 |     137 |
| 658 | 100658 | VmAPza |   30 |     922 |
| 433 | 100433 | VXcrBJ |   30 |      81 |
| 853 | 100853 | wcWBRJ |   30 |      63 |
| 816 | 100816 | yBnJJe |   30 |     668 |
| 598 | 100598 | ZjZtTm |   30 |     216 |
+-----+--------+--------+------+---------+
16 rows in set, 1 warning (0.03 sec)

方案二：尽量让where的过滤条件和排序使用上索引

#建一个三个字段的组合索引
CREATE INDEX idx_age_stuno_name ON student(age,stuno,NAME);

EXPLAIN SELECT SQL_NO_CACHE * FROM student WHERE age = 30 AND stuno <101000 ORDER BY NAME ;

在这里插入图片描述
我们发现using filesort 依然存在，所以name并没有用到索引，而且type还是range光看字面其实并不美好。原因是，因为 stuno是一个范围过滤，所以索引后面的字段不会再使用索引了。
运行结果:

mysql> SELECT SQL_NO_CACHE * FROM student WHERE age = 30 AND stuno <101000 ORDER BY NAME ;
+-----+--------+--------+------+---------+
| id  | stuno  | name   | age  | classId |
+-----+--------+--------+------+---------+
| 852 | 100852 | EKMEMY |   30 |      39 |
| 660 | 100660 | fQNtCH |   30 |      49 |
| 297 | 100297 | gyaDTH |   30 |      29 |
| 726 | 100726 | hPDxDx |   30 |     583 |
| 906 | 100906 | KgAjwD |   30 |     223 |
| 519 | 100519 | kOpiVd |   30 |     768 |
| 700 | 100700 | qVJviJ |   30 |     109 |
| 990 | 100990 | rgHQjw |   30 |     703 |
|  71 | 100071 | SlDgZA |   30 |     438 |
| 174 | 100174 | TrafxZ |   30 |     976 |
| 789 | 100789 | tzpboo |   30 |     137 |
| 658 | 100658 | VmAPza |   30 |     922 |
| 433 | 100433 | VXcrBJ |   30 |      81 |
| 853 | 100853 | wcWBRJ |   30 |      63 |
| 816 | 100816 | yBnJJe |   30 |     668 |
| 598 | 100598 | ZjZtTm |   30 |     216 |
+-----+--------+--------+------+---------+
16 rows in set, 1 warning (0.00 sec)

结果竟然有filesort的 sql运行速度，超过了已经优化掉 filesort的 sql，而且快了很多，几乎一瞬间就出现了结果。
原因:
所有的排序都是在条件过滤之后才执行的。所以，如果条件过滤掉大部分数据的话，剩下几百几千条数据进行排序其实并不是很消耗性能，即使索引优化了排序，但实际提升性能很有限。相对的stuno<101000这个条件，如果没有用到索引的话，要对几万条的数据进行扫描，这是非常消耗性能的，所以索引放在这个字段上性价比最高，是最优选择。

结论:

  1. 两个索引同时存在，mysql自动选择最优的方案。(对于这个例子，mysql选择idx_age_stuno_name)。但是，随着数据量的变化，选择的索引也会随之变化的。

  2. 当【范围条件】和【group by或者order by】的字段出现二选一时，优先观察条件字段的过滤数量，如果过滤的数据足够多，而需要排序的数据并不多时，优先把索引放在范围字段上。反之，亦然。

思考：

#删除索引
DROP INDEX idx_age_stuno_name ON student;
#创建索引
CREATE INDEX idx_age_stuno ON student(age,stuno);
#可以正常使用到索引idx_age_stuno
EXPLAIN SELECT SQL_NO_CACHE * FROM student WHERE age = 30 AND stuno <101000 ORDER BY NAME ;

在这里插入图片描述

5.4 filesort算法:双路排序和单路排序

排序的字段若如果不在索引列上，则filesort会有两种算法: 双路排序和单路排序

双路排序（慢)

  • MySQL 4.1之前是使用双路排序，字面意思就是两次扫描磁盘，最终得到数据，读取行指针和 order by列 ，对他们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读取对应的数据输出
  • 从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。

取一批数据，要对磁盘进行两次扫描，众所周知，lO是很耗时的，所以在mysql4.1之后，出现了第二种改进的算法，就是单路排序。

单路排序(快)
从磁盘读取查询需要的 所有列 ，按照order by列在buffer对它们进行排序，然后扫描排序后的列表进行输出，它的效率更快一些，避免了第二次读取数据。并且把随机IO变成了顺序IO，但是它会使用更多的空间，因为它把每一行都保存在内存中了。

结论及引申出的问题

  • 由于单路是后出的，总体而言好过双路。
  • 但是用单路有问题
    • 在sort_buffer中，单路比多路要 多占用很多空间，因为单路是把所有字段都取出,所以有可能取出的数据的总大小超出了sort_buffer的容量，导致每次只能取sort_buffer容量大小的数据，进行排序(创建tmp文件，多路合并)，排完再取sort_buffer容量大小，再排…从而多次l/O。
    • 单路本来想省一次I/O操作，反而导致了大量的I/O操作，反而得不偿失。

优化策略
1. 尝试提高sort_buffer_size

  • 不管用哪种算法，提高这个参数都会提高效率，要根据系统的能力去提高，因为这个参数是针对每个进程(connection)的1M-8M之间调整。MySQL5.7，InnoDB存储引擎默认值是1048576字节，1MB。
SHOW VARIABLES LIKE '%sort_buffer_size%';

mysql> SHOW VARIABLES LIKE '%sort_buffer_size%';
+-------------------------+---------+
| Variable_name           | Value   |
+-------------------------+---------+
| innodb_sort_buffer_size | 1048576 |
| myisam_sort_buffer_size | 8388608 |
| sort_buffer_size        | 262144  |
+-------------------------+---------+
3 rows in set (0.00 sec)

2. 尝试提高max_length_for_sort_data

  • 提高这个参数，会增加用改进算法的概率。
#默认1024字节
SHOW VARIABLES LIKE '%max_length_for_sort_data%';

mysql> SHOW VARIABLES LIKE '%max_length_for_sort_data%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| max_length_for_sort_data | 4096  |
+--------------------------+-------+
1 row in set (0.00 sec)
  • 但是如果设的太高，数据总容量超出sort_buffer_size的概率就增大，明显症状是高的磁盘I/O活动和低的处理器使用率。如果需要返回的列的总长度大于max_length_for_sort_data，使用双路算法，否则使用单路算法。1024-8192字节之间调整

3. Order by时select*是一个大忌。最好只Query需要的字段。

原因:

  • 当Query的字段大小总和小于 max_length_for_sort_data ，而且排序字段不是TEXT|BLOB类型时，会用改进后的算法 单路排序，否则用老算法 多路排序。
  • 两种算法的数据都有可能超出sort_buffer_size的容量，超出之后，会创建tmp文件进行合并排序，导致多次I/O，但是用单路排序算法的风险会更大一些，所以要 提高sort_buffer_size。
cheng7736
关注
专栏目录
后端程序员必备：攻克order by
weixin_57907028的博客
06-15 3164
前言 日常开发中，我们经常会使用到order by，亲爱的小伙伴，你是否知道order by 的工作原理呢？order by的优化思路是怎样的呢？使用order by有哪些注意的问题呢？本文将跟大家一起来学习，攻克order by~ 一个使用order by 的简单例子 假设用一张员工表，表结构如下： CREATE TABLE `staff` ( `id` BIGINT ( 11 ) AUTO_INCREMENT COMMENT '主键id', `id_card` VARCHAR ( 20 ) NOT N
04-VIP-Mysql索引优化实战一.pdf
11-30
总之，MySQL索引优化涉及到对查询语句的理解、索引设计的合理性以及根据数据量和查询模式选择合适的索引使用策略。在实际应用中，应结合`EXPLAIN`分析、性能测试和业务需求来调整索引和查询方式，以达到最佳的数据库...
Mysql索引优化详细教程
qq_51867867的博客
08-07 341
mysql索引优化和存储引擎讲解
MySQL查询优化之order by 、 group by与分页查询优化
小小默：进无止境
09-07 3449
order by 子句尽量使用index方式排序(即using index)，避免使用filesort方式排序(即using filesort)。Index方式效率高，它指MySQL扫描索引本身完成排序，filesort则效率低。 **order by满足两种情况，会使用 index 方式排序：** * order by语句使用索引最左前列(最左匹配法则) * where子句和order by子句条件列组合满足最左匹配法则 下面给出几个实例来说明，如下所示我们创建表并为其创建组合索引(c1,c2,c3)
5.mysql调优--mysql查询优化分析（1节）
weixin_43381245的博客
08-09 276
mysql优化
MySQL-索引优化/查询优化
萌萌虎的博客
07-04 1268
对于多列索引，过滤条件想使用索引就必须按照索引建立时的顺序依次满足，一旦跳过某个字段，索引后面的字段都无法使用。 假如索引中定义的是id，name，age，那查询时条件必须严格按照 id，name，age 的顺序。 对于添加了索引的字段，最好不要包括在函数内，或有其他计算、转换行为。 由于name字段是范围条件，所以它后面的字段都失效了。我们开发时要把条件字段放在最后。 1.5 like以通配符%开头导致索引失效 1.6 OR 前后存在非索引的列，索引失效
MySQL索引性能优化分析
热门推荐
张彦峰的博客
04-07 173万+
总结MySQL索引性能优化，主要集中在索引的背景介绍以及索引的高效创建、使用和查询等，最有给出除了索引的一些其他优化思路
MySQL索引系列--索引的优化--LIKE模糊查询
IT利刃出鞘的博客
02-08 8833
本文介绍MySQL的LIKE模糊查询索引的优化。主要是索引失效的解决方案。
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面试题-mysql经典面试题目-数据库的基本概念-SQL语法-事务处理-索引优化-性能调优-mysql-面试题目
01-20
【MySQL面试题】在面试MySQL相关的职位时，面试官可能会问到一系列关于数据库基础、SQL语法、事务处理、索引优化以及性能调优的问题。以下是一些可能的面试重点： 1. **数据库基本概念**： - 数据库是用于存储和...
MySQL之优化器追踪命令
mutou0312的博客
01-13 452
show variables like '%tmp_table_size%'; show variables like '%sort_buffer_size%'; show variables like '%max_length_for_sort_data%'; set tmp_table_size=16777216; set sort_buffer_size=262144; set max_length_for_sort_data=4096; set tmp_table_size=1024; set
mysql max datalength,mysql 排序长度限制之max_length_for_sort_data以及mysql两种排序算法...
weixin_33451125的博客
03-17 393
SET max_length_for_sort_data = 1024SHOW VARIABLES LIKE '%max_length_for_sort_data%';查询：SELECT * FROM CS_COLUMNS ORDER BY table_name,column_name LIMIT 0,100错误代码： 1815Internal error: IDB-2015: Sorting l...
mysql到doris的DDL整库转换工具
fengjian的博客
11-01 338
适用于常规的mysql-ddl到doris-ddl的整库转换，附全部代码
【Linux】MySQLMGR主从复制
Stringzhua的博客
10-30 754
MySQL是⽬前最流⾏的开源关系型数据库，国内⾦融⾏业也开始全⾯使⽤，其中MySQL5.7.17提出的 MGR(MySQL Group Replication)既可以很好的保证数据⼀致性⼜可以⾃动切换，具备故障检测功能、 ⽀持多节点写⼊，MGR是⼀项被普遍看好的技术。MGR(MySQL Group Replication)是MVSQL⾃带的⼀个插件，可以灵活部署。
Windows 命令提示符（cmd）中输入 mysql 并收到错误消息“MySQL不是内部或外部命令，也不是可运行的程序或批处理文件？
weixin_59272777的博客
11-01 282
属性描述名称PATH环境变量定义可执行文件搜索路径列表作用让系统快速找到并运行程序使用输入命令名（无需完整路径）分隔符Windows用;，Linux/macOS用配置编辑系统或用户环境变量设置。
【MySql】第五章（存储函数与存储过程）习题
她是不会无条件的！！
11-01 333
【MySql】第五章（存储函数与存储过程）习题
MySQL常用sql语句
yangyang3401的博客
10-29 258
mysql基本操作
Java项目实战II基于Java+Spring Boot+MySQL的植物健康系统（开发文档+数据库+源码）
最新发布
2401_86524610的博客
11-01 551
基于Java、Spring Boot和MySQL的植物健康系统，是信息技术在农业管理领域的一次重要应用。随着现代农业的发展，植物健康管理已成为农业生产中不可或缺的一环。然而，传统的植物健康管理方式存在诸多不足，如信息记录不完整、管理效率低下等。为解决这些问题，我们设计并实现了基于Java、Spring Boot和MySQL的植物健康系统。该系统利用Spring Boot框架的简洁性和高效性，结合MySQL数据库的强大数据管理能力，为植物健康管理提供了一个全面、可靠的信息平台。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值