mysql索引怎么用 mysql 索引是怎么实现的?

Mysql —— 索引的使用顺序

创建表

目前成都创新互联公司已为数千家的企业提供了网站建设、域名、网页空间、网站运营、企业网站设计、茄子河网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。

该表的记录如下:

添加两个索引:

通过 explain 来查看:

会命中两条索引,但实际只用了 idx_v1,即使实际查询用联合索引更好,也依然只用了 idx_v1。

之前的测试,发现用的是第一个,我们删除索引,把之前的索引语句顺序换一下:

发现用的是第一个。

MySql是怎么使用的索引,在哪些情况下会使用

MySql为以下这些操作使用索引:

1、为了快速查找匹配WHERE条件的行。

2、为了从考虑的条件中消除行。如果在多个索引之间选择一个,正常情况下,MySql使用找到行的最小数量的那个索引。

3、如果表有一个multiple-column索引,任何一个索引的最左前缀可以通过使用优化器来查找行。例如,如果你有一个 three-column索引在(col1, col2, col3),你能搜索索引在(col1), (col1, col2),和 (col1, col2, col3)。

Mysql索引

建立索引,要使用离散度(选择度)更高的字段。

我们先来看一个重要的属性列的 离散度,

count(distinct(column_name)) : count(*) -- 列的全部不同值个数:所有数据行行数

数据行数相同的情况下,分子越大,列的离散度就越高。简单来说,如果列的重复值越多,离散度就越低,重复值越少,离散度就越高。

当字段值比较长的时候,建立索引会消耗很多的空间,搜索起来也会很慢。我们可以通过截取字段的前面一部分内容建立索引,这个就叫前缀索引。

创建一张商户表,因为地址字段比较长,在地址字段上建立前缀索引

create table shop(address varchar(120) not null);

alter table shop add key(address(12));  // 截取12个字符作为前缀索引是最优的吗?

问题是,截取多少呢?截取得多了,达不到节省索引存储空间的目的,截取得少了,重复内容太多,字段的散列度(选择性)会降低。怎么计算不同的长度的选择性呢?

先看一下字段在全部数据中的选择度计算公式:

select count(distinct address) / count(*) from shop;

select count(distinct left(address, n)) / count(*) as subn from shop;

count(distinct left(address,n)) / count(*) 的结果是会随着 n 的变大而变大。举个例子,现在有两个address(东大街长兴小区,东大街福乐小区),那么 distinct(address,2) distinct(address,3)

==所以,截取的长度越长就会越接近字段在全部数据中的选择度

==所以,我们要权衡索引大小和查询速度。

举个例子,通过不同长度去计算,与全表的选择性对比:

SELECT  COUNT(DISTINCT(address))/COUNT(*) sub,            -- 字段在全部数据中的选择度

COUNT(DISTINCT(LEFT(address,5)))/COUNT(*) sub5,  -- 截取前5个字符的选择度

COUNT(DISTINCT(LEFT(address,7)))/COUNT(*) sub7, 

COUNT(DISTINCT(LEFT(address,9)))/COUNT(*) sub9,

COUNT(DISTINCT(LEFT(address,10)))/COUNT(*) sub10,  -- 截取前10个字符的选择度

COUNT(DISTINCT(LEFT(address,11)))/COUNT(*) sub11,

COUNT(DISTINCT(LEFT(address,12)))/COUNT(*) sub12,

COUNT(DISTINCT(LEFT(address,13)))/COUNT(*) sub13,

COUNT(DISTINCT(LEFT(address,15)))/COUNT(*) sub15

FROM shop;

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

| sub    | sub5  | sub7  | sub9  | sub10  | sub11  | sub12  | sub13  | sub15  |

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

| 0.9993 | 0.0225 | 0.4663 | 0.8618 | 0.9734 | 0.9914 | 0.9943 | 0.9943 | 0.9958 |

+--------+--------+--------+--------+--------+--------+--------+--------+--------+

可以看到在截取 11 个字段时 sub11(0.9993) 就已经很接近字段在全部数据中的选择度 sub(0.9958)了,而且长度也相较后面更短一些, 综合考虑比较合适。

ALTER TABLE shop ADD KEY (address(11));

1.索引的个数不要过多(浪费空间,更新变慢)

2.在用于 where 判断 order 排序和 join 的(on)字段上创建索引

3.区分度低的字段,例如性别,不要建索引(离散度太低,导致扫描行数过多)

4.更新频繁的值,不要作为主键或者索引(页分裂)

5.不建议用无序的值作为索引,例如身份证、UUID(在索引比较时需要转为ASCII,并且插入时可能造成页分裂)

6.若在多个字段都要创建索引的情况下,联合索引优于单值索引

7.联合索引把散列性高(区分度高)的值放在前面

mysql索引

在mysql中,索引是一种特殊的数据库结构,由数据表中的一列或多列组合而成,可以用来快速查询数据表中有某一特定值的记录。

通过索引,查询数据时不用读完记录的所有信息,而只是查询索引列即可。

通过索引,查询数据时不用读完记录的所有信息,而只是查询索引列。否则,数据库系统将读取每条记录的所有信息进行匹配。

可以把索引比作新华字典的音序表。例如,要查“库”字,如果不使用音序,就需要从字典的 400 页中逐页来找。但是,如果提取拼音出来,构成音序表,就只需要从 10 多页的音序表中直接查找。这样就可以大大节省时间。

因此,使用索引可以很大程度上提高数据库的查询速度,还有效的提高了数据库系统的性能。

索引的优缺点

索引有其明显的优势,也有其不可避免的缺点。

优点

索引的优点如下:

1、通过创建唯一索引可以保证数据库表中每一行数据的唯一性。

2、可以给所有的 MySQL 列类型设置索引。

3、可以大大加快数据的查询速度,这是使用索引最主要的原因。

4、在实现数据的参考完整性方面可以加速表与表之间的连接。

5、在使用分组和排序子句进行数据查询时也可以显著减少查询中分组和排序的时间

缺点

增加索引也有许多不利的方面,主要如下:

1、创建和维护索引组要耗费时间,并且随着数据量的增加所耗费的时间也会增加。

2、索引需要占磁盘空间,除了数据表占数据空间以外,每一个索引还要占一定的物理空间。如果有大量的索引,索引文件可能比数据文件更快达到最大文件尺寸。

3、当对表中的数据进行增加、删除和修改的时候,索引也要动态维护,这样就降低了数据的维护速度。

使用索引时,需要综合考虑索引的优点和缺点。

关于MySQL复合索引的使用方法

MySQL的复合索引可以创建多个,每个复合索引可以包含一列或多列。复合索引使用的基本原则是左侧对齐原则。例如,复合索引包含A,B,C字段,实际相当于创建了5个索引,即:

那么问题来了,如果我们创建两个复合索引,复合索引1:包含A,B,C列和复合索引2:包含B,C列,MySQL如何执行呢?

按照正常的逻辑,和复合索引的原则,应该能命中的索引是A_B_C_index,让我们拭目以待吧!

结果:和上次测试的不一致,这次虽然包含ABC三个列,但命中的索引是B_C_index

重要结论:当命中两个或者多个不同的复合索引时,按照创建顺序不同,MySQL会有不同策略来选取其中的一个复合索引。

mysql 索引怎么使用

CREATE [UNIQUE] INDEX index_name ON table_name(字段 [ASC|DESC]);

UNIQUE --确保所有的索引列中的值都是可以区分的。

[ASC|DESC] --在列上按指定排序创建索引。

(创建索引的准则:

1.如果表里有几百行记录则可以对其创建索引(表里的记录行数越多索引的效果就越明显)。

2.不要试图对表创建两个或三个以上的索引。

3.为频繁使用的行创建索引。

)

示例

create index i_1 on emp(empno asc);


当前名称:mysql索引怎么用 mysql 索引是怎么实现的?
网站链接:http://ybzwz.com/article/doccdii.html