mysql8.0索引跳跃扫描如何使用_优化联合索引非首列查询
MySQL 8.0 索引跳跃扫描：一个被误解的“优化捷径”
免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈
提到MySQL 8.0的索引跳跃扫描（Index Skip Scan），很多人的第一反应是：“终于可以不用管联合索引最左前缀原则了！” 但事实果真如此吗？先泼一盆冷水：它并非一个可以随意开关的“万能钥匙”，而是优化器在特定场景下才会动用的“秘密武器”。盲目依赖它，不仅可能达不到预期效果，反而会掩盖真正的索引设计问题。
什么时候会触发 skip_scan？
优化器决定是否启用跳跃扫描，背后有一套精密的成本核算逻辑，核心在于三个条件的权衡：
- 最左列基数必须极低：这是前提中的前提。通常要求被“跳过”的第一列，不同值的数量要控制在10到20个以内。想想看，像
gender（性别）、status（状态）、is_deleted（删除标记）这类字段，就非常符合条件。 - 后续查询列选择性要高：查询条件中实际用到的第二列、第三列，必须能高效过滤数据。例如，在
(status, city)索引中查询city='Beijing'，如果北京的用户只占一小部分，那么跳跃扫描才有价值。 - 执行计划有明确标识：最终，你需要通过
EXPLAIN命令来验证。只有当type显示为range或ref，并且Extra列明确出现Using index for skip scan时，才能确认它真的生效了。
这里有个关键限制：skip_scan目前主要服务于简单的单表查询。对于涉及多表JOIN、GROUP BY聚合或DISTINCT去重的复杂场景，它就无能为力了。
optimizer_switch 开关怎么调？
这个功能默认是开启的，但最好亲手确认一下。执行以下命令：
SHOW VARIABLES LIKE 'optimizer_switch';
在输出结果里，你应该能找到skip_scan=on。如果发现是off，可以在当前会话中临时开启：
SET SESSION optimizer_switch='skip_scan=on';
⚠️ 请注意，通常不建议使用SET GLOBAL进行全局开启。原因在于，跳跃扫描的本质是“枚举首列所有可能值，然后为每一个值执行一次子范围扫描”。试想，如果首列有1000个不同的值，那么这个查询就会被拆分成1000次小扫描。在首列基数不低的场景下，这种操作的代价可能比全表扫描还要高。
为什么 EXPLAIN 看不到 Using index for skip scan？
明明条件好像都符合，为什么执行计划就是不显示呢？以下几个原因最为常见：
- 首列基数过高：这是最常见的“拦路虎”。像
user_id、order_no这种几乎唯一的值放在联合索引首位，优化器会直接放弃跳跃扫描的评估。 - 查询条件“不干净”：查询中使用了
OR、前导模糊匹配LIKE '%xxx'、函数包裹列，或者发生了隐式类型转换，都会破坏索引的有效使用。 - 数据量太小或统计信息过时：当表数据量极小时，优化器可能认为全表扫描更快。此外，如果表的统计信息没有及时更新，优化器的成本估算就会失准，运行
ANALYZE TABLE命令刷新一下往往能解决问题。 - 强制使用了索引：如果在查询中使用了
FORCE INDEX，就等于剥夺了优化器自主选择执行路径的权利，自然也就屏蔽了跳跃扫描的可能性。
所以，判断是否走了跳跃扫描，不能只看key字段用了哪个索引，Extra列里的信息才是最终的“判决书”。
比 skip_scan 更可靠的做法是什么？
说到底，索引跳跃扫描更像是一种“亡羊补牢”的兜底策略，而非数据库设计的黄金法则。追求稳定和极致的性能，下面这些做法往往更靠谱：
- 调整索引列顺序：一劳永逸的方法，就是根据实际的查询频率，重新设计联合索引的列顺序。例如，如果经常按
city查询，那么就把(status, city, create_time)调整为(city, status, create_time)。 - 建立单独索引：如果某个非首列的查询频率极高，且业务对写入性能不敏感，为其单独建立一个索引是最直接的方案。
- 善用隐藏索引：在不确定新索引效果时，可以先用
INVISIBLE属性创建一个隐藏索引进行测试，验证无误后再将其“转正”，这能避免对线上业务造成冲击。 - 考虑分区表：对于低基数列（如地区、状态）结合高频等值查询的场景，使用
LIST分区可能是一个比依赖跳跃扫描更优雅、更可控的解决方案。
最后必须提醒一点：跳跃扫描并没有减少索引维护的成本。那个庞大的联合索引依然存在，每次数据写入或更新时，你仍需为它付出额外的I/O和计算开销。它只是在“读”的时候，偶尔帮你省了点力气而已。在优化之路上，理解原理远比记住技巧更重要。
相关攻略
MySQL 8 0 索引跳跃扫描：一个被误解的“优化捷径” 提到MySQL 8 0的索引跳跃扫描（Index Skip Scan），很多人的第一反应是：“终于可以不用管联合索引最左前缀原则了！” 但事实果真如此吗？先泼一盆冷水：它并非一个可以随意开关的“万能钥匙”，而是优化器在特定场景下才会动用的“
RC降低死锁概率的根本原因是默认不使用间隙锁，仅对命中行加记录锁，锁范围更小、冲突更少；而RR对范围条件自动加Next-Key锁，易引发循环等待死锁。 RC 隔离级别为什么能降低死锁概率 说到底，RC级别降低死锁概率的核心秘诀，就在于它“不轻易动用”间隙锁（Gap Lock）——除了检查唯一键或外键
MySQL索引使用率：一个被过度简化的伪命题 在数据库优化的讨论中，“索引使用率”常常被当作一个关键指标。但这里有个根本性的认知偏差：MySQL本身并不提供，也计算不出一个精确的“索引使用率”百分比。 市面上有些工具或文章，试图用sys库视图的数据做除法，得出诸如“某索引使用率95%”的结论，这种做
MySQL 5 7 到 8 0 升级：字符集与排序规则的“暗礁”与避坑指南 先明确一个核心事实：从 MySQL 5 7 升级到 8 0，字符集和排序规则的默认设置发生了根本性改变。这绝非一个简单的版本号变化，而是一个可能直接导致数据乱码、查询异常甚至业务逻辑错误的“硬切换”。 MySQL 5 7 和
慢查询日志：从开启到分析，避开那些“开了等于没开”的坑 想优化数据库性能，慢查询日志是绕不开的起点。但这里有个常见的误区：你以为开启了全局日志就万事大吉？如果关键的阈值没设对，很可能跑上一天也抓不到一条有效记录。而在分析工具的选择上，pt-query-digest凭借其SQL归一化、细粒度指标分析和
热门专题
热门推荐
WF-1000XM4蓝牙配对指南：两种触发路径，一个核心逻辑 给索尼WF-1000XM4配对，核心其实就一件事：让耳机进入“被发现”的状态。有意思的是，它并不依赖某个单一的物理按键，而是提供了双路径的触发方式。根据官方的操作指南以及多次的实际测试，无论是通过充电盒上的功能键，还是直接操作耳机本身，都
迅捷路由器桥接失败怎么办？原因分析与解决方法大全 许多用户在使用迅捷路由器进行无线桥接时，经常遇到“显示已连接但无法访问互联网”的问题。实际上，这通常并非设备故障，而是由于关键的网络参数配置不当或主副路由器之间的通信协调不畅所致。简单来说，就是两台路由器之间的设置没有完全匹配。那么，具体哪些环节最容
迅捷路由器无线桥接：手机端设置实操指南 使用手机为迅捷路由器配置无线桥接（WDS），听似专业，实则通过官方适配的移动端界面就能轻松完成。只要满足几个关键条件，您仅需一部手机即可高效架设扩展网络。操作时，请先将手机连接至副路由器的默认无线信号（通常以FAST_XXXX格式命名），随后在Safari或C
小米空调联网故障全解析：从新手排查到专家级修复，步步为营 当小米空调始终无法成功连接网络时，许多用户的第一反应往往是联系售后或怀疑设备故障。然而实际情况是，超过九成的联网失败案例，根源都出在网络配置、操作流程这类“软性”环节，空调硬件本身出问题的概率极低。解决问题的核心在于掌握系统化的排查思路，按照
有线音响加装蓝牙功能并不复杂，普通用户借助外置蓝牙接收器即可在十分钟内完成升级 想给家里的老款有线音响“剪掉”那根烦人的音频线？其实这件事没你想的那么复杂。普通用户完全不需要动用电烙铁，借助一个小巧的外置蓝牙接收器，十分钟之内就能搞定升级。核心操作很简单：确认你的音箱背面有标准的3 5毫米或RCA音