本文深入探讨了MySQL中的BTree索引和Limit优化。通过理解BTree索引的结构，解释了普通索引和聚集索引的工作原理，并通过实验验证了Limit在全表扫描和索引查询中的性能差异。提出了优化Limit查询的策略，包括使用延迟查询和子查询，显著减少了回表操作，提升了查询效率。
在招聘开发中，我看到简历上面只要写了熟悉SQL优化我就会问他：limit 如何优化？
因为在系统中随着业务的发展数据库表存储的数据越来越多，原先的SQL在没做优化的情况下会变得越来越慢稍不注意就会造成我们线上系统的崩溃。
大多数都说连表查询（延迟查询）、子查询这两种，只有一个说是看场景。确实，如果场景业务不复杂没有什么过滤条件那么使用主键自增ID进行范围查询无疑是一个最好的选择！但我问为什么要这么做时却没人能够回答出来。
BTree索引（innoDB）
首选我们新建索引的普遍都是使用BTree索引，而BTree索引的数据结构则是B+Tree。所谓知己知彼百战百胜，只有先了解B+Tree的结构才能更好地进行优化！（盗用百度上的一张草图 哈哈哈）
从这个结构上，第一层跟第二层存储只是索引并不是真正的数据直到第三层时则是真正的值。例如这个是age字段的索引，执行select * from user where age = 5 语句，根据这个图则需要做三次IO操作才能准确找到5。首先在第一个节点【8，15】比较值，小于8则访问左节点【2，5，8】，在左节点中虽然有5但还是需要继续向下访问节点【3，5】，由于【3，5】没有
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
