最左前缀法则
- 联合索引中，最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列，如果跳跃某一列，索引将会部分失效（后面的字段索引失效）
- 举例假设有一个联合索引包含三个字段按顺序：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值时，它可以更好地确定哪个索引最有效地用于查询
