1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
| 1.选择唯一性索引(尽量考虑这个) 唯一性索引的值是唯一的,可以更快速的通过该索引来确定某条记录 2.为经常需要排序、分组和联合操作的字段建立索引 3.为常作为查询条件的字段建立索引 3.1 经常查询 3.2 列值的重复值少 注:如果经常作为条件的列,重复值特别多,可以建立联合索引 4.尽量使用前缀来索引 如果索引字段的值很长,最好使用值的前缀来索引 """ 5.限制索引的数目 索引的数目不是越多越好。每个索引都需要占用磁盘空间,索引越多,需要的磁盘空间就越大。 修改表时,对索引的重构和更新很麻烦。越多的索引,会使更新表变得很浪费时间。
6.删除不再使用或者很少使用的索引 表中的数据被大量更新,或者数据的使用方式被改变后,原有的一些索引可能不再需要。数据库管理 员应当定期找出这些索引,将它们删除,从而减少索引对更新操作的影响。 """
*******************不走索引的情况******************* 1.没有查询条件,或者查询条件没有建立索引 """ 在业务数据库中,特别是数据量比较大的表,是没有全表扫描这种需求。 1)对用户查看是非常痛苦的。 2)对服务器来讲毁灭性的。 3)SQL改写成以下语句: #情况1 #全表扫描 select * from table; #需要在price列上建立索引 selec * from tab order by price limit 10; #情况2 #name列没有索引 select * from table where name='zhangsan'; 1、换成有索引的列作为查询条件 2、将name列建立索引 """ 2.查询结果集是原表中的大部分数据大概25%以上 哪怕建了索引也不会走,所以这个时候一般会用limit限制 3.索引本身失效,统计数据不真实 索引有自我维护的能力 对于表内容变化比较频繁的情况下,有可能会出现索引失效。 4.查询条件使用函数在索引列上或者对索引列进行运算,运算包括(+,-,*等) 错误的例子:select * from test where id-1=9; 正确的例子:select * from test where id=10; 5.隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误 create table test (id int ,name varchar(20),telnum varchar(10)); insert into test values(1,'zs','110'),(2,'l4',120),(3,'w5',119),(4,'z4',112); explain select * from test where telnum=120; alter table test add index idx_tel(telnum); explain select * from test where telnum=120; explain select * from test where telnum=120; explain select * from test where telnum='120'; 6. <> ,not in 不走索引 单独的>,<,in 有可能走,也有可能不走,和结果集有关,尽量结合业务添加limit or或in尽量改成union EXPLAIN SELECT * FROM teltab WHERE telnum IN ('110','119'); EXPLAIN SELECT * FROM teltab WHERE telnum='110' UNION ALL SELECT * FROM teltab WHERE telnum='119' 7.like "%_" 百分号在最前面不走 EXPLAIN SELECT * FROM teltab WHERE telnum LIKE '%110'; EXPLAIN SELECT * FROM teltab WHERE telnum LIKE '31%'; 8.单独引用联合索引里非第一位置的索引列
|