Mysql优化——索引优化实践

最新推荐文章于 2023-08-20 20:42:11 发布
最新推荐文章于 2023-08-20 20:42:11 发布
阅读量230 收藏 1
点赞数
分类专栏： Java学习之路 # java学习之路——mysql 文章标签： mysql 数据库 sql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/sinat_24044957/article/details/119652838
版权

索引最佳实践

示例表：
CREATE TABLE `employees` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名',
  `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',
  `position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位',
  `hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间',
  PRIMARY KEY (`id`),
  KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COMMENT='员工记录表';

INSERT INTO employees(name,age,position,hire_time) VALUES('LiLei',22,'manager',NOW());
INSERT INTO employees(name,age,position,hire_time) VALUES('HanMeimei', 23,'dev',NOW());
INSERT INTO employees(name,age,position,hire_time) VALUES('Lucy',23,'dev',NOW());

备注：索引总长度（3 *24+2）+ 4 + （3 *20+2）= 140

1.全值匹配

EXPLAIN SELECT * FROM employees WHERE name= 'LiLei';

在这里插入图片描述
EXPLAIN 结果解析：
1）key_len为74：表示索引只用到了name字段。
2）ref为const：走了索引并且是等于判断相当于是找常量

EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22;

在这里插入图片描述
EXPLAIN 结果解析：
1）key_len为78：表示索引只用到了name和age字段
2）ref为const,const：走了索引并且是等于判断相当于是找常量

EXPLAIN SELECT * FROM employees WHERE  name= 'LiLei' AND  age = 22 AND position ='manager';

在这里插入图片描述

2.最左前缀法则

如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。

EXPLAIN SELECT * FROM employees WHERE name = 'Bill' and age = 31;
EXPLAIN SELECT * FROM employees WHERE age = 30 AND position = 'dev';
EXPLAIN SELECT * FROM employees WHERE position = 'manager';

在这里插入图片描述

3.不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描

EXPLAIN SELECT * FROM employees WHERE name = 'LiLei';
EXPLAIN SELECT * FROM employees WHERE left(name,3) = 'LiLei';

在这里插入图片描述

给hire_time增加一个普通索引：

ALTER TABLE `employees` ADD INDEX `idx_hire_time` (`hire_time`) USING BTREE ;
EXPLAIN  select * from employees where date(hire_time) ='2018-09-30';

在这里插入图片描述

转化为日期范围查询，有可能会走索引：

EXPLAIN  select * from employees where hire_time >='2018-09-30 00:00:00'  and  hire_time <='2018-09-30 23:59:59';

在这里插入图片描述
还原最初索引状态

ALTER TABLE `employees` DROP INDEX `idx_hire_time`;

4.存储引擎不能使用索引中范围条件右边的列

EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22 AND position ='manager';
EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age > 22 AND position ='manager';

在这里插入图片描述
EXPLAIN 结果解析：
1）key_len为78：表示索引只用到了name和age字段

5.尽量使用覆盖索引（只访问索引的查询（索引列包含查询列）），减少 select * 语句

EXPLAIN SELECT name,age FROM employees WHERE name= 'LiLei' AND age = 23 AND position ='manager';

在这里插入图片描述
EXPLAIN 结果解析：
1）key_len为140：表示索引用到全部字段

EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 23 AND position ='manager';

在这里插入图片描述

6.mysql在使用不等于（！=或者<>），not in ，not exists 的时候无法使用索引会导致全表扫描< 小于、 > 大于、 <=、>= 这些，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引

EXPLAIN SELECT * FROM employees WHERE name != 'LiLei';

在这里插入图片描述

7.is null,is not null 一般情况下也无法使用索引

EXPLAIN SELECT * FROM employees WHERE name is null

在这里插入图片描述

8.like以通配符开头（’$abc…’）mysql索引失效会变成全表扫描操作

EXPLAIN SELECT * FROM employees WHERE name like '%Lei'

在这里插入图片描述

EXPLAIN SELECT * FROM employees WHERE name like 'Lei%'

在这里插入图片描述

问题：解决like’%字符串%'索引不被使用的方法？
a）使用覆盖索引，查询字段必须是建立覆盖索引字段

EXPLAIN SELECT name,age,position FROM employees WHERE name like '%Lei%';

在这里插入图片描述

b）如果不能使用覆盖索引则可能需要借助搜索引擎

9.字符串不加单引号索引失效

EXPLAIN SELECT * FROM employees WHERE name = '1000';
EXPLAIN SELECT * FROM employees WHERE name = 1000;

在这里插入图片描述

10.少用or或in，用它查询时，mysql不一定使用索引，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引，详见范围查询优化

EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' or name = 'HanMeimei';

在这里插入图片描述

11.范围查询优化

给年龄添加单值索引

ALTER TABLE `employees` ADD INDEX `idx_age` (`age`) USING BTREE ;
explain select * from employees where age >=1 and age <=2000;

在这里插入图片描述

没走索引原因：mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引。比如这个例子，可能是由于单次数据量查询过大导致优化器最终选择不走索引
优化方法：可以将大的范围拆分成多个小范围

explain select * from employees where age >=1 and age <=1000;
explain select * from employees where age >=1001 and age <=2000;

在这里插入图片描述

还原最初索引状态

ALTER TABLE `employees` DROP INDEX `idx_age`;

索引使用总结：

在这里插入图片描述
like KK%相当于=常量，%KK和%KK% 相当于范围

-- mysql5.7关闭ONLY_FULL_GROUP_BY报错
select version(), @@sql_mode;SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));

分页查询优化

示例表：
CREATE TABLE `employees` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名',
  `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',
  `position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位',
  `hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间',
  PRIMARY KEY (`id`),
  KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='员工记录表';

很多时候我们业务系统实现分页功能可能会用如下sql实现

mysql> select * from employees limit 10000,10;

表示从表 employees 中取出从 10001 行开始的 10 行记录。看似只查询了 10 条记录，实际这条 SQL 是先读取 10010 条记录，然后抛弃前 10000 条记录，然后读到后面 10 条想要的数据。因此要查询一张大表比较靠后的数据，执行效率是非常低的。

常见的分页场景优化技巧：

1、根据自增且连续的主键排序的分页查询

首先来看一个根据自增且连续主键排序的分页查询的例子：

mysql> select * from employees limit 90000,5;

在这里插入图片描述

该 SQL 表示查询从第 90001开始的五行数据，没添加单独 order by，表示通过主键排序。我们再看表 employees ，因为主键是自增并且连续的，所以可以改写成按照主键去查询从第 90001开始的五行数据，如下：

mysql> select * from employees where id > 90000 limit 5;

查询的结果是一致的。我们再对比一下执行计划：

mysql> EXPLAIN select * from employees limit 90000,5;

在这里插入图片描述

mysql> EXPLAIN select * from employees where id > 90000 limit 5;

在这里插入图片描述

显然改写后的 SQL 走了索引，而且扫描的行数大大减少，执行效率更高。
但是，这条改写的SQL 在很多场景并不实用，因为表中可能某些记录被删后，主键空缺，导致结果不一致，如下图试验所示（先删除一条前面的记录，然后再测试原 SQL 和优化后的 SQL）：

在这里插入图片描述
在这里插入图片描述

两条 SQL 的结果并不一样，因此，如果主键不连续，不能使用上面描述的优化方法。
另外如果原 SQL 是 order by 非主键的字段，按照上面说的方法改写会导致两条 SQL 的结果不一致。所以这种改写得满足以下两个条件：

  • 主键自增且连续
  • 结果是按照主键排序的

2、根据非主键字段排序的分页查询

再看一个根据非主键字段排序的分页查询，SQL 如下：

mysql>  select * from employees ORDER BY name limit 90000,5;

在这里插入图片描述

mysql> EXPLAIN select * from employees ORDER BY name limit 90000,5;

在这里插入图片描述

发现并没有使用 name 字段的索引（key 字段对应的值为 null），具体原因mysql需要先通过索引找出前面90000条记录并且回表获取完整记录后再返回最后5条，回表数据量过大导致成本更高，所以优化器放弃使用索引。
知道不走索引的原因，那么怎么优化呢？
其实关键是让排序时返回的字段尽可能少（只返回主键不用回表），所以可以让排序和分页操作先查出主键，然后根据主键查到对应的记录，SQL改写如下

mysql> select * from employees e inner join (select id from employees order by name limit 90000,5) ed on e.id = ed.id;

需要的结果与原 SQL 一致，执行时间减少了一半以上，我们再对比优化前后sql的执行计划：

原 SQL 使用的是 filesort 排序，而优化后的 SQL 使用的是索引排序。

Join关联查询优化

-- 示例表：
CREATE TABLE `t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

create table t2 like t1;

-- 插入一些示例数据
-- 往t1表插入1万行记录
drop procedure if exists insert_t1; 
delimiter ;;
create procedure insert_t1()        
begin
  declare i int;                    
  set i=1;                          
  while(i<=10000)do                 
    insert into t1(a,b) values(i,i);  
    set i=i+1;                       
  end while;
end;;
delimiter ;
call insert_t1();

-- 往t2表插入100行记录
drop procedure if exists insert_t2; 
delimiter ;;
create procedure insert_t2()        
begin
  declare i int;                    
  set i=1;                          
  while(i<=100)do                 
    insert into t2(a,b) values(i,i);  
    set i=i+1;                       
  end while;
end;;
delimiter ;
call insert_t2();

mysql的表关联常见有两种算法

  • Nested-Loop Join 算法
  • Block Nested-Loop Join 算法
1、 嵌套循环连接 Nested-Loop Join(NLJ) 算法

一次一行循环地从第一张表（称为驱动表）中读取行，在这行数据中取到关联字段，根据关联字段在另一张表（被驱动表）里取出满足条件的行，然后取出两张表的结果合集。

mysql> EXPLAIN select * from t1 inner join t2 on t1.a= t2.a;

在这里插入图片描述

从执行计划中可以看到这些信息：

  • 驱动表是 t2，被驱动表是 t1。先执行的就是驱动表(执行计划结果的id如果一样则按从上到下顺序执行sql)；优化器一般会优先选择小表做驱动表，用where条件过滤完驱动表，然后再跟被驱动表做关联查询。所以使用 inner join 时，排在前面的表并不一定就是驱动表。
  • 当使用left join时，左表是驱动表，右表是被驱动表，当使用right join时，右表时驱动表，左表是被驱动表，当使用join时，mysql会选择数据量比较小的表作为驱动表，大表作为被驱动表。
  • 使用了 NLJ算法。一般 join 语句中，如果执行计划 Extra 中未出现 Using join buffer 则表示使用的 join 算法是 NLJ。
    上面sql的大致流程如下：
  1. 从表 t2 中读取一行数据（如果t2表有查询过滤条件的，用先用条件过滤完，再从过滤结果里取出一行数据）；
  2. 从第 1 步的数据中，取出关联字段 a，到表 t1 中查找；
  3. 取出表 t1 中满足条件的行，跟 t2 中获取到的结果合并，作为结果返回给客户端；
  4. 重复上面 3 步。
    整个过程会读取 t2 表的所有数据(扫描100行)，然后遍历这每行数据中字段 a 的值，根据 t2 表中 a 的值索引扫描 t1 表中的对应行(扫描100次 t1 表的索引，1次扫描可以认为最终只扫描 t1 表一行完整数据，也就是总共 t1 表也扫描了100行)。因此整个过程扫描了 200 行。
    如果被驱动表的关联字段没索引，使用NLJ算法性能会比较低(下面有详细解释)，mysql会选择Block Nested-Loop Join算法。
2、 基于块的嵌套循环连接 Block Nested-Loop Join(BNL)算法

把驱动表的数据读入到 join_buffer 中，然后扫描被驱动表，把被驱动表每一行取出来跟 join_buffer 中的数据做对比。

mysql>EXPLAIN select * from t1 inner join t2 on t1.b= t2.b;

在这里插入图片描述

Extra 中 的Using join buffer (Block Nested Loop)说明该关联查询使用的是 BNL 算法。
上面sql的大致流程如下：

  1. 把 t2 的所有数据放入到 join_buffer 中
  2. 把表 t1 中每一行取出来，跟 join_buffer 中的数据做对比
  3. 返回满足 join 条件的数据
    整个过程对表 t1 和 t2 都做了一次全表扫描，因此扫描的总行数为10000(表 t1 的数据总量) + 100(表 t2 的数据总量) = 10100。并且 join_buffer 里的数据是无序的，因此对表 t1 中的每一行，都要做 100 次判断，所以内存中的判断次数是 100 * 10000= 100 万次。
    这个例子里表 t2 才 100 行，要是表 t2 是一个大表，join_buffer 放不下怎么办呢？·
    join_buffer 的大小是由参数 join_buffer_size 设定的，默认值是 256k。如果放不下表 t2 的所有数据话，策略很简单，就是分段放。
    比如 t2 表有1000行记录， join_buffer 一次只能放800行数据，那么执行过程就是先往 join_buffer 里放800行记录，然后从 t1 表里取数据跟 join_buffer 中数据对比得到部分结果，然后清空 join_buffer ，再放入 t2 表剩余200行记录，再次从 t1 表里取数据跟 join_buffer 中数据对比。所以就多扫了一次 t1 表。

被驱动表的关联字段没索引为什么要选择使用 BNL 算法而不使用 Nested-Loop Join 呢？
如果上面第二条sql使用 Nested-Loop Join，那么扫描行数为 100 * 10000 = 100万次，这个是磁盘扫描。
很显然，用BNL磁盘扫描次数少很多，相比于磁盘扫描，BNL的内存计算会快得多。
因此MySQL对于被驱动表的关联字段没索引的关联查询，一般都会使用 BNL 算法。如果有索引一般选择 NLJ 算法，有索引的情况下 NLJ 算法比 BNL算法性能更高

对于关联sql的优化
  • 关联字段加索引，让mysql做join操作时尽量选择NLJ算法，驱动表因为需要全部查询出来，所以过滤的条件也尽量要走索引，避免全表扫描，总之，能走索引的过滤 条件尽量都走索引
  • 小表驱动大表，写多表连接sql时如果明确知道哪张表是小表可以用straight_join写法固定连接驱动方式，省去mysql优化器自己判断的时间

straight_join解释：straight_join功能同join类似，但能让左边的表来驱动右边的表，能改表优化器对于联表查询的执行顺序。
比如：select * from t2 straight_join t1 on t2.a = t1.a; 代表指定mysql选着 t2 表作为驱动表。

  • straight_join只适用于inner join，并不适用于left join，right join。（因为left join，right join已经代表指定了表的执行顺序）
  • 尽可能让优化器去判断，因为大部分情况下mysql优化器是比人要聪明的。使用straight_join一定要慎重，因为部分情况下人为指定的执行顺序并不一定会比优化引擎要靠谱。

对于小表定义的明确
在决定哪个表做驱动表的时候，应该是两个表按照各自的条件过滤，过滤完成之后，计算参与 join 的各个字段的总数据量，数据量小的那个表，就是“小表”，应该作为驱动表。

in和exsits优化
原则：小表驱动大表，即小的数据集驱动大的数据集
in：当B表的数据集小于A表的数据集时，in优于exists

select * from A where id in (select id from B)  
#等价于：
　　for(select id from B){
      select * from A where A.id = B.id
    }

exists：当A表的数据集小于B表的数据集时，exists优于in
　　将主查询A的数据，放到子查询B中做条件验证，根据验证结果（true或false）来决定主查询的数据是否保留

select * from A where exists (select 1 from B where B.id = A.id)
#等价于:
    for(select * from A){
      select * from B where B.id = A.id
    }
    
#A表与B表的ID字段应建立索引

1、EXISTS (subquery)只返回TRUE或FALSE,因此子查询中的SELECT * 也可以用SELECT 1替换,官方说法是实际执行时会忽略SELECT清单,因此没有区别
2、EXISTS子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比
3、EXISTS子查询往往也可以用JOIN来代替，何种最优需要具体问题具体分析

count(*)查询优化

-- 临时关闭mysql查询缓存，为了查看sql多次执行的真实时间
mysql> set global query_cache_size=0;
mysql> set global query_cache_type=0;

mysql> EXPLAIN select count(1) from employees;
mysql> EXPLAIN select count(id) from employees;
mysql> EXPLAIN select count(name) from employees;
mysql> EXPLAIN select count(*) from employees;

注意：以上4条sql只有根据某个字段count不会统计字段为null值的数据行
在这里插入图片描述

四个sql的执行计划一样，说明这四个sql执行效率应该差不多
字段有索引：count()≈count(1)>count(字段)>count(主键 id) //字段有索引，count(字段)统计走二级索引，二级索引存储数据比主键索引少，所以count(字段)>count(主键 id)
字段无索引：count()≈count(1)>count(主键 id)>count(字段) //字段没有索引count(字段)统计走不了索引，count(主键 id)还可以走主键索引，所以count(主键 id)>count(字段)
count(1)跟count(字段)执行过程类似，不过count(1)不需要取出字段统计，就用常量1做统计，count(字段)还需要取出字段，所以理论上count(1)比count(字段)会快一点。
count() 是例外，mysql并不会把全部字段取出来，而是专门做了优化，不取值，按行累加，效率很高，所以不需要用count(列名)或count(常量)来替代 count()。
为什么对于count(id)，mysql最终选择辅助索引而不是主键聚集索引？因为二级索引相对主键索引存储数据更少，检索性能应该更高，mysql内部做了点优化(应该是在5.7版本才优化)。

常见优化方法

1、查询mysql自己维护的总行数

对于myisam存储引擎的表做不带where条件的count查询性能是很高的，因为myisam存储引擎的表的总行数会被mysql存储在磁盘上，查询不需要计算
在这里插入图片描述

对于innodb存储引擎的表mysql不会存储表的总记录行数(因为有MVCC机制，后面会讲)，查询count需要实时计算

2、show table status

如果只需要知道表总行数的估计值可以用如下sql查询，性能很高
在这里插入图片描述

3、将总数维护到Redis里

插入或删除表数据行的时候同时维护redis里的表总行数key的计数值(用incr或decr命令)，但是这种方式可能不准，很难保证表操作和redis操作的事务一致性

4、增加数据库计数表

插入或删除表数据行的时候同时维护计数表，让他们在同一个事务里操作

HJHxHJH
关注
专栏目录
MYSQL——索引设计原则
庄小焱
12-28 1503
之前优化器选择使用索引 b，是因为它认为使用索引 b 可以避免排序（b 本身是索引，已经是有序的了，如果选择索引 b 的话，不需要再做排序，只需要遍历），所以即使扫描行数多，也判定为代价更小。但是，对于这个查询语句来说，如果你定义的 index2 不是 email(6) 而是 email(7），也就是说取 email 字段的前 7 个字节来构建索引的话，即满足前缀’zhangss’的记录只有一个，也能够直接查到 ID2，只扫描一行就结束了。其中，Q1 的结果还是符合预期的，rows 的值是 104620；
掌握MySQL索引：策略与最佳实践——索引使用（三）
最新发布
zhangruibo_code的博客
08-07 893
表中存在联合索引 idx_user_pro_age_sta (关联了三个字段profession, age, status)，该索引也是一个二级索引，该叶子节点下面的是这一行的主键id。虽然是根据name字段查询，查询二级索引，但是由于查询返回在字段为 id，name，在name的二级索 引中，这两个值都是可以直接获取到的，因为覆盖索引，所以不需要回表查询，性能高。由于在name的二级索引中，不包含gender，所以，需要两次索引扫描，也就是需要回表查询，性能相对较差一点。
复习mysql + 高级
xiongmaogaizi的博客
06-17 994
MySql高级 MySQL是一个关系型数据库管理系统，由瑞典MySQL AB公司开发，目前属于Oracle公司。MySQL是一种关联数据库管理系统，将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。 Mysql是开源的，所以你不需要支付额外的费用。Mysql是可以定制的，采用了GPL协议，你可以修改源码来开发自己的Mysql系统。Mysql支持大型的数据库。可以处理拥有上千万条记录的大型数据库。MySQL使用标准的SQL数据语言形式。Mysql可以允许于多个系.
mysql查询语句的访问方法const、ref、ref_or_null、range、index、all
知道的越多 不知道的就越多
01-06 3535
下面我们来看一个下mysql都有哪些访问方法，以及他们各自的执行效率
mysql中explain的字段含义
iaoyou1的博客
08-20 1281
具体解释如下： - 如果连接操作是通过唯一索引或主键进行的，ref字段将显示连接所使用的索引列。- 如果连接操作是通过非唯一索引进行的，ref字段将显示连接所使用的索引列以及其他列，用于进一步筛选结果。它提供了关于连接操作所使用的条件的信息，帮助我们理解查询的执行计划和优化查询性能。这意味着查询的过滤条件非常严格，所有的行都符合条件，没有需要被排除或过滤的行。当filtered字段显示为其他小于100的值时，表示有部分行被过滤掉，只有一部分行符合查询的过滤条件。查询的标识符，表示查询的顺序。
MySQL的优化（例子讲解）
qq_40368860的博客
11-05 149
首先创建一张测试表用于测试使用： CREATE TABLE `test` (   `id` int(11) NOT NULL AUTO_INCREMENT,   `c1` varchar(10) DEFAULT NULL,   `c2` varchar(10) DEFAULT NULL,   `c3` varchar(10) DEFAULT NULL,   `c4`...
mysql 索引学习日志
IT_Octopus的博客
09-18 496
话不多说，先放代码（其实是知识点没学完，不想整理，狗头保命） 下列都是索引的基本操作，像那些查看所有删除所有的骚操作一般不要搞 --从选中表中查询所有索引（包括自动生成的主键索引） show INDEX from book -- 像选中表中的选定字段添加索引,可以创建覆盖索引 --下面两个随你选，你开心就好 alter table book ADD INDEX Y(card,name) create index index_name on book(card) --还有你如果想加字符符号一定是“ ` ”而
mysql优化——部分
05-18
本篇文章将深入探讨两个关键的MySQL优化技术：存储过程优化和索引优化，具体为使用临时表代替游标以及巧建SUM索引来提升效率。 首先，我们来谈谈MySQL存储过程中的优化策略——使用临时表代替游标。游标在处理复杂...
MySQL——索引与EXPLAIN
等一杯咖啡的博客
12-05 1343
前言 本文内容主要参考自《高性能MySQL》第5章以及《MySQL DBA 修炼之道》书中的第三章，算是原书的实践与补充。 上次主要讲了MySQL的基本操作，这次来谈谈索引与EXPLAIN。 I. 什么是索引？ 想要深入的学习MySQL相关技术，而不仅仅停留在简单CURD，能够写出百万数据中分分钟查出需要数据的SQL，首先就需要掌握索引技术。那么什么是索引呢？ 要理解MySQL中索引是如何工作的，...
static ,out,ref，const关键字
qq_36499416的博客
07-10 662
const：修饰的变量成为常量，常量必须在丁一时初始化，以及不可以修改；static:   通过类名，结构名进行访问，跟对象无关；            static:静态的，修饰字段，属性，方法，事件，类；            静态的成员跟对象无关，通过类名或者结构名访问；            静态类只能定义常量或者静态的成员，不可以定义实例成员；静态类不可以实例化的;ref,out:传递值...
MySQL索引分析
weixin_48268269的博客
05-15 868
首先创建示例表，建立主键索引和联合索引。 CREATE TABLE `employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名', `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄', `position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位',
all index range ref eq_ref const system 索引type说明
weixin_30872671的博客
04-24 1212
背景知识 在使用sql的过程中经常需要建立索引，而每种索引是怎么处罚的又是怎么起到作用的，首先必须知道索引和索引的类型。 索引类型type 我们可以清楚的看到type那一栏有index ALL eq_ref，他们都代表什么意思呢？ 首先类型有许多，这里我只给大家介绍用的最多的几种类型： system>const>eq_ref>re...
mysql 索引ref_MySQL索引优化-性能分析Explain（转）
weixin_29038345的博客
01-27 1922
1. explain是什么使用explain关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的，分析你的查询语句或是表结构的性能瓶颈。2. explain能干吗可用于分析：表的读取顺序数据读取操作的操作类型哪些索引可以使用哪些索引被实际使用表之间的引用每张表有多少行被优化器查询3.explain怎么分析执行计划包含的信息如下：各字段解释3.1 idselect查...
mysql const ref_掌控你的MySQL语句执行方案
weixin_42126274的博客
02-17 747
SQL语句执行方案在互联网项目中，必然少不了数据库的使用，随着服务器QPS的上升，数据库的性能逐渐成为产品发展的瓶颈，对于快速响应用户的操作请求，掌控SQL语句的执行方案，对于请求的快速响应、查询的性能提升有着举足轻重的作用。互联网项目中，大部分情况下使用MySQL数据库，查看查询优化器如何执行查询的主要方法是使用EXPLAIN命令。EXPLAIN简介若要使用EXPLAIN，只需要在查询中的S...
mysql中explain的type的解释
热门推荐
dennis211的博客
10-07 10万+
连接操作的类型 （1）SYSTEM CONST的特例，当表上只有一条元组匹配 （2）CONST WHERE条件筛选后表上至多有一条元组匹配时，比如WHERE ID = 2 （ID是主键，值为2的要么有一条要么没有） （3）EQ_REF 参与连接运算的表是内表（在代码实现的算法中，两表连接时作为循环中的内循环遍历的对象，这样的表称为内表）。
springMVC
sdaujsj1的博客
04-09 467
===新手入门指南=== 新建goods包，并在goods包下创建model、repository、service、controller四个包，在/WEB-INF/views下创建goods文件夹 1.创建goods商品表结构 CREATE TABLE `goods` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT...
sql索引优化实战
xjk201的博客
01-31 292
举一个大家不容易理解的综合例子： 1、联合索引第一个字段用范围不会走索引 EXPLAIN SELECT * FROM employees WHERE name > 'LiLei' AND age = 22 AND position ='manager'; 结论：联合索引第一个字段就用范围查找不会走索引，mysql内部可能觉得第一个字段就用范围，结果集应该很大，回表效率不高，还不 如就全表扫描 下图 2、强制走索引 1 EXPLAIN SELECT * FROM em..
【MySQL】Using join buffer (Block Nested Loop) 索引不生效失效
hallo world！
01-29 589
【MySQL】Using join buffer (Block Nested Loop) 索引不生效失效 报错 字符集导致
数据库性能优化讲座——MySQL调用流程与实践案例
4. **优化整合**：MySQL的查询优化器会根据表结构、数据分布和索引情况，选择最佳的执行计划。 5. **连接数据库**：建立与数据库的连接，进行用户认证，确保只有授权的用户能访问数据库。 6. **发送查询请求**：...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值