为什么SQL关联查询在单索引下依然慢？检查关联字段的选择性是否过低

来源：Python编程网作者：行者头衔：草根站长

导读：本期聚焦于小伙伴创作的《为什么SQL关联查询在单索引下依然慢？检查关联字段的选择性是否过低》，敬请观看详情，探索知识的价值。以下视频、文章将为您系统阐述其核心内容与价值。如果您觉得《为什么SQL关联查询在单索引下依然慢？检查关联字段的选择性是否过低》有用，将其分享出去将是对创作者最好的鼓励。

在做数据库开发时，我们常常遇到这样的现象：已经给关联查询的字段建立了单列索引，但执行起来仍然很慢。其中一个容易被忽略的原因是关联字段的选择性过低，导致索引无法有效过滤数据。

什么是索引选择性

索引选择性（Selectivity）是指字段中不同值的数量与总记录数的比例。比例越接近1，说明字段区分度越高；越接近0，说明重复值越多。例如用gender字段关联，可能只有男和女两个值，选择性极低。

可以通过下面SQL估算关联字段的选择性：

-- 计算 user_id 字段的选择性
SELECT 
  COUNT(DISTINCT user_id) / COUNT(*) AS selectivity
FROM orders;

如果结果小于0.1，通常认为选择性较低，单列索引效果有限。

当关联字段选择性过低时，即使使用了单列索引，数据库仍要处理大量重复键值的匹配。以A表关联B表为例：

使用EXPLAIN观察是否真的用到索引，以及扫描行数：

EXPLAIN
SELECT a.id, b.name
FROM users a
JOIN profiles b ON a.gender = b.gender;

若rows列显示扫描了几乎全表，且type为index或ALL，就说明选择性低让索引失去意义。

将低选择性字段与高选择性字段组合：

-- 建立组合索引
CREATE INDEX idx_user_region_id ON users (gender, user_id);

先过滤再关联，减少参与JOIN的数据量：

SELECT a.id, b.name
FROM (SELECT id, gender FROM users WHERE status = 1) a
JOIN profiles b ON a.gender = b.gender;

业务允许时，尽量使用主键或订单号等选择性高的字段做关联条件。

因此，当SQL关联查询在单索引下依然慢，应先检查关联字段的选择性是否过低，再决定是调整索引还是改写SQL。

免责声明：已尽一切努力确保本网站所含信息的准确性。网站内容多为原创整理与精心编撰，观点力求客观中立。本站旨在免费分享，内容仅供个人学习、研究或参考使用。若引用了第三方作品，版权归原作者所有。如内容涉及您的权益，请联系我们处理。