深圳外贸网站商城,相片制作图片,建设网站哪里便宜,网站建设 域名 数据库避免索引失效原则(二)注#xff1a;继上一篇文章继续讲解#xff1a;避免索引失效原则(一)https://www.cnblogs.com/StanleyBlogs/p/10482048.html#4195062作者 #xff1a; Stanley 罗昊【转载请注明出处和署名#xff0c;谢谢#xff01;】体验SQL优化中的概率情况在上一…避免索引失效原则(二)注继上一篇文章继续讲解避免索引失效原则(一)https://www.cnblogs.com/StanleyBlogs/p/10482048.html#4195062作者 Stanley 罗昊【转载请注明出处和署名谢谢】体验SQL优化中的概率情况在上一篇文章结尾处我们在执行查询计划的时候却发现我明明加了索引并且也满足了使用索引的条件但是给我的优化结果却是失败从而得出一个结论便是优化是概率的也就跟彩票一样不可能百分之百优化成功的但是彩票我们都知道全凭运气但是这里就不一样了我们需要了解SQL优化概率背后到底是谁导致它优化失败的首先我们来了解下出现概率优化的原因因为在SQL底层中有一个服务层服务层有一个SQL优化器当我们写一条语句虽然我们手动优化了但是优化器觉得你优化的不太合适它可能会进行一些自己的干扰干扰完毕之后就执行结果就不再是你理想中的那样了所以这个优化器有的时候会阻扰我们的优化工作接下来我们就通过几个例子来体验一下我们设想的优化和实际不一样的一些操作首先我们需要建立一个复合索引alter table book add index idx_book_at(authorid,typeid);建立完索引后我们进行一个简单的查询explain select * from book where authorid 1 and typeid 2;通过结果我们可以发现复合索引全部生效了那么接下来我们将体验一下让它产生概率问题我把上面的SQL语句拿过来改改explain select * from book where authorid 1 and typeid 2;我们查看执行结果结果很明显给authorid 添加了一个大于号这样则导致了右侧索引全部失效包括自身从而得出一个结论复合索引中如果有则自身已经后面的索引都将会失效但是这次我SQL语句再次改变奇怪的事情将会发生explain select * from book where authorid 1 and typeid 2;这次我把这个大于号加给了typeid字段显然它也是索引刚才我说了添加大于号会导致自身并且右侧索引全部失效但是接下来现在我们又发现结论又不对了我明明自身肯定失效啊为啥这次偏偏却两个都生效了原因就是概率情况咱们在实际执行时复合索引全部使用了并不是刚才我们说的那个结论自身失效及右侧全部失效当然这个情况是大部分情况下都是有用了仅有小部分情况会出现明显的概率问题刚才我写了几个例子看起来不是特别的明显下面我将写几个比较明显的例子来体验一下概率问题首先我们编写一条SQL语句explain select * from book where authorid 1 and typeid 2;此时我把authorid改成了小于号我们看结果我们看到了此时我们换层了小于号发现没有全部失效此条语句得出结论两个索引仅生效了一个因为范围查询仅对自身生效对后面的不会生效接下来我再改变一下SQL语句explain select * from book where authorid 4 and typeid 2;首先看清楚我现在没有更改任何符号仅把authorid小于号后面的数字条件写成了4再来看看执行结果我们惊奇的发现竟然全部失效了我明明就光改了一个数字而已就全部失效了刚才还有一个生效现在一个都没有了这到底是为什么呢通过后两个例子我们发现就改了一个数索引都不一样了所以这就是SQL优化的一个概率因此得出结论我们学习的索引优化是一个大部分情况都适用的结论但由于SQL优化器等原因该结论不是100%正确因为SQL的底层把我们写的语句给干扰了一般而言范围查询( in)之后的索引失效仅对自身生效补救那么如果这样一直干扰下去我们到底还优不优化了就没有办法来补救这个概率问题吗答案是有的尽量使用索引覆盖 (using index)在Extra里面出现这个就表示你的SQL语句不会出错如果你怕在优化中出现概率问题那么你就朝着using index这个方向去优化因为出现这个就代表你这条SQL100%生效不会出现概率问题比如我现在有 a b c三张表;现在我编写一条SQLselect a,b,c from 表名 where a ... and b ...;在select后面我们用到了abc 并且查询条件也是a b 没有跨列满足最佳做前缀最主要的是查询条件也是索引所有的索引你都按照规则全部用上了这样就会出现索引覆盖大大的提高了系统性能like尽量以“常量”开头不要以%开头否则索引失效我现在编写一条SQL语句;select * from 表名 where name like %x%;首先这条sql语句是查询表名中name 带有x的数据如果你这样写了如果name是索引那么name将会失效接下来我结合数据库进行证实一下explain select tname from teacher where tname like %x%首先tname我是加了一个索引的但是看一下看一下执行结果没有失效因为出现了覆盖索引因为tname是索引我刚好去查tname所以出现了覆盖索引导致本次查询没有失效下面我把它换成“*”值得注意的是在开发过程中严禁出现“*”本次为了说明问题所以换成“*”执行结果索引全部失效原因我刚才也说过了在模糊查询是不要以百分号开头如果想避免失效可以变成以下这种写法explain select tname from teacher where tname like x%这样虽然可以保证索引不会失效但是我们在项目开发中难免遇到模糊查询所以也是有解决方案的刚才我不小心也试出来了因为我使用了索引覆盖你想用模糊查询可以但是你需要有索引覆盖刚才我查询tnametname本身就在索引里面所以出现了索引覆盖如果必须使用模糊查询那么就把查询条件以及需要查询的字段全部声明成索引即可尽量不要使用类型转换(显示、隐式)否则索引失效这里我就简单的举个例子select * from teacher where tname abc;此时tname是varchar类型这个时候你你却写成int类型select * from teacher where tname 123;人家本来需要单引号的字符串类型结果你给人家弄了一个去掉引号的int类型所以索引就会失效尽量不要使用or否则索引失效select * from teacher where tname or tcid1;这条sql语句就会导致索失效所以要避免使用or这个关键字经过测试发现or回导致以左的索引失效也就是tname这个字段的索引失效了今日感悟努力就一定会有收获心无旁骛