MySQL中索引最左前缀法则、索引失效情况、前缀索引、索引设计原则

最左前缀法则

• 联合索引中，最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列，如果跳跃某一列，索引将会部分失效（后面的字段索引失效）
• 举例假设有一个联合索引包含三个字段按顺序：name、age、status
• 也就表示where条件中必须包含name字段，否则就不会走该索引
• 如果where条件中只包含name、status，那么走该索引但是只走了部分，因为跳过了age列，跳过列后面的字段索引会失效

范围查询

• 联合索引中，出现范围查询（>、<），范围查询右侧的列索引失效
• 还是上述的例子有一个联合索引包含三个字段按顺序：name、age、status
• where name = ‘zhangsan’ and age > 18 and status = ‘0’，只有name和age字段走了索引，status字段索引失效
• where name = ‘zhangsan’ and age >= 18 and status = ‘0’，>=全部字段索引都会生效
• 所以，在业务允许的情况下，尽可能使用类似于>=或<=，而避免使用>或<

索引失效情况

• 索引列运算

  • 不要在索引列上进行运算操作，索引将失效
  • 比如对某个索引列进行了函数运算操作，将导致索引失效

• 字符串不加引号

  • 字符串类型不加引号，数据库存在隐式类型转换，索引将失效

• 模糊查询

  • 如果仅仅是尾部模糊匹配，索引不会失效，like ‘字符串%’
  • 如果是头部模糊匹配，索引失效，like ‘%字符串’

• or连接条件

  • 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及到的索引都不会被用到
  • 使用or连接的条件，必须左右两侧字段都有索引，索引才会生效

• 数据分布影响

  • 如果MySQL评估使用索引比全表更慢，则不使用索引
  • 因为索引是用来检索少量数据的，如果通过索引查询返回大批量的数据，则还不如走全表扫描来的快，此时索引就会失效

索引的SQL提示

• 问题：有一个字段既在单列索引，也在联合索引的最左列，会走哪个索引呢？

• 简介：SQL提示，是优化数据库的一个重要手段，简单来说，就是在SQL语句中加入一些人为的提示来达到优化操作的目的

• 语法

  • use index：建议MySQL使用哪一个索引完成此次查询（仅仅是建议，MySQL内部还会再次进行评估）

  • ignore index：忽略指定的索引

  • force index：强制使用的索引

• 示例：select * from tb_user use index (idx_name) where name = ‘zhangsan’

前缀索引

• 当字段类型为字符串（varchar、text、longtext等）时，有时候需要索引很长的字符串，这会让索引变的很大，查询时，浪费大量的磁盘IO，影响查询效率。

• 此时可以只将字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率

• 语法：create index index_name on table_name(column(n));

• 前缀长度

  • 可以根据索引的选择性来决定，而选择性是指不重复的索引值（基数）和数据表的记录总数的比值

  • 索引选择性越高则查询效率越高

  • 唯一索引的选择性是1，这是最好的索引选择性，性能也是最好的

    -- 求取前缀长度公式
    select count(distinct email) / count(*) from tb_user;
    select count(distinct substring(email,1,5)) / count(*) from tb_user;
    -- 根据查询效率和节约空间之间做一个平衡选择前缀长度
    

索引设计原则

• 针对于数据量较大，且查询比较频繁的表建立索引
• 针对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引
• 尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高
• 如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引
• 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率
• 要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率
• 如果索引列不能存储null值，请在创建表时使用not null约束它。当优化器知道每列是否包含null值时，它可以更好地确定哪个索引最有效地用于查询