关联查询字段没索引会怎样？多数人忽略的数据库性能陷阱

你在用数据库查数据时，有没有遇到过明明只查几万条记录，却要等好几秒的情况？尤其是两个表做关联查询的时候，卡得像是网络出了问题。其实，很多时候问题就出在——关联查询的字段没有加索引。

比如你在一个电商系统里，想查某个用户的订单详情。用户信息存在 users 表，订单存在 orders 表，通过 user_id 字段把两张表连起来。SQL 语句大概是这样：

SELECT u.name, o.amount 
FROM users u 
JOIN orders o ON u.id = o.user_id 
WHERE u.id = 123;

这看起来没问题，但如果 orders.user_id 没有加索引，数据库就得从头到尾扫一遍所有订单，一条条比对 user_id 是不是 123。这种操作叫“全表扫描”。

最直接的感受就是慢。哪怕你的主表数据不多，只要被关联的那张大表没索引，查询时间就会指数级上升。比如订单表有 100 万条数据，每次关联都得扫 100 万行，服务器 CPU 狂飙，响应变慢，用户体验一落千丈。

更严重的是，高并发场景下，多个请求同时执行这类慢查询，数据库连接池可能迅速耗尽，整个网站卡死。你刷个购物车页面都转圈，客服电话立马被打爆。

想象一下，你要在一座百万人口的城市里找一个叫“李明”的人，但没有电话簿、没有身份证号查询系统，只能挨家挨户敲门问：“你是李明吗？” 这效率可想而知。索引的作用，就是给数据库建一本“电话簿”，让它能直接定位目标数据。

凡是出现在 JOIN、WHERE、ORDER BY 后面的字段，尤其是关联字段，都应该优先考虑加索引。还是上面的例子，orders.user_id 就必须加索引。

加索引的 SQL 很简单：

ALTER TABLE orders ADD INDEX idx_user_id (user_id);

加上之后再执行关联查询，速度通常能从几秒降到毫秒级。

每加一个索引，写入数据时就要多维护一份结构，插入、更新、删除都会变慢一点。而且索引占存储空间。所以只给真正需要的字段加，别看到字段就加索引。

日常开发中，很多人只关注功能实现，忽略了数据库性能细节。等到系统慢了才去查原因，往往已经影响了用户。特别是涉及用户登录、订单查询、消息推送这些关键路径，关联字段没索引，轻则体验差，重则服务瘫痪。

下次写关联查询时，不妨停下来问问自己：这个 ON 的字段，真的有索引吗？

关联查询字段没索引会怎样（实用技巧版）