产品中心
小白白跑去鹅厂面试，面试官提出了一个很实际的问题： mysql增加索引，那些情况会失效呢？谈一下实际工作中遇到的情况。我们的小白白又抛出了白氏秘籍：用不用索引，找DBA小姐姐！啊？这是你面试哈，还是DBA小姐姐面试呀。
日常处理mysql问题中，往往通过增加索引来提高查询速度，但在有些情况下，执行过程中并没有按照我们的预期结果执行，也就是说，即使字段加了索引，但现实也没有使用到，到底是什么地方出了差错，以下我们将一探究竟。
我们将对以下表结构进行实际案例分析：
为什么会出现这样的情景呢？因为 student表中10W多条数据的值全都是'name'，索引基数太小，所以在执行<>'1name'查询时，实际上要查询条数为10多W条，如果走了name字段索引，其实和全表查询没什么区别，况且，执行name字段索引，最终还是要转换为主键索引（二级索引查询都会转换为主键查询），所以索引优化器的优化结果是不走name索引。然而在执行<>'name'查询时，优化器优化结果是走name索引，因为，<>'name'的查询行数很小，大部分条数name字段的值都是'name'。
索引优化器实例二：
同理，前缀like匹配是走索引，但是，以下却展示了不一样的结果：
为什么会这样呢？请小伙伴们参考实例一仔细思考一下。
如何指定优化器执行固定的索引？
索引优化器的存在，我们就没办法指定强制走我们指定的索引？答案就是通过 force index强制来实现，
执行语句和分析结果如下图所示：
实际应用中，应该牢记上述索引优化的原则，比如在实际工作中，由于索引优化器选错索引，导致数据查询缓慢，阻塞线上业务，而当时的解决办法，就是上述文章的分析过程，以及采用force 强制索引才解决的，前车之鉴，希望广大读者避免踩坑。
到此这篇关于mysql or走索引加索引及慢查询的作用的文章就介绍到这了,更多相关mysql or索引 内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
