【推荐】mysql联合索引(复合索引)的探讨

最新推荐文章于 2024-07-25 16:06:56 发布

大树叶

最新推荐文章于 2024-07-25 16:06:56 发布

阅读量2.5w

点赞数 29

分类专栏：数据库 mysql 文章标签： mysql 多列索引

数据库同时被 2 个专栏收录

122 篇文章 0 订阅

订阅专栏

mysql

117 篇文章 1 订阅

订阅专栏

Ｍysql联合索引(复合索引)的使用原则

命名规则：表名_字段名

需要加索引的字段，要在where条件中。
数据量少的字段不需要加索引。最窄的字段放在键的左边。
如果where条件中是OR关系，必须所有的or条件都必须是独立索引，否则加索引不起作用。见：mysql关于or的索引问题
最左匹配原则。
只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

下面用例子来说明多列联合索引的用法。

假设某个表有一个联合索引（c1,c2,c3,c4）以下选项哪些字段使用了该索引：
A where c1=x and c2=x and c4>x and c3=x
B where c1=x and c2=x and c4=x order by c3
C where c1=x and c4= x group by c3,c2
D where c1=? and c5=? order by c2,c3
E where c1=? and c2=? and c5=? order by c2,c3

例子演示

首先创建表：

CREATE TABLE t(
c1 CHAR(1) not null,
c2 CHAR(1) not null,
c3 CHAR(1) not null,
c4 CHAR(1) not null,
c5 CHAR(1) not null
)ENGINE myisam CHARSET UTF8;

有c1到c5 5个字段，特别说明一下字段类型都是定长char（1）类型，并且非空，字符集是utf8（与计算索引使用字节数有关）

创建索引：

alter table t add index c1234(c1,c2,c3,c4);

插入2条数据：

insert into t VALUES('1','1','1','1','1'),('2','2','2','2','2')

使用MySql Explain开始分析题目结果：

A选项：

结果可以看出，c1,c2,c3,c4均使用到了该索引，而我们对A结果稍作更改：

将c2条件去掉后：

根据索引最左原则，c2字段没有使用索引，c2之后的字段都不能使用索引。下面2图我们对比下索引最左原则：

上图结果显示直接使用c3是全表查询，无法使用该索引的，所以c3字段使用索引的前提是c1，c2两字段均使用了索引。

即是索引的最左原则（左前缀原则）。

B选项：

key_len长度说明c1，c2字段用到了该索引，Extra显示并没有使用临时表进行排序，说明排序是使用了索引的，但并没有计算在key_len值中，也没有起到连接c4的作用，说明索引到c3这里是断掉的。

排序其实是利用联合索引直接完成了的，即：使用了c1234联合索引，就已经使得c1下c2，c2下c3，c3下c4是有序的了，所以实际是排序利用了索引，c3字段并没有使用该索引。（这段写的时候总感觉有点别扭，不知道我理解的对不对，还有待更深层次的研究）

C选项：

使用group by 一般先生成临时文件，再进行排序，但是字段顺序为c2，c3时，并没有用临时表进行排序，而是利用索引排序好的；当group by字段为c3，c2时，由于与索引字段顺序不一致，所以分组和排序并没有利用到索引。

由key_len长度确定，只有c1一个字段使用了索引。

D选项：

order by 和group by 类似，字段顺序与索引一致时，会使用索引排序；字段顺序与索引不一致时，不使用索引。

由key_len长度确定，只有c1一个字段使用了索引。

E选项：

其实选项E的结果分析在上述ABCD的结果中都分析过了，这里只有c1，c2字段使用了该索引。

综上所述问题答案：

A:四个字段均使用了该索引

B:c1，c2字段使用了该索引

C:c1字段使用该索引

D:c1字段使用该索引

E:c1，c2字段使用了该索引

总结：

索引的最左原则（左前缀原则），如（c1,c2,c3,c4....cN）的联合索引，where 条件按照索引建立的字段顺序来使用（不代表and条件必须按照顺序来写），如果中间某列没有条件，或使用like会导致后面的列不能使用索引。

索引也能用于分组和排序，分组要先排序，在计算平均值等等。所以在分组和排序中，如果字段顺序可以按照索引的字段顺序，即可利用索引的有序特性。

什么情况下应不建或少建索引

表记录太少

如果一个表只有5条记录，采用索引去访问记录的话，那首先需访问索引表，再通过索引表访问数据表，一般索引表与数据表不在同一个数据块，这种情况下ORACLE至少要往返读取数据块两次。而不用索引的情况下ORACLE会将所有的数据一次读出，处理速度显然会比用索引快。

如表zl_sybm（使用部门）一般只有几条记录，除了主关键字外对任何一个字段建索引都不会产生性能优化，实际上如果对这个表进行了统计分析后ORACLE也不会用你建的索引，而是自动执行全表访问。如：

select * from zl_sybm where sydw_bh=’5401’（对sydw_bh建立索引不会产生性能优化）

经常插入、删除、修改的表

对一些经常处理的业务表应在查询允许的情况下尽量减少索引，如zl_yhbm，gc_dfss，gc_dfys，gc_fpdy等业务表。

数据重复且分布平均的表字段

假如一个表有10万行记录，有一个字段A只有T和F两种值，且每个值的分布概率大约为50%，那么对这种表A字段建索引一般不会提高数据库的查询速度。

经常和主字段一块查询但主字段索引值比较多的表字段

如gc_dfss（电费实收）表经常按收费序号、户标识编号、抄表日期、电费发生年月、操作标志来具体查询某一笔收款的情况，如果将所有的字段都建在一个索引里那将会增加数据的修改、插入、删除时间，从实际上分析一笔收款如果按收费序号索引就已经将记录减少到只有几条，如果再按后面的几个字段索引查询将对性能不产生太大的影响。

对千万级MySQL数据库建立索引的事项及提高性能的手段

一、注意事项：

首先，应当考虑表空间和磁盘空间是否足够。我们知道索引也是一种数据，在建立索引的时候势必也会占用大量表空间。因此在对一大表建立索引的时候首先应当考虑的是空间容量问题。

其次，在对建立索引的时候要对表进行加锁，因此应当注意操作在业务空闲的时候进行。

二、性能调整方面：

首当其冲的考虑因素便是磁盘I/O。物理上，应当尽量把索引与数据分散到不同的磁盘上（不考虑阵列的情况）。逻辑上，数据表空间与索引表空间分开。这是在建索引时应当遵守的基本准则。

其次，我们知道，在建立索引的时候要对表进行全表的扫描工作，因此，应当考虑调大初始化参数db_file_multiblock_read_count的值。一般设置为32或更大。

再次，建立索引除了要进行全表扫描外同时还要对数据进行大量的排序操作，因此，应当调整排序区的大小。

9i之前，可以在session级别上加大sort_area_size的大小，比如设置为100m或者更大。

9i以后，如果初始化参数workarea_size_policy的值为TRUE，则排序区从pga_aggregate_target里自动分配获得。

最后，建立索引的时候，可以加上nologging选项。以减少在建立索引过程中产生的大量redo，从而提高执行的速度。