不错：果然是大神，学了老师的45讲；索引的理解和使用比过去好了许多；不过再次听又有新的收获-怪不得最近explain出来的表有索引却还是全表扫描了😀

老师太棒了， 扫描行数才是判断一个sql语句最关键的因素。

最后一个优化不明白的同学，我给出我的拙见。我认为使用like '张%' 时是绕不开左前缀匹配的，也就是说不论age是多少都要进行匹配，所以扫描行数取决于姓张的人数。优化后不需要左前缀匹配了，扫描的行数就是姓张且年龄是8的，所以行数大大减少了。 如有问题，希望大家批评指正。

丁奇老师的课都是干货，听了停不下来啊。墙裂推荐！

牛逼，牛逼，大牛就是厉害👍，现在才知道扫描行数才是判断执行效率的最佳手段

老师，最后那里还是不是很明白，建立一个虚拟列，和 age 的联合索引，然后姓张的记录不是有 8000 万条吗，那还是要扫描 8000 万次再回表 100 万次，为什么会只扫描 100 万次呢？麻烦老师解答了。哈哈 这么多文章，就感觉是老师的 MySQL 讲的很好。赞٩(๑^o^๑)۶

喜欢这种类型的每日一课！！！！！！

如果不是声音和专栏音频一样，我都怀疑这是不是丁奇老师😂

使用索引本来就是减少扫描行数啊

学到了虚拟列

一般线上的数据库稳定运行后是不会，也不能升级的，又要怎么实现这些优化呢🤔（旧项目感觉用5.5的较多）

1.索引和慢查询没有必然联系
2.检查一个查询语句的执行效率最终要看的是扫描行数
3.使用虚拟列和联合索引来提升复杂查询的执行效率

最后一个优化的理解: 索引结构是在姓张的同时，age是有序的，所以只扫描了姓张且年龄等于8的100万行。

这种视频形式太棒了

林老师的课满满的干货，谢谢！要是每日一课也配文字稿就更好了。

大神怎么这么胖了啊，但课还是一如既往的精彩，实用！

select * from people where age=8 and name like '%张' ； 把age放前面，用到索引，能解决问题吗？

丁奇老师讲课真是深入浅出，让自己豁然开朗。SQL被记录到慢查询日志，并不代表这条SQL没有用到索引，这其中有很多原因，但证明这条SQL执行时花费的时间超过系统设置的long_query_time参数的值，我们索引优化的最终目的是减少查询目标数据的所要执行的扫描行数，...还讲到了 MySQL 5.6中的 index condition pushdown ,MySQL 5.7中的虚拟列

联合索引的第二个字段不会排序吗？如果是联合索引为什么不优先第一个字段排序，如果第一个字段一样根据第二个字段排序，这样就不用在联合索引树上遍历完所有第一个字段一样的值了啊