a 复合型数据库索引按最左作为前缀的标准挑选,比如
create index idx_a_b_c on test (a,b,c); #给a,b,c创建的数据库索引
where a=xxx
where a=xxx and b=xxx
where a=xxx and b=xxx and c=xxx
where a=xxx and c=xxx
where b=xxx and a=xxx
前三种状况采用了数据库索引,第四种仅用到a的数据库索引,最终一种a和b都没用到数据库索引
假如where标准中另外有精准标准(=,in)和范畴标准,那麼靠左的列先应用了范畴标准则靠右边的列则用不上数据库索引,由于mysql索引只适用一个并且是近期的范畴数据库索引:
idx_a_b_c_d (a,b,c,d)
where a=? and b=? and c>? and d<?
a,b也没有应用范畴标准,因此 c会采用数据库索引,可是c用了范畴标准,因此 d没用到数据库索引
where a>? and b=? and c=? and d<?
a采用数据库索引,b,c,d没用到
因此 范畴搜索尽量放到最终
优: select * from test where a=10 and b>50
优: select * from test where order by a
差: select * from test where order by b
差: select * from test where order by c
优: select * from test where a=10 order by a
优: select * from test where a=10 order by b
差: select * from test where a=10 order by c
优: select * from test where a>10 order by a
差: select * from test where a>10 order by b
差: select * from test where a>10 order by c
优: select * from test where a=10 and b=10 order by a
优: select * from test where a=10 and b=10 order by b
优: select * from test where a=10 and b=10 order by c
优: select * from test where a=10 and b=10 order by a
优: select * from test where a=10 and b>10 order by b
差: select * from test where a=10 and b>10 order by c
因此 在创建复合型数据库索引的情况下,越常见的字段放越左侧,上边常见性是a>b>c因此 ,界定的情况下是(a,b,c)
b 假如一个 Like 句子的查询条件不因使用通配符起止则应用数据库索引。
如：%车 或 %车% 不应用数据库索引。
车% 应用数据库索引。
c 应用涵数
要是没有应用根据涵数的数据库索引，那麼where子句中对存有数据库索引的列应用涵数时，会使优化器忽视掉这种数据库索引。下边的查看就不容易应用数据库索引：
Sql编码 个人收藏编码
select * from staff where trunc(birthdate) = '01-MAY-82';
可是把涵数运用在标准上，数据库索引是能够起效的，把上边的句子改为下边的句子，就可以根据数据库索引开展搜索。
Sql编码 个人收藏编码
select * from staff where birthdate < (to_date('01-MAY-82') 0.9999);
d 较为不配对的基本数据类型
较为不配对的基本数据类型也是难以发觉的特性难题之一。
下边的事例中，dept_id是一个varchar2型的字段名，在这个字段名上面有数据库索引，可是下边的句子会实行全表扫描仪。
Sql编码 个人收藏编码
select * from dept where dept_id = 900198;
这是由于oracle会全自动把where子句转化成to_number(dept_id)=900198，便是3常说的状况，那样就限定了数据库索引的应用。
把SQL句子改成以下方式就可以应用数据库索引
Sql编码 个人收藏编码
select * from dept where dept_id = '900198';
e 数据库索引列的范畴搜索
假如某列界定了数据库索引,对该列应用 where between and / > / < 也是会应用到数据库索引的,会采用数据库索引范畴搜索;可是假如这一范畴很大,数据库查询感觉成本费太高，很有可能会变为全表数据库索引。
f 一个基本常识 对常常做为检索标准(where),常常排列(order),常常排序(group by) 的字段名创建数据库索引能提高工作效率
假如做为数据库索引的字段名有越大同样的值,那麼这一数据库索引的高效率越低
g 有关多表联查时应用到的数据库索引的状况
在多表联查的情况下，数据库查询会特定一个表为驱动器表，另一个表为被驱动器表
以下：
select a.col1,b.col2 from a join b on a.id=b.id
在其中id是2个表的主键,如果a表被判断为驱动器表,那麼数据库查询很有可能会全表扫描仪a表,并且用a表的每一个id检测b表的数据库索引搜索配对的纪录。
那麼大家先掌握在join联接时哪一个表有驱动器表，哪一个表有被驱动器表：
1.当应用left join时，左表是驱动器表，右表是被驱动器表
2.当应用right join时，右表时驱动器表，左表是驱动器表
3.当应用join时，mysql会挑选信息量较为小的表做为驱动器表，大表做为被驱动器表，我们知道假如大表做驱动器表，会全表扫描驱动表，那麼便会高效率很低。换句话说join的状况下，数据库查询会全自动做提升。
join查看中，始终是以小表驱动器大表。
比如: A是小表，B是大表
应用left join 时，则应当那样写select * from A a left join B b on a.code=b.code
A表时驱动器表，B表有被驱动器表
检测：A表140好几条数据信息，B表二十万上下的信息量
select * from A a left join B b on a.code=b.code
实行時间：7.5s
select * from B b left join A a on a.code=b.code
实行時间：19s
结果：小表驱动器大表好于大表驱动器小表
join查看在有数据库索引标准下
驱动器表有数据库索引不容易应用到数据库索引
被驱动器表创建数据库索引会应用到数据库索引
在以小表驱动器大表的状况下，再给大表创建数据库索引会进一步提高实行速率
在我做的一个新项目中有一个查看,这一查看牵涉到二张表:归类表和文章内容表
归类表 type 有20条数据信息,文章内容表 arts 有七十万条数据信息,文章内容表有一个字段名是is_send,用于标识文章内容是不是推送,is_send字段名的值仅有2个。我想查每一个归类下有多少一篇文章
select t.id,t.name,count(*) as arts_count from arts a join type t on a.tid=t.id group by t.id;
我还在arts中对tid也干了数据库索引
上边应用了join因此 ,默认设置以type做为驱动器,并且排序的目标t.id是主键,主键毫无疑问也是干了数据库索引的,因此 上边的查看高效率不容易低,只花了一秒
可是假如加了一个标准 is_send=0
select t.id,t.name,count(*) as arts_count from arts a join type t on a.tid=t.id where is_send=0 group by t.id;
那麼,查看時间变成了12秒
缘故是is_send沒有创建数据库索引,因此 以他为标准会对arts表全表扫描仪;
更重要的是is_send仅有0和12个值,因此 即便对它创建了数据库索引,高效率也只有提升一半,并且還是0和1遍布较为匀称的状况下才可以提升一半,假如0占百分之二十90,1占百分之二十10,那麼where is_send=0 提升的高效率不上百分之二十10。
h 根据主键去取数据信息是更快的,根据二级数据库索引(即一般的 index)则要开展2次数据库索引搜索,先寻找二级数据库索引再依据二级数据库索引寻找主键,再依据主键寻找相匹配的纪录
i 防止反复对一个列建立好几个数据库索引,那样会消耗室内空间,并且对一个列建立好几个数据库索引不容易出错
j 应用覆盖索引能够进一步提高特性
覆盖索引指全部数据信息能够从数据库索引中获得,不用去载入物理学纪录。比如
idx_a_b_c
select a,b from tb1 where a=? and b=? and c=?
这就是覆盖索引,也防止了二次数据库索引搜索
k 运用数据库索引排列
mysql有二种方法能够造成井然有序的結果:一种是文件排序(filesort)对纪录排列,另一种是扫描仪井然有序的数据库索引排列
文件排序,mysql是将获得的数据信息在运行内存中排列,假如对小量数据信息开展排列会迅速,但如果是对很多数据信息排列便会比较慢
order by create_time 便是文件排序
order by id 便是数据库索引排列
可是以前做新项目,全是对分页查询数据信息排列,每一页不超过100条数据信息,因此 用文件排序都不慢
像复合型数据库索引在排列的情况下还要遵照流板列和最左作为前缀标准,不然就算不上数据库索引排列
idx_a_b_c
order by a,b,c
where a=? and b=? order by c
这两个都复合型数据库索引排列
能够根据 explain 的extra查询是不是文档数据库索引,表明filesort便是文档数据库索引
l 防止沉余数据库索引
沉余数据库索引便是:
我界定了a字段名为数据库索引,有界定了(a,b)的复合型数据库索引
可是有一种状况是要界定沉余数据库索引:例如本来我对a创建了数据库索引,a是一个整形列,假如忽然想将a数据库索引拓展为a,b数据库索引,而b是一个长短较长的字符串数组列,那麼数据库索引会非常大。这时就迫不得已加上一个新的复合型数据库索引，保存本来的数据库索引
M 应用更短的数据库索引
例如 我想对文章内容的题目创建数据库索引，题目会较长，这时创建的数据库索引会非常大（我们知道创建数据库索引会将数据库索引字段名独立放进一个表格中储存），因此我们可以应用作为前缀数据库索引，即只对题目的前是多少字符开展数据库索引
index title (title(6))
便是只对题目的前6个标识符开展数据库索引,那样存到数据库索引表的就并不是全部题目只是题目的前6个标识符
可是要保证所挑选的作为前缀的长短的內容绝大多数值是唯一的
n where不因数据库索引字段名为标准的时候会全表扫描仪;
where以数据库索引为标准时,假如数据库索引高效率不高时,mysql依然会全表扫描仪;
因此 不必对多余的字段名创建数据库索引,比如性別
o innodb的主键不可以过长,以避免 二级数据库索引过大。主键一般全是选整形
