postgresql 中 seq scan 扫描的行数与预期不符是怎么回事
我的t_device 表里有27w条记录，建立了一个联合索引 （oui,sn），现在我 EXPLAIN ANALYZE select * from t_device where sn ='999999999265986' 
由于是联合索引，且该查询只用了联合索引最后一个字段，所以不能走索引，只能seq scan ，这我能理解，但是为什么seq scan 只扫描了一行？
本问题来自阿里云开发者社区的【11大垂直技术领域开发者社群】。 https://developer.aliyun.com/article/706511 点击链接欢迎加入感兴趣的技术领域群。
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
在你的查询中，EXPLAIN ANALYZE 显示只扫描了一行，这通常意味着数据库优化器已经足够智能，它识别到通过SN（作为联合索引的一部分）可以直接定位到唯一的一行数据。尽管理论上对于非前导列的查询可能需要进行全索引扫描或表扫描，但在某些数据库系统中，特别是当优化器能够判断出查询条件能精确匹配到少数或单个记录时，它可能会选择一种更高效的执行计划。
具体到你的场景，即使sn不是联合索引的前导列，如果数据库系统（如PostgreSQL、MySQL的InnoDB存储引擎等）支持所谓的"索引覆盖扫描"（Index Covering Scan），那么查询优化器可能会利用到这一点。索引覆盖扫描意味着所有需要的数据（即select *中的列）都能从索引中直接获取，而不需要回表到原数据行，这样可以显著提高查询效率。在这种情况下，即便没有直接使用到索引的前导部分，优化器也可能通过索引快速定位到满足条件的行，从而避免了全表扫描。
简而言之，虽然你预期的是一个全表扫描（seq scan），但实际上优化器找到了一个更高效的方法来处理这个特定查询，可能是通过某种形式的索引跳跃扫描或者直接利用索引覆盖特性，仅需访问索引中与sn='999999999265986'匹配的条目，因此只扫描了一行。
