Mysql 索引

最新推荐文章于 2023-02-03 23:41:38 发布
最新推荐文章于 2023-02-03 23:41:38 发布
阅读量221 收藏 1
点赞数
分类专栏： mysql
原文链接：https://www.cnblogs.com/nov5026/p/11210078.html
版权

一. 存储引擎

1. 什么是存储引擎？
与其他数据库例如Oracle 和SQL Server等数据库中只有一种存储引擎不同的是，MySQL有一个被称为“Pluggable Storage Engine Architecture”(可替换存储引擎架构)的特性，也就意味着MySQL数据库提供了多种存储引擎。用户可以根据不同的需求为数据表选择不同的存储引擎，用户也可以根据自己的需要编写自己的存储引擎。MySQL数据库在实际的工作中其实分为了语句分析层和存储引擎层，其中语句分析层就主要负责与客户端完成连接并且事先分析出SQL语句的内容和功能，而存储引擎层则主要负责接收来自语句分析层的分析结果，完成相应的数据输入输出和文件操作。简而言之，就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法。因为在关系数据库中数据的存储是以表的形式存储的，所以存储引擎也可以称为表类型（即存储和操作此表的类型）。

2. 存储引擎种类

存储引擎说明
MyISAM高速引擎，拥有较高的插入，查询速度，但不支持事务
InnoDB5.5版本后MySQL的默认数据库，支持事务和行级锁定，比MyISAM处理速度稍慢
ISAMMyISAM的前身，MySQL5.0以后不再默认安装
MRG_MyISAM(MERGE)将多个表联合成一个表使用，在超大规模数据存储时很有用
Memory内存存储引擎，拥有极高的插入，更新和查询效率。但是会占用和数据量成正比的内存空间。只在内存上保存数据，意味着数据可能会丢失
Falcon一种新的存储引擎，支持事物处理，传言可能是InnoDB的替代者
Archive将数据压缩后进行存储，非常适合存储大量的独立的，作为历史记录的数据，但是只能进行插入和查询操作
CSVCSV 存储引擎是基于 CSV 格式文件存储数据(应用于跨平台的数据交换)

接下来我们就介绍两种在实际开发中使用最多的两种引擎【MyISAM】和【InnoDB】。

3. MyISAM 引擎
这种引擎是MySQL最早提供的。这种引擎又可以分为静态MyISAM、动态MyISAM 和压缩MyISAM三种：

静态MyISAM： 如果数据表中的各数据列的长度都是预先固定好的，服务器将自动选择这种表类型。因为 数据表中每一条记录所占用的空间都是一样的，所以这种表存取和更新的效率非常高。当数据受损时，恢复工作也比较容易做。

动态MyISAM: 如果数据表中出现varchar、xxxtext或xxxBLOB字段时，服务器将自动选择这种表类型。相对于静态MyISAM，这种表存储空间比较小，但由于每条记录的长度不一，所以多次修改数据后，数据表中的数据就可能离散的存储在内存中，进而导致执行效率下降。同时，内存中也可能会出现很多碎片。因此，这种类型的表要经常用optimize table 命令或优化工具来进行碎片整理。

压缩MyISAM： 以上说到的两种类型的表都可以用myisamchk工具压缩。这种类型的表进一步减小了占用的存储，但是这种表压缩之后不能再被修改。另外，因为是压缩数据，所以这种表在读取的时候要先时行解压缩。

当然不管是何种MyISAM表，目前它都不支持事务，行级锁和外键约束的功能，这就意味着有事务处理需求的表，不能使用MyISAM存储引擎。MyISAM存储引擎特别适合在以下几种情况下使用：

  • 选择密集型的表。MyISAM存储引擎在筛选大量数据时非常迅速，这是它最突出的优点。
  • 插入密集型的表。MyISAM的并发插入特性允许同时选择和插入数据。

MyISAM表是独立于操作系统的，这说明可以轻松地将其从Windows服务器移植到Linux服务器；每当我们建立一个MyISAM引擎的表时，就会在本地磁盘上建立三个文件，文件名就是表名。 例如我创建了一个【test】表，那么就会生成以下三个文件：

文件名说明
test.frm存储表定义
test.MYD存储数据
test.MYI存储索引

4. InnoDB引擎
InnoDB表类型可以看作是对MyISAM的进一步更新产品，它提供了事务、行级锁机制和外键约束的功能。InnoDB的表需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引。 使用InnoDB是最理想的选择：

  • 更新密集的表：InnoDB存储引擎特别适合处理多重并发的更新请求 事务：InnoDB存储引擎是支持事务的标准MySQL存储引擎
  • 自动灾难恢复：与其它存储引擎不同，InnoDB表能够自动从灾难中恢复
  • 外键约束：MySQL支持外键的存储引擎，只有InnoDB支持自动增加列AUTO_INCREMENT属性

总结

  • InnoDB： 支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高（比如银行），要求实现并发控制（比如售票），那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交（commit）和回滚（rollback）。

  • MyISAM： 插入数据快，空间和内存使用比较低。如果表主要是用于插入新记录和读出记录，那么选择MyISAM能实现处理高效率。如果应用的完整性、并发性要求比较低，也可以使用。

注意，同一个数据库也可以使用多种存储引擎的表。如果一个表要求比较高的事务处理，可以选择InnoDB。这个数据库中可以将查询要求比较高的表选择MyISAM存储。如果该数据库需要一个用于查询的临时表，可以选择MEMORY存储引擎。

二. 索引结构(方法、算法)

在mysql中常用两种索引结构(算法)BTree和Hash，两种算法检索方式不一样，对查询的作用也不一样。
常用存储引擎对应的索引结构

存储引擎显示支持索引结构
InnoDBBTREE
MyISAMBTREE
MEMORY/HEAPHASH,BTREE
NDBHASH, BTREE (see note in text)

mysql InnoDB存储引擎 是支持hash索引的，不过，我们必须启用，hash索引的创建由InnoDB存储引擎引擎自动优化创建，我们干预不了。

1.Hash
Hash索引的底层实现是由Hash表来实现的，非常适合以 key-value 的形式查询，也就是单个key 查询，或者说是等值查询。其结构如下所示：

从上面结构可以看出，Hash 索引可以比较方便的提供等值查询的场景,由于是一次定位数据，不像BTree索引需 要从根节点到枝节点，最后才能访问到页节点这样多次IO访问，所以检索效率远高于BTree索引。但是对于范围查询的话，就需要进行全表扫描了。

但为什么我们使用BTree比使用Hash多呢？主要Hash本身由于其特殊性，也带来了很多限制和弊端：

  1. Hash索引仅仅能满足“=”,“IN”,“<=>”查询，不能使用范围查询。
  2. 联合索引中，Hash索引不能利用部分索引键查询。对于联合索引中的多个列，Hash是要么全部使用，要么全部不使用，并不支持BTree支持的联合索引的最优前缀，也就是联合索引的前面一个或几个索引键进行查询时，Hash索引无法被利用。
  3. Hash索引无法避免数据的排序操作, 由于Hash索引中存放的是经过Hash计算之后的Hash值，而且Hash值的大小关系并不一定和Hash运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算。
  4. Hash索引任何时候都不能避免表扫描, Hash索引是将索引键通过Hash运算之后，将Hash运算结果的Hash值和所对应的行指针信息存放于一个Hash表中，由于不同索引键存在相同Hash值，所以即使满足某个Hash键值的数据的记录条数，也无法从Hash索引中直接完成查询，还是要通过访问表中的实际数据进行比较，并得到相应的结果。
  5. Hash索引遇到大量Hash值相等的情况后性能并不一定会比BTree高, 对于选择性比较低的索引键，如果创建Hash索引，那么将会存在大量记录指针信息存于同一个Hash值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据访问，而造成整体性能底下。

2. B+Tree
B+Tree索引是最常用的mysql数据库索引算法，因为它不仅可以被用在=,>,>=,<,<=和between这些比较操作符上，而且还可以用于like操作符，只要它的查询条件是一个不以通配符开头的常量，例如：* select * from user where name like ‘jack%’; select * from user where name like ‘jac%k%’; 如果一通配符开头，或者没有使用常量，则不会使用索引，例如： select * from user where name like ‘%jack’; select * from user where name like simply_name;

看看mysql中的B+树模型吧：
B+树

三. 索引方式

Mysql数据库中的B+树索引可以分为聚集索引和非聚集索引（辅助索引）

聚集索引
聚集索引：指索引项的排序方式和表中数据记录排序方式一致的索引（这里不懂先放着，一会举例），每张表只能有一个聚集索引，聚集索引的叶子节点存储了整个行数据(即:一张表只能有一个聚集索引)。

解释： 什么叫索引项的排序方式和表中数据记录排序方式一致呢？ 我们把一本字典看做是数据库的表，那么字典的拼音目录就是聚集索引，它按照A-Z排列。实际存储的字也是按A-Z排列的。这就是索引项的排序方式和表中数据记录排序方式一致。

对于Innodb，主键毫无疑问是一个聚集索引。但是当一个表没有主键，或者没有一个索引，Innodb会如何处理呢。请看如下规则:

  • 如果一个主键被定义了，那么这个主键就是作为聚集索引。
  • 如果没有主键被定义，那么该表的第一个唯一非空索引被作为聚集索引。
  • 如果没有主键也没有合适的唯一索引，那么innodb内部会生成一个隐藏的主键作为聚集索引，这个隐藏的主键是一个6个字节的列，该列的值会随着数据的插入自增。

非聚集索引
非聚集索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同，一个表中可以拥有多个非聚集索引。叶子节点并不包含行记录的全部数据。叶子节点除了包含键值以外，还存储了一个指向改行数据的聚集索引建的书签。

四. 索引类型

MySQL目前主要有以下几种索引类型：

  • 普通索引
  • 唯一索引
  • 主键索引
  • 组合索引
  • 全文索引

普通索引
这是最基本的索引，它没有任何限制。它有以下几种创建方式：

  • 直接创建索引
CREATE INDEX index_name ON table(column(length))
  • 修改表结构的方式添加索引
ALTER TABLE table_name ADD INDEX index_name ON (column(length))
  • 创建表的时候同时创建索引
CREATE TABLE `table` (
    `id` int(11) NOT NULL AUTO_INCREMENT ,
    `title` char(255) CHARACTER NOT NULL ,
    `content` text CHARACTER NULL ,
    `time` int(10) NULL DEFAULT NULL ,
    PRIMARY KEY (`id`),
    INDEX index_name (title(length))
)
  • 删除索引
drop index indexName on TableName

唯一索引
与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：

  • 创建唯一索引
CREATE UNIQUE INDEX indexName ON table(column(length))
  • 修改表结构
ALTER TABLE table_name ADD UNIQUE indexName ON (column(length))

（3）创建表的时候直接指定

CREATE TABLE `table` (
    `id` int(11) NOT NULL AUTO_INCREMENT ,
    `title` char(255) CHARACTER NOT NULL ,
    `content` text CHARACTER NULL ,
    `time` int(10) NULL DEFAULT NULL ,
    UNIQUE indexName (title(length))
);

主键索引
是一种特殊的唯一索引，一个表只能有一个主键，不允许有空值。一般是在建表的时候同时创建主键索引：

CREATE TABLE `table` (
    `id` int(11) NOT NULL AUTO_INCREMENT ,
    `title` char(255) NOT NULL ,
    PRIMARY KEY (`id`)
);

组合索引
指多个字段上创建的索引，只有在查询条件中使用了创建索引时的第一个字段，索引才会被使用。使用组合索引时遵循 最左前缀集合

ALTER TABLE `table` ADD INDEX name_city_age (name,city,age);

全文索引
主要用来查找文本中的关键字，而不是直接与索引中的值相比较。fulltext索引跟其它索引大不相同，它更像是一个搜索引擎，而不是简单的where语句的参数匹配。fulltext索引配合match against操作使用，而不是一般的where语句加like。它可以在create table，alter table ，create index使用，不过目前只有char、varchar，text 列上可以创建全文索引。值得一提的是，在数据量较大时候，现将数据放入一个没有全局索引的表中，然后再用CREATE index创建fulltext索引，要比先为一张表建立fulltext然后再将数据写入的速度快很多。

CREATE TABLE `table` (
    `id` int(11) NOT NULL AUTO_INCREMENT ,
    `title` char(255) CHARACTER NOT NULL ,
    `content` text CHARACTER NULL ,
    `time` int(10) NULL DEFAULT NULL ,
    PRIMARY KEY (`id`),
    FULLTEXT (content)
);

五. 索引优化

mysql执行计划中的extra列中表明了执行计划的每一步中的实现细节，其中包含了与索引相关的一些细节信息 其中跟索引有关的using index 在不同的情况下会出现Using index， Using where Using index ，Using index condition，(Using filesort, Using temporay 需要优化) 等 ，那么Using index 和 Using where;Using index 有什么区别？网上搜了一大把文章，说实在话也没怎么弄懂，于是就自己动手试试。

本文仅从最简单的单表去测试using index 和 using where using index以及简单测试using index condition的情况的出现时机 。 执行计划的生成与表结构，表数据量，索引结构，统计信息等等上下文等多种环境有关，无法一概而论，复杂情况另论。

测试环境搭建

create table test_order
(
    id int auto_increment primary key,
    user_id int,
    order_id int,
    order_status tinyint,
    create_date datetime
);
create table test_orderdetail
(
    id int auto_increment primary key,
    order_id int,
    product_name varchar(100),
    cnt int,
    create_date datetime
);
create index idx_userid_order_id_createdate on test_order(user_id,order_id,create_date);
create index idx_orderid_productname on test_orderdetail(order_id,product_name);

创建存储过程（insertOrder），创建测试数据，脚本如下

BEGIN
	 declare v_uuid  varchar(50);
DECLARE  v_orderId int;
    while loopcount>0 do
        set v_uuid = uuid();
				SET v_orderId=rand()*100000;
        insert into test_order (user_id,order_id,order_status,create_date) values (rand()*1000,v_orderId,rand()*10,DATE_ADD(NOW(), INTERVAL - RAND()*20000 HOUR));
        insert into test_orderdetail(order_id,product_name,cnt,create_date) values (v_orderId,v_uuid,rand()*10,DATE_ADD(NOW(), INTERVAL - RAND()*20000 HOUR));
        set loopcount = loopcount -1;
    end while;
END
-- 创建50W条测试数据

call insertOrder (50000);

Using index

1，查询的列被索引覆盖，并且where筛选条件是索引的是前导列，Extra中为Using index

  • 查询的列全部在索引中,并且where筛选条件是索引的前导列
  • type:ref(索引查找)+ Extra:using index
EXPLAIN SELECT user_id,order_id,create_date from test_order where user_id=1;

Using where Using index

查询的列被索引覆盖，并且where筛选条件是索引列之一但是不是索引的不是前导列，Extra中为Using where; Using index，意味着无法直接通过索引查找来查询到符合条件的数据

  • 查询的列全部在索引中,并且where的筛选条件不符合索引的前导列
  • type:index(索引扫描) + Extra:Using where; Using index
EXPLAIN SELECT user_id,order_id,create_date from test_order where order_id=67260;

查询的列被索引覆盖，并且where筛选条件是索引列前导列的一个范围，同样意味着无法直接通过索引查找查询到符合条件的数据

  • 查询的列全部在索引中,并且where的筛选条件是索引前导列的一个范围
  • type:index(索引扫描) + Extra:Using where; Using index
EXPLAIN SELECT user_id,order_id,create_date from test_order where user_id<5;

NULL（既没有Using index，也没有Using where Using index，也没有using where）

查询的列未被索引覆盖，并且where筛选条件是索引的前导列， 　　 意味着用到了索引，但是部分字段未被索引覆盖，必须通过“回表”来实现，不是纯粹地用到了索引，也不是完全没用到索引，Extra中为NULL(没有信息)

  • 查询的列不全在索引中,并且where的筛选条件是索引的前导列
  • type:ref + Extra:NULL
EXPLAIN SELECT * from test_order where user_id=1;

Using where

查询的列未被索引覆盖，where筛选条件非索引的前导列，Extra中为Using where

  • 查询的列不全在索引中,并且where的筛选条件不是索引的前导列
EXPLAIN SELECT * from test_order where order_id=67260;

using where 意味着通过索引或者表扫描的方式进程where条件的过滤， 反过来说，也就是没有可用的索引查找，当然这里也要考虑索引扫描+回表与表扫描的代价。 这里的type都是all，说明MySQL认为全表扫描是一种比较低的代价。

Using index condition

查询的列不全在索引中，where条件中是一个前导列的范围

  • 查询的列不全在索引中，where条件中是一个前导列的范围
EXPLAIN SELECT * from test_order where user_id>1 and user_id<10;

查询列不完全被索引覆盖，查询条件完全可以使用到索引（进行索引查找）

  • 查询的列不全在索引中，查询条件完全可以使用到索引（进行索引查找）
EXPLAIN SELECT * from test_order where user_id=1 and order_id=67260 
and create_date>'2017-03-15';

结论：

  1. Extra中的为Using index的情况。 where筛选列是索引的前导列 &&查询列被索引覆盖 && where筛选条件是一个基于索引前导列的查询，意味着通过索引超找就能直接找到符合条件的数据，并且无须回表
  2. Extra中的为空的情况。查询列存在未被索引覆盖&&where筛选列是索引的前导列，意味着通过索引超找并且通过“回表”来找到未被索引覆盖的字段，
  3. Extra中的为Using where Using index。出现Using where Using index意味着是通过索引扫描（或者表扫描）来实现sql语句执行的，即便是索引前导列的索引范围查找也有一点范围扫描的动作，不管是前非索引前导列引起的，还是非索引列查询引起的。

MySQL执行计划中的Extra中信息非常多，不仅仅包括Using index，Using where Using index，Using index condition，Using where，尤其是在多表连接的时候，这一点在相对MSSQL来说，不够直观或者结构化。MSSQL中是通过区分索引查找（index seek），索引扫描（index scan），表扫描（table scan）来实现具体的查询的，这图形化的执行计划在不同的场景下是非常直观的，要想完全弄懂MySQL的这个执行计划，可能要更多地在实践中摸索。

  1. id 表示执行的顺序，id越大越先执行，id一样的从上往下执行。
  2. select_type
  3. table表名或者表的别名。
  4. partitions分区信息，非分区表为null。
  5. type 访问类型，表示找到所查询数据的方法，也是本文重点介绍的属性。该属性的常见值如下，性能从好到差：
NULL:无需访问表或者索引，比如获取一个索引列的最大值或最小值。
system/const:当查询最多匹配一行时，常出现于where条件是＝的情况。system是const的一种特殊情况，既表本身只有一行数据的情况。
eq_ref: 每次与之前的表合并行都只在该表读取一行，这是除了system，const之外最好的一种，特点是使用=，而且索引的所有部分都参与join且索引是主键或非空唯一键的索引
ref: 如果每次只匹配少数行，那就是比较好的一种，使用=或<=>，可以是左覆盖索引或非主键或非唯一键
fulltext: 全文搜索
ref_or_null: 与ref类似，但包括NULL
index_merge: 表示出现了索引合并优化(包括交集，并集以及交集之间的并集)，但不包括跨表和全文索引。 这个比较复杂，目前的理解是合并单表的范围索引扫描（如果成本估算比普通的range要更优的话）
unique_subquery: 在in子查询中，就是value in (select...)把形如“select unique_key_column”的子查询替换。PS：所以不一定in子句中使用子查询就是低效的！
index_subquery: 同上，但把形如”select non_unique_key_column“的子查询替换
range: 常数值的范围（索引范围扫描），对索引的扫描开始于某一点，返回匹配值域的行，常见于between、<、>等的查询
index: a.当查询是索引覆盖的，即所有数据均可从索引树获取的时候（Extra中有UsingIndex）； b.以索引顺序从索引中查找数据行的全表扫描（无 UsingIndex）； c.如果Extra中Using Index与Using Where同时出现的话，则是利用索引查找键值的意思； d.如单独出现，则是用读索引来代替读行，但不用于查找
all: 遍历全表以找到匹配的行
null: MySQL在优化过程中分解语句，执行时甚至不用访问表或索引
  1. possible_keys 表示mysql此次查询中可能使用的索引。
  2. key 表示mysql实际在此次查询中使用的索引。
  3. key_len 表示mysql使用的索引的长度。该值越小越好。
  4. ref 表示连接查询的连接条件。
  5. rows 表示mysql估计此次查询所需读取的行数。该值越小越好。
  6. extra 表示mysql解决查询的其他信息，有几十种不同的值，该信息也是我们优化sql可以专注的一个值。关于这个extra信息我可能会再下一篇中介绍，这里先略过。

索引结果值从好到坏依次是：

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

优化原则

  • 禁用select *
  • 使用select count(*) 统计行数
  • 尽量少运算
  • 尽量避免全表扫描，如果可以，在过滤列建立索引
  • 尽量避免在where子句对字段进行null判断
  • 尽量避免在where子句使用!= 或者<>
  • 尽量避免在where子句使用or连接
  • 尽量避免对字段进行表达式计算
  • 尽量避免对字段进行函数操作
  • 尽量避免使用不是复合索引的前缀列进行过滤连接
  • 尽量少排序，如果可以，建立索引
  • 尽量少join
  • 尽量用join代替子查询
  • 尽量避免在where子句中使用in,not in或者having，使用exists,not exists代替
  • 尽量避免两端模糊匹配 like %***%
  • 尽量用union all代替union
  • 尽量早过滤
  • 避免类型转换
  • 尽量批量insert
  • 优先优化高并发sql，而不是频率低的大sql
  • 尽可能对每一条sql进行explain
  • 尽可能从全局出发

六. 扩展:常见问题

1. 如何解决非聚集索引二次查询(回表)的问题？
建立两列以上的索引，即可查询复合索引里的列的数据而不需要进行回表二次查询，如index(col1, col2)，执行下面的语句：

select col1, col2 from t1 where col1 = '213';

因为复合索引的列包括了col1和col2，不需要查询别的列，所以不需要进行二次查询。

要注意使用复合索引需要满足最左侧索引的原则，也就是查询的时候如果where条件里面没有最左边的一到多列，索引就不会起作用。

2. 哪些情况下需要创建索引

  • 主键自动建立索引
  • 频繁作为查询条件的字段应该创建索引
  • 查询中与其他字段关联的字段，外键关系建立索引
  • 频繁更新的字段不适合建立索引，因为每次更新不单单更新记录，还会更新索引
  • where 条件里用不到的字段不创建索引
  • 单键/组合索引的选择问题，在高并发下倾向创建组合索引
  • 查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度
  • 查询中的分组或统计字段

3. 哪些情况下不要创建索引

  • 表的记录太少
  • 经常增删改的表
  • 数据重复且分布平均的表字段

4. 索引使用注意事项：

  • 索引会忽略null值，所以我们在设计数据库的时候设置为为NOT NULL;
  • 短索引（给索引设置长度）不仅能够提高查询速度，而且能节省I/O操作。
  • Mysql在查询的时候只会使用一个索引，但不是一个字段
  • 不鼓励使用like对索引操作：like"%aaa%"不会使用索引；但like“aaa%”会使用索引。即可以对固定起始值模糊查询
  • 不适用于否地操作（not in , <>, !=，or） //用到or地方，尽量用union，或者程序两次查找
  • 如果创建了索引，但是查询语句并没有使用，则会使原来的效率更差
hw19674
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
mysql执行计划extra为null_MySQL执行计划extra解析
weixin_32308155的博客
02-28 3653
MySQL执行计划extra解析mysql的执行计划最让人难以捉磨的地方就是extra栏位的提示了，这是由于其他的栏位没有提供详细的信息，因此多一个栏位来附加额外的信息，以利于用户更好的理解sql是怎么执行的.以下是一些最常见的出现值:创建测试对像,并插入一些数据create table t1 ( a int primary key,b int,c varchar(100));create tab...
mysql之执行计划——explain中的extra详解
想当厨子的程序媛
02-01 7724
之前一直对explain中的extra和type两个类型混淆。其实两者完全不同，type列和覆盖索引毫无关系，它只是表示这个查询访问数据的方式，或者说是MySQL查询行的方式。 我们使用一个例子来讲解这个extra列。下面的例子来自：https://blog.csdn.net/jeffrey11223/article/details/79100761 首先我们创建一个表 CREATE TAB...
MySQL 执行计划中Extra(Using where,Using index,Using index condition,Using index,Using where)的浅析...
weixin_34372728的博客
11-05 857
  关于如何理解MySQL执行计划中Extra列的Using where、Using Index、Using index condition，Using index,Using where这四者的区别。首先，我们来看看官方文档关于三者的简单介绍（官方文档并没有介绍Using index,Using where这种情况）：     Using index (JSON property: using_...
MySQL执行计划extra中的using index 和 using where using index 的区别
dark
09-09 1306
引用： MySQL执行计划extra中的using index 和 using where using index 的区别 测试环境搭建 测试表以及测试数据搭建，类似于订单表和订单明细表，暂时先用订单表做测试 表结构 create table test_order ( id int auto_increment primary key, user_id int, order_id int, order_status tinyint, create_date dat.
mysql extra 为空_mysql – 运行EXPLAIN时,如果key的字段值不为null但Extra为空,是否使用了密钥？...
weixin_31349647的博客
01-19 1092
在没有索引的情况下运行此EXPLAIN查询时EXPLAIN SELECT exec_date,100 * SUM(CASE WHEN cached = 'no' THEN 1 ELSE 0 END) / SUM(1) cached_no,100 * SUM(CASE WHEN cached != 'no' THEN 1 ELSE 0 END) / SUM(1) cached_yesFROM r...
MySQL 执行计划的浅析
ldw1986hf123的博客
09-04 1093
首先是explain中所有列的信息，Extra只是其中比较重要的一列。 EXPLAIN列的解释 table：显示这一行的数据是关于哪张表的 type：这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、index、ALLtype显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是：system > const > eq_ref > ref > fulltext > ref_or_null > in...
MYSQL索引
01-27
MySQL索引是数据库管理系统中用于加速数据检索的关键结构。索引优化是提升查询性能的关键手段。MySQL中的索引主要在存储引擎层实现，而非服务器层。B-Tree索引是最常见的索引类型，其特点是所有值按顺序存储，每个...
Mysql索引详细介绍
09-10
MySQL索引是数据库管理系统中用于加速数据检索的重要工具。它们通过创建数据结构，使得数据库能够快速定位到所需的数据行，从而显著提高了查询性能。以下是关于MySQL索引的详细介绍： **一、索引概述** MySQL允许为...
快速了解MySQL 索引
12-14
MySQL索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。 打个比方，如果合理的设计且使用索引的MySQL是一辆兰博基尼的话，那么没有设计和使用索引的MySQL就是一个人力三轮车。 索引分...
php mysql索引问题
10-30
朋友问：今天我碰到个问题，我建个表，索引是REF，怎么才能写进一条信息，自动生成一个REF号码，记录到表中去呢？希望生成的REF号码是连续的，从00000开始。
Mysql Explain 详解
10-17
Mysql Explain 详解
MySQL-explain-extra字段详解
浩然的博客
02-03 1423
MySQL的explain中extra分析
mysql 执行计划extra_mysql之执行计划——explain中的extra详解
weixin_39833429的博客
01-27 920
之前一直对explain中的extra和type两个类型混淆。其实两者完全不同，type列和覆盖索引毫无关系，它只是表示这个查询访问数据的方式，或者说是MySQL查询行的方式。我们使用一个例子来讲解这个extra列。下面的例子来自：https://blog..net/jeffrey11223/article/details/79100761首先我们创建一个表CREATE TABLE test_ex...
mysql extra 为空_请问各路高手：MySQL的Explain结果中Extra为空值代表什么意思
weixin_26905423的博客
01-19 3106
请教各路高手：mysql的Explain结果中Extra为空值代表什么意思？explainselect a.id,a.cid,a.title,a.date,a.description,b.ctitle,b.cname from tb_2_content as a left join tb_2_category as b on (a.cid=b.cid) order by id desc limit...
mysql extra 为空_运行EXPLAIN时，如果key的字段值不为null但Extra为空，是否使用了key？...
weixin_27180827的博客
01-19 741
When running this EXPLAIN query without an indexEXPLAIN SELECT exec_date,100 * SUM(CASE WHEN cached = 'no' THEN 1 ELSE 0 END) / SUM(1) cached_no,100 * SUM(CASE WHEN cached != 'no' THEN 1 ELSE 0 END) ...
MySQL中explain执行计划中额外信息字段(Extra)详解
热门推荐
poxiaonie的博客
08-31 6万+
SQL执行计划是经过优化器决策，产生的SQL在数据库内部执行的访问路径计划； 由如下语法得到：explain select col1,col2 from t1..; desc select col1,col2 from t1..;理解输出各个列的含义 id:每个select子句的标识id select_type:select语句的类型 table:当前表名 显示查询将访问的分区，如果你的查询是基于
Android Kotlin intent.getStringExtra("xxx") 获取为 null 问题解决
Keep Learning , Keep Improving !
02-25 6327
使用 Anko 时遇到一个坑，Activity 获取上一个页面传过来的参数 String xxx=intent.getStringExtra("xxx") xxx 一直为 null 因为缺少 toString val xxx= et_xxx.text startActivity&lt;MainActivity&gt;("xxx " to xxx) 此时 xxx 是Editable 不是 St...
mysql索引
最新发布
05-29
MySQL索引是一种数据结构，可以帮助MySQL快速定位和访问表中的数据。使用索引可以提高查询效率，降低数据库的负载。下面是MySQL索引的一些基本概念和使用方法： 1. 索引类型 MySQL支持多种类型的索引，包括B树索引、哈希索引、全文索引等。其中，B树索引是最常用的一种，也是默认的索引类型。B树索引可以用于精确匹配和范围查询，而哈希索引主要用于等值查询，全文索引则用于文本检索。 2. 索引创建 可以在创建表时指定索引，例如： ``` CREATE TABLE users ( id INT PRIMARY KEY, name VARCHAR(50), email VARCHAR(50), INDEX idx_email (email) ); ``` 也可以在已有的表上添加索引，例如： ``` ALTER TABLE users ADD INDEX idx_name (name); ``` 3. 索引使用 查询语句中可以使用WHERE子句和ORDER BY子句来利用索引，例如： ``` SELECT * FROM users WHERE email = 'example@example.com'; SELECT * FROM users WHERE name LIKE 'John%' ORDER BY id DESC; ``` 需要注意的是，索引并不是越多越好，过多的索引会占用过多的磁盘空间并降低写操作的性能。因此，需要根据实际情况选择合适的索引。同时，还需要定期对索引进行维护，包括优化查询语句、删除不必要的索引等。 4. 索引优化 MySQL提供了一些工具来优化索引，例如EXPLAIN命令可以帮助分析查询语句的执行计划，找出慢查询和不必要的全表扫描。可以使用OPTIMIZE TABLE命令来优化表的索引和碎片，从而提高查询性能。还可以使用缓存来避免频繁的查询操作，例如使用Memcached或Redis等缓存工具。 以上就是MySQL索引的一些基本概念和使用方法，需要根据实际情况进行选择和优化。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值