

> 从几十亿行临时结果到秒级响应，只差这几个优化

我是小耶，干运营半路出家的野生DBA——写功课只是为了我踩过的坑，你们别再踩了！

## 一、大表JOIN的常见死法

很多新手写SQL直接这样：

```
SELECT * FROM orders o JOIN users u ON o.user_id = u.id;
```

当 `orders` 有200万行、`users` 有100万行时，MySQL默认使用 ​**Nested Loop Join**​（嵌套循环连接）。外层表每一行都要去内层表全表扫描一遍，复杂度 O(M×N)。如果两张表都没有索引，那就是200万 × 100万 = 2万亿次比较，服务器直接CPU爆满。

## 二、优化第一招：先过滤再JOIN

把每张表的数据范围先缩小，然后再关联。这样可以大大减少参与JOIN的数据量。


```
SELECT *
FROM (SELECT * FROM orders WHERE order_date >= '2026-01-01') o
JOIN (SELECT id, name FROM users WHERE vip_level = 3) u
ON o.user_id = u.id;
```

​**注意点**​：子查询里尽量只SELECT需要的列，不要用 `*`。

## 三、优化第二招：JOIN字段必须建索引


```
ALTER TABLE orders ADD INDEX idx_user_id (user_id);
ALTER TABLE users ADD INDEX idx_id (id);
```

​**原理**​：有了索引，内层表的匹配从全表扫描变成B+树查找，复杂度从 O(N) 降到 O(logN)。200万 vs log2(200万) ≈ 21，差距巨大。

​**验证方法**​：用 `EXPLAIN` 看执行计划，`type` 列应该是 `ref` 或 `eq_ref`，如果是 `ALL` 说明索引没生效。

## 四、优化第三招：反范式设计，能不加JOIN就不加

如果某个字段在查询中高频使用，可以考虑直接冗余到主表。


```
-- 反范式：订单表直接存用户名和会员等级
ALTER TABLE orders ADD COLUMN user_name VARCHAR(64);
ALTER TABLE orders ADD COLUMN vip_level INT;
```

​**代价**​：写入时需要维护多份数据，适合读多写少的场景。

​**替代方案**​：如果不想改表结构，可以用 `IN` + 子查询，有时比JOIN更快（取决于数据分布）。


```
SELECT * FROM orders 
WHERE user_id IN (SELECT id FROM users WHERE vip_level = 3);
```

## 五、一个关键踩坑提醒

### LEFT JOIN vs INNER JOIN


```
-- 这种写法优化器可以重排列顺序
SELECT * FROM a JOIN b JOIN c ...

-- 这种写法必须按顺序执行，左表无法减少
SELECT * FROM a LEFT JOIN b ...
```

如果你的业务允许（比如不需要保留左表所有匹配不上的数据），​**尽量用 INNER JOIN**​。

### 算法选择：Hash Join（MySQL 8.0.18+）

MySQL 8.0.18 开始引入了 Hash Join，对于等值连接且两表都很大的情况，比 Nested Loop 快得多。可以通过 `EXPLAIN FORMAT=TREE` 查看实际使用的算法。

如果看到 `Using where; Using join buffer (hash join)`，说明用上了 Hash Join，效率较高。

## 六、生产环境实战建议

1. ​**先在小数据量上运行**​：加 `LIMIT 10` 看执行计划，确认索引生效再放开限制。
2. ​**分批处理**​：如果JOIN结果需要更新或删除，可以按时间范围分批执行。
3. ​**监控临时表大小**​：`SHOW STATUS LIKE 'Created_tmp%';` 看是否产生了大量磁盘临时表。

## 七、总结对照表

| 场景           | 错误写法                     | 正确姿势                    |
| ---------------- | ------------------------------ | ----------------------------- |
| 两表都大       | `SELECT * FROM a JOIN b` | 先分别过滤 + JOIN字段建索引 |
| 关联字段无索引 | 直接跑                       | `ALTER TABLE ADD INDEX` |
| 高频查询       | 每次都JOIN                   | 反范式冗余字段              |
| 业务允许       | `LEFT JOIN`              | 改成 `INNER JOIN`       |

小耶在手，SQL不愁。

你最崩溃的一次JOIN跑了多久？评论区分享一下，大家一起避坑。


当 orders 有200万行、users 有100万行时，MySQL默认使用 ​Nested Loop Join​（嵌套循环连接）。外层表每一行都要去内层表全表扫描一遍，复杂度 O(M×N)。如果两张表都没有索引，那就是200万 × 100万 = 2万亿次比较，服务器直接CPU爆满。

两张百万级大表JOIN跑崩了？试试这3招

分享SQL优化干货：从2万亿次比较到秒级响应，三招搞定大表JOIN——先过滤再关联、JOIN字段必建索引、读多写少可反范式。附LEFT/INNER JOIN避坑、Hash Join启用指南及生产实操建议。

编程语言

SQL优化技巧：通过过滤数据、建立索引、反范式设计等方法提升JOIN查询性能，避免全表扫描和临时表问题，实现秒级响应。掌握这些技巧可有效解决大表关联的性能瓶颈。

服务器

MySQL

腾讯云数据库特惠，新用户首单0.5折起


4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

两张百万级大表JOIN跑崩了？试试这3招-腾讯云开发者社区-腾讯云

两张百万级大表JOIN跑崩了？试试这3招

两张百万级大表JOIN跑崩了？试试这3招

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐