MYSQL 索引优化

1:索引性能优化测试:

我们通过全值匹配测试 来对索引优化来进行一个了解:

这里是我们需要示列的表格 我们通过where 使用这些联合索引 对数据进行一个全值匹配对性能优化的测试 

通过EXPLAIN 来对查询数据性能进行检测(这里介绍一下EXPLAIN  这个是用来测试sql性能优化的)

列1:

我们通过顺序使用联合索引进行全条件检索匹配 这样来看性能是最优的 

列2:

这样进行匹配查询 出现了索引失效的问题  type=ALL 显示的是全表查询  这样是因为没有遵循最左前缀法则 导致的索引失效 这里要讲一下最左前缀法则 这个问题来源于B+树 在B+树结构中 索引其实是通过键值在叶子节点中进行存储的 所以每次只能匹配一个值确定索引关系 。MySQL创建联合索引的规则是首先会对联合索引的最左边第一个字段排序 而每次它必须根据最左边第一个字段排序，在第一个字段的排序基础上，然后在对第二个字段进行排序   

列3 :

我们通过将中间的条件 进行跳过 可以发现 我们此时性能明显就下降 此刻的key-len它的值是74 

1.1 :在索引优化中那些方式会导致索引失效 

使用函数: 在有一些场景下会使用到函数去匹配我们的数据 但是这样会导致我们的索引失效   这里通过name去对最左侧3个字符进行匹配 发现在使用函数以后这样会导致  type=ALL 全表扫描 因为索引在使用了函数 会导致索引会在每个节点进行运算 导致索引全表查询 和索引失效

列2:  通过函数对日期进行匹配范围查询发现索引失效 

还有一种方式也会导致索引失效就是使用or 进行匹配 这样也会导致索引失效

使用!= 导致索引失效 

所以尽可能不要使用 像函数 计算  or 类型转换 != 等....这样可能导致索引失效

当然 可以使用 force index() 方法强制使用这个索引  解决 or  != 导致的索引失效的问题 进行索引优化

索引优化 模糊查询 优化测试

列1：通过前模糊 进行查询 我们发现type=all 索引是失效的  因为B+树在使用字符进行索引的时候太会先找到最左侧第一个字符进行排序 当我们使用前模糊的时候 无法确认第一个匹配字符 只能够走全表扫描

列2:

通过列2我们发现 B+树通过第一个字符去匹配到对应的字符  所以索引是没有失效的

列3:

我们通过全模糊匹配 如果不用覆盖 会导致全表扫描 索引失效  必须先覆盖索引 比如联合索引条件为 name 我们必须先对name 这个字段进行查找覆盖索引项

类型转换导致的索引失效:

类型转换导致的索引失效 其实本身就是我们在sql中输入的类型和对应的类型不匹配 所以才会导致索引失效的问题产生  

列1: 这里的name实际的类型是varchar '' 而我们索引项条件是int类型 导致类型不匹配所以索引会失效

范围查询 值过大 导致 索引失效 

列1 : 我们可以通过前面的 覆盖的方法进行 可以针对这种进行优化

  拆成小段的方式已经试了行不通........