SeigRobotics说实话，我见过太多人写了三年SQL，还在用SELECT *和WHERE堆业务逻辑，一遇到"每个分组里排名前3的订单"这种需求就掏出Python跑循环。这不是个例，而是断层——基础SQL你已经会了，但高级SQL的思维和武器库没跟上。这篇内容，我想讲讲从"会写SQL"到"会设计SQL"之间，到底缺了什么。
很多初学者听到"高级SQL"就慌，觉得是那种全是黑话、绕着弯子炫技的东西。其实真不是。高级SQL的核心只有一件事：用更少的资源、更清晰的逻辑，拿到更准确的数据。它不是什么高不可攀的技术，而是你解决真实业务问题时手里该有的那套工具箱。无论你用MySQL、PostgreSQL还是SQL Server 2008 R2，这套思想全通。尤其是如果你正在准备面试、要接手复杂的报表需求、或者被慢查询折磨得头大，这篇内容基本就是按你踩过的坑来写的。
1. 高级SQL的进阶路线：别急着学语法，先纠正思维方式
1.1 声明式思维：你要的是结果，不是过程
基础SQL到高级SQL的分水岭，第一道就是思维转换。你用Java、Python写逻辑时是命令式思维——先干嘛、再干嘛、循环怎么走、条件怎么判断。但SQL不是这么玩的。SQL是声明式语言，你告诉数据库"我要什么"，数据库自己决定"怎么拿"。
举一个我实际辅导新人时常举的例子：有两张表，一张订单表，一张订单明细表，让你统计每个客户的总消费金额，并且只看那些消费总额超过1万的客户。新手写法往往是这样：
sql复制SELECT 客户ID, SUM(金额) AS 总额
FROM 订单
GROUP BY 客户ID
HAVING SUM(金额) > 10000;
然后呢？没有了。就这么简单。但新手会忍不住问：那我是不是应该先写个临时表存一下每个人的总额，再筛选一遍？不用。HAVING就是干这个的，它是在分组后做条件过滤，本质上是SQL替你完成了一次"中间过程"。这个例子听起来很基础，但我想说的是：高级SQL的第一步，是接受"数据库比你聪明"这个事实，把过程思维放下，把结果思维捡起来。
再往下走，你会碰到窗口函数、CTE（公用表表达式）、动态SQL这些概念。这些东西单独看都能理解，但组合起来才是真正的杀伤力。我建议的进阶顺序是这样的：
- 第一层：子查询和JOIN的各种姿势，搞清楚什么时候用
IN、什么时候用EXISTS、什么时候必须用JOIN。 - 第二层：窗口函数，尤其是
ROW_NUMBER()、RANK()、LAG()/LEAD()，这是分析报表的利器。 - 第三层：CTE和递归查询，把复杂逻辑拆成一块一块，可读性直接拉满。
- 第四层：动态SQL和优化执行计划，这层就开始接触数据库底层了。
1.2 为什么说"能跑就行"是最大的坑
基础SQL阶段，你写的每条语句可能只面对几百几千行数据，性能差异完全感觉不出来。但到了生产环境，一张表几百万行、关联四五张表的时候，一条烂写法能把数据库CPU打满。所谓的"高级SQL"，很多时候不是会什么冷门语法，而是知道在什么场景下用什么写法是安全的、高效的。
打个比方。基础SQL像是你学会了开车，能踩油门能刹车，能到目的地。高级SQL是你开始理解路况——什么时候该走高速、什么时候该绕开拥堵路段、什么时候就算绕远也不要走一条可能堵死的小路。同样的起点和终点，老司机和新手到达的时间完全不一样。
所以这篇文章里，我尽量不纠结那些教科书上已经写明白的基础定义，而是把重点放在取舍和为什么上。每个语法点，我都会说清楚它解决什么问题、牺牲了什么、什么时候别用它。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 高级查询语法实战：这几个技巧能救你于水火
2.1 窗口函数：分组计算不再丢行
窗口函数可以说是基础SQL到高级SQL的一道分水岭。很多写了两三年SQL的人，遇到"每个部门工资排名前两名的员工"这种需求，第一反应还是自连接，写出来的SQL又长又绕。其实窗口函数一行就能解决。
sql复制SELECT
部门ID,
员工姓名,
工资,
ROW_NUMBER() OVER (PARTITION BY 部门ID ORDER BY 工资 DESC) AS 工资排名
FROM 员工表
WHERE 工资排名 <= 2;
注意，上面的写法在MySQL 8.0之前的版本会直接报错，因为窗口函数不能在WHERE里直接引用。正确姿势是套一层子查询：
sql复制SELECT *
FROM (
SELECT
部门ID,
员工姓名,
工资,
ROW_NUMBER() OVER (PARTITION BY 部门ID ORDER BY 工资 DESC) AS 工资排名
FROM 员工表
) AS t
WHERE 工资排名 <= 2;
这里PARTITION BY就是"分组窗口"，它把每个部门单独作为一个窗口，窗口内按工资从高到低排序，然后编号。ROW_NUMBER()编号从1开始连续递增，不会重复。如果你要处理并列排名，就用RANK()或DENSE_RANK()。RANK()遇到并列会跳号（1、1、3），DENSE_RANK()不跳号（1、1、2）——这个细节特别容易被面试官考到，自己在本地试一次就记住了。
窗口函数最大的价值在于：它不像GROUP BY那样会把多行压成一行，而是在保留所有原始行的同时，额外给你一个计算列。这就非常适合做"同期对比""累计求和""移动平均"这类分析需求。比如算每个用户今年以来每个月的累计消费金额：
sql复制SELECT
用户ID,
月份,
月消费金额,
SUM(月消费金额) OVER (PARTITION BY 用户ID ORDER BY 月份) AS 累计消费金额
FROM 月度消费表;
这个SQL跑出来的结果，每一行都保留，同时多出一列"累计消费金额"，完美符合中国式复杂报表的格式要求。
2.2 WITH AS：把一坨复杂的SQL拆成积木
WITH AS（CTE，公用表表达式）是我个人最推崇的SQL写法之一，尤其是面对嵌套三层的子查询时，它能把你的可读性从地狱拉回人间。它的逻辑很简单：给一段查询结果起个名字，后面随时引用。
sql复制WITH 高价值客户 AS (
SELECT 客户ID, SUM(金额) AS 总金额
FROM 订单表
GROUP BY 客户ID
HAVING SUM(金额) > 50000
)
SELECT
客户名称,
高价值客户.总金额
FROM 高价值客户
JOIN 客户表 ON 客户表.客户ID = 高价值客户.客户ID;
这么做的好处首先是把"先算什么"和"再算什么"分开了。你不需要在一层套一层的括号里面找逻辑，每一段都是命名清晰的独立模块。其次是同一个CTE可以被后面的多个查询复用，不用像子查询那样到处重复粘贴同一段代码。
热度词里提到的"sql with as用法"，其实就是这东西。我见过有些老系统里几百行的嵌套子查询，这种SQL基本没人敢动，改一行都会心惊胆战。但用WITH AS重构一遍之后，结构就清晰多了。
CTE还有一个用得比较少但很实用的特性——递归。如果你要处理树形结构，比如部门层级、分类树、BOM物料清单，递归CTE是标配。比如一个简单的树状结构，从某个父节点开始往下找所有层级的子节点：
sql复制WITH RECURSIVE 部门树 AS (
SELECT 部门ID, 部门名称, 上级部门ID, 1 AS 层级
FROM 部门表
WHERE 上级部门ID IS NULL
UNION ALL
SELECT 子.部门ID, 子.部门名称, 子.上级部门ID, 父.层级 + 1
FROM 部门表 子
JOIN 部门树 父 ON 子.上级部门ID = 父.部门ID
)
SELECT * FROM 部门树;
注意，不同数据库的递归写法有差异——PostgreSQL和MySQL 8.0用的是WITH RECURSIVE，SQL Server直接写WITH就行。第一次跑递归CTE时最好先确认数据里没有环，否则会无限递归把数据库跑挂。这是我踩过的坑，后面在问题排查里细说。
2.3 BETWEEN AND与AND/OR的执行顺序：细节里的魔鬼
热搜词里同时出现了"sql between and的用法总结"和"sql当中同时有and和or的执行顺序"，这两个都是初级到中级过渡期很容易踩坑的知识点。
先说BETWEEN AND。很多人的理解是"在...和...之间"，用的时候觉得很简单：
sql复制SELECT * FROM 订单表 WHERE 下单时间 BETWEEN '2023-01-01' AND '2023-12-31';
但BETWEEN AND在SQL标准里是闭区间，也就是说它等价于下单时间 >= '2023-01-01' AND 下单时间 <= '2023-12-31'。这里有个隐患：如果你的字段是带时分秒的DATETIME类型，那'2023-12-31'会被自动解析成'2023-12-31 00:00:00'，意味着12月31日当天的订单其实没被包含进去，除了零点整那一秒。这是生产环境里非常经典的"边界Bug"。
我在实际开发里更推荐半开区间写法，也就是>=配合<：
sql复制SELECT * FROM 订单表
WHERE 下单时间 >= '2023-01-01'
AND 下单时间 < '2024-01-01';
这样能完整覆盖整个2023年，不用担心边界缺失。这个习惯养成之后，查询精度会高很多。
再说AND和OR的优先级。SQL里AND的优先级是高于OR的，这个顺序和大多数编程语言一致。但你在看一条复杂查询时，眼睛很容易被OR左右两边的内容牵着走。比如：
sql复制SELECT * FROM 客户表
WHERE 省份 = '广东' OR 省份 = '浙江' AND 等级 = 'VIP';
你以为是"广东或浙江的VIP客户"，其实SQL理解的是"广东省的全部客户，加上浙江省的VIP客户"。因为AND先执行，省份 = '浙江' AND 等级 = 'VIP'被绑定成了一个整体，然后再和省份 = '广东'做OR。要避免这种误解，最佳实践是凡是混用AND和OR，必须加括号：
sql复制SELECT * FROM 客户表
WHERE (省份 = '广东' OR 省份 = '浙江') AND 等级 = 'VIP';
括号不是可选项，是必需品。别嫌麻烦，也别觉得自己记得住优先级。等你在半夜被线上问题叫起来的时候，你会发现括号是你唯一能信任的东西。
2.4 去重与空值：数据清洗的基础功
热搜词里有"sql语句去重查询"和"sql去除空值"，这两个看似基础，但高级用法也不少。
去重最简单的当然是DISTINCT：
sql复制SELECT DISTINCT 客户ID FROM 消费记录表;
但DISTINCT的问题在于它会对整行去重，如果后面跟了多个列，只有所有列完全相同才会被合并。如果你想去重后只保留某几条数据，比如每个客户最新的一条订单，那就不能用DISTINCT了。这时候窗口函数又派上用场：
sql复制SELECT *
FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY 客户ID ORDER BY 下单时间 DESC) AS rn
FROM 订单表
) AS t
WHERE rn = 1;
这个"按客户ID分组，每组按下单时间倒序排序，取第一条"的模式，比用GROUP BY加MAX()再自连接要简洁得多。而且它保留了整行数据，不受"只查分组字段"这个限制的束缚。
空值处理也是一样。很多新手会把空字符串和NULL混为一谈，用= ''去查空值，结果一条都查不出来。SQL里的空值判断必须用IS NULL或者IS NOT NULL：
sql复制-- 查没有填写手机号的客户
SELECT * FROM 客户表 WHERE 手机号 IS NULL;
-- 查填写了手机号的客户
SELECT * FROM 客户表 WHERE 手机号 IS NOT NULL;
还有一点：NULL和任何值做比较运算，结果都是NULL而不是TRUE或FALSE。所以WHERE 手机号 = NULL永远查不到数据。如果你要把空值替换成默认值，用COALESCE()函数，它可以接受多个参数，从左往右返回第一个非空值：
sql复制SELECT COALESCE(手机号, '未填写') AS 手机号 FROM 客户表;
这个函数在报表里极其常用，尤其是做数据导出的时候，避免出现一堆空白的单元格。
3. 慢SQL优化实录：从执行计划到索引设计
3.1 为什么你的SQL慢？先学会看执行计划
热度词里有一堆"sql优化""慢sql优化""并行sql优化"，说明这是所有写SQL的人绕不过去的一道坎。我的经验是：优化SQL的第一步不是猜，也不是瞎加索引，而是看执行计划。
执行计划就是数据库告诉你"我准备怎么执行你这条SQL"的路线图。以MySQL为例，你在SQL前面加上EXPLAIN：
sql复制EXPLAIN SELECT 订单号, 金额 FROM 订单表 WHERE 客户ID = 12345;
返回结果里最关键的是type这一列。它的取值从好到差大概是：const、eq_ref、ref、range、index、ALL。如果你看到ALL，那就是全表扫描——数据库把整张表一行行读了一遍，当表很大时这就是慢查询的根源。看到index也不一定好，它是全索引扫描，虽然比全表扫描快一点，但依然是在遍历。
rows列也很关键，它表示数据库预估需要读取的行数。这个数字越大，SQL越危险。另外，Extra列如果出现Using filesort，说明排序没走索引，是在临时文件里排的，数据量大时非常慢；出现Using temporary则说明用了临时表，常见于GROUP BY和DISTINCT组合的情况下。
以SQL Server为例，你最该养成的好习惯是在SSMS里开启"包含实际执行计划"，然后看那些百分比特别大的运算符。比如一个Hash Match占了85%的执行开销，那问题基本就出在这个关联操作上。
3.2 索引不是越多越好，关键看选择性
索引是SQL优化里最核心的手段，但也是最容易被滥用的手段。我见过一张表建了二十多个索引，结果写入性能差到令人发指。记住一个原则：索引是给查询用的，不是给表装饰的。
什么样的查询适合建索引？简单来说，WHERE子句里频繁出现的等值条件字段、ORDER BY排序字段、GROUP BY分组字段、JOIN的关联字段。建索引的时候还要注意联合索引的字段顺序。比如你经常按客户ID + 下单时间查询，那在MySQL里应该建一个(客户ID, 下单时间)的联合索引，而不是分别建两个单列索引。因为联合索引会先按第一个字段排序，再按第二个字段排序，这正好匹配了先按客户ID过滤、再按下单时间排序的查询路径。如果你把顺序反过来，很多场景就用不上这个索引了。
另一个高频知识点是最左前缀原则。联合索引(a, b, c)能匹配的查询组合包括a、a+b、a+b+c。如果你跳过第一列直接用b和c查，对不起，索引失效。这就好比你查字典先知道第二个字而不知道第一个字，没法用拼音索引快速定位。
索引失效的常见场景我也帮你列一下：
- 对索引列使用函数，比如
WHERE YEAR(下单时间) = 2023，数据库就没法用索引了，最好改写为WHERE 下单时间 >= '2023-01-01' AND 下单时间 < '2024-01-01'。 - 隐式类型转换。字段是字符串类型，条件里写的是数字，数据库会做隐式转换导致索引失效。比如
WHERE 手机号 = 13800138000，手机号字段是varchar，这个条件会全表扫描。 - 前置模糊匹配。
LIKE '%关键词'用不上索引，但LIKE '关键词%'可以。 - 在索引列上做运算，比如
WHERE 金额 + 1 > 100，要改成WHERE 金额 > 99。
3.3 分页查询和JOIN的优化细节
分页查询是后台管理系统的标配功能，但越到后面越慢。经典的写法是这样：
sql复制SELECT * FROM 订单表 ORDER BY 下单时间 DESC LIMIT 100000, 20;
这条SQL在MySQL里的执行逻辑，是先找出所有符合条件的记录并排序，然后扔掉前10万条，只返回最后20条。越往后翻页，数据库干的活儿越多，性能自然越来越差。一个常见的优化方法是用延迟关联，先查出主键或索引列，再回表查完整数据：
sql复制SELECT 订单表.*
FROM 订单表
JOIN (
SELECT 订单ID
FROM 订单表
ORDER BY 下单时间 DESC
LIMIT 100000, 20
) AS tmp ON 订单表.订单ID = tmp.订单ID;
子查询里只查主键和排序字段，可以走覆盖索引（索引里包含了所有需要的列，不需要回表），速度会快不少。如果你有"上一页最后一条记录的主键"，还可以用"游标分页"的方式，直接跳过偏移量：
sql复制SELECT * FROM 订单表
WHERE 订单ID < 上一页最后一条的订单ID
ORDER BY 订单ID DESC
LIMIT 20;
这种写法在数据量极大时性能非常稳定，但前提是排序字段必须是唯一的、连续可比较的，一般用自增主键最合适。
JOIN的优化要点在于：小表驱动大表。这个原则在MySQL里尤其重要。STRAIGHT_JOIN可以强制指定驱动表的顺序，但在绝大多数情况下，你只要保证JOIN的关联字段上有索引就够了。另外，尽量用INNER JOIN而不是LEFT JOIN去实现"只要匹配的行"这个需求，因为LEFT JOIN会保留左表所有行，数据库必须做更多的工作来判断右表有没有匹配。
3.4 慢SQL排查方法论：从发现问题到定位问题
接到线上慢SQL的报警，我的排查套路通常是这样的：
- 先开慢查询日志。MySQL里
slow_query_log开启后，执行时间超过设定阈值的SQL都会被记录到日志文件。SQL Server里可以用"活动监视器"或者查询sys.dm_exec_query_stats动态管理视图来找到运行时间长的SQL。 - 看这条SQL是不是全表扫描。用
EXPLAIN看执行计划，重点看type是不是ALL，rows有多大。 - 看锁等待是不是主因。如果查询本身很快，但就是一直卡住，多半是锁的问题。在MySQL里可以用
SHOW PROCESSLIST看看State是不是Waiting for table metadata lock。SQL Server里可以用sp_who2查看阻塞的会话。 - 试着加索引并对比前后执行计划。有时候问题其实就是缺了一个索引，加上之后
rows从几十万变成几十行。
慢SQL优化很多时候不是一条SQL的事，而是SQL、索引、数据库配置三者之间的配合。比如SQL Server 2019有一个"并行查询"特性，当一个查询很大时，数据库会自动用多个CPU核并行处理。但并行度太高也可能导致CPU资源耗尽，影响其他在线事务。所以看到"并行sql优化"这个热词，我的建议是：少去调那些数据库级别的并行度参数，先把自己的SQL写利索了再看这些高级配置。
4. 动态SQL与安全防线：能写复杂SQL，更要防住攻击
4.1 动态SQL：按需拼装查询的利器
在Java后端开发里，动态SQL出现频率最高的场景就是多条件组合查询。用户在前端勾选了三个筛选条件，另一个用户勾选了五个，你不能为每种组合都写一条静态SQL。这时候动态SQL就派上用场了。以MyBatis为例，它提供了if、choose、when、foreach这些标签来拼装SQL。
典型场景：一个客户列表查询，可按客户名模糊搜索、按省份精确匹配、按消费金额区间筛选，三个条件可选可不选。MyBatis的动态SQL写法大致是这样：
xml复制SELECT * FROM 客户表
WHERE 1 = 1
<if test="客户名 != null and 客户名 != ''">
AND 客户名 LIKE CONCAT('%', #{客户名}, '%')
</if>
<if test="省份 != null and 省份 != ''">
AND 省份 = #{省份}
</if>
<if test="最小金额 != null">
AND 消费金额 >= #{最小金额}
</if>
<if test="最大金额 != null">
AND 消费金额 <= #{最大金额}
</if>
这里WHERE 1 = 1看着别扭，但它的作用是让后面每个AND都能直接拼上去，不用费心判断这是不是第一个条件。这是一种非常务实的写法。
更规范的替代方案是用<where>标签，它会自动去掉第一个多余的AND。还有<foreach>用来处理IN条件列表，比如传一个ID集合：
xml复制SELECT * FROM 订单表 WHERE 客户ID IN
<foreach collection="ids" item="id" open="(" separator="," close=")">
#{id}
</foreach>
使用动态SQL时最容易踩的坑是什么？我经验里有两条：第一，注意参数类型。if标签里的判断要严格区分null和空字符串，尤其从前端传过来的参数，经常是"空字符串"而不是null，不加判断的话条件就会拼成AND 字段 = ''，查出来的结果莫名其妙。第二，foreach虽然好用，但列表太长时会导致SQL语句过长，数据库可能直接拒绝执行。一般超过1000个元素的IN列表就要考虑拆批。
4.2 SQL注入：为什么参数化查询是底线
热度词里有一条"sql注入万能密码绕过"，这话题我必须认真说清楚。SQL注入的原理说白了就是：你原本写的SQL是固定结构的，但攻击者通过在输入里插入SQL片段，改变了整个语句的语义。经典的万能密码登录绕过姿势大概长这样：
假设后端代码是这么写的：
csharp复制string sql = "SELECT * FROM 用户表 WHERE 用户名 = '" + 用户名 + "' AND 密码 = '" + 密码 + "'";
攻击者在用户名框里输入' OR '1'='1' --，整个SQL就变成：
sql复制SELECT * FROM 用户表 WHERE 用户名 = '' OR '1'='1' --' AND 密码 = 'anything'
--在SQL Server和MySQL里都是注释符，后面的内容全部被注释掉。OR '1'='1'恒为真，于是这条查询直接把第一行记录返回了，攻击者就这么"绕过"了密码校验。这不是段子，是真实发生过无数次的事故。
正确的做法是永远不要用字符串拼接来构造SQL，而是使用参数化查询。在MyBatis里，用#{}就是参数化，用${}则是字符串替换，不安全且容易被注入。
xml复制<!-- 安全：#{} 会生成预编译的占位符 -->
SELECT * FROM 用户表 WHERE 用户名 = #{用户名} AND 密码 = #{密码}
预编译的意思就是，先把SQL语句的结构发给数据库，让数据库确定这个语句是"查用户名等于某个值"，之后输入什么内容都只是纯粹的数据，不会再被当作SQL代码执行。这个机制就像先把信封上写清楚收件人，之后再往信封里塞什么都不影响外面的地址。所有主流语言的数据库驱动都支持预编译，JDBC的PreparedStatement、C#的SqlParameter、Python的%s占位符，全都是这个思路。
我见过有些老项目因为历史原因大量使用拼接SQL，想改造成参数化又怕影响业务。我的建议是：这种事不要"全部一键改"，而是先从登录、搜索这些用户可输入的入口开始改，因为这些地方风险最高。可以写一个脚本扫描代码里所有的SQL字符串，优先处理带有用户输入变量的那部分。防住注入，比写出花哨的窗口函数重要一万倍。
5. 高频问题排查实录与避坑指南
5.1 连接与登录相关：SQL Server用户的日常崩溃
热搜词里出现了不少关于SQL Server 2008 R2下载、SQL Server 2019安装教程、SQL Server 2022安装教程的搜索，说明很多人在数据库安装和连接阶段就已经被折磨得不行了。根据我的实际经验，这类问题90%都可以归结为以下几个原因：
第一个是"用户'sa'登录失败"。大概率是SQL Server只开了Windows身份验证模式，没开混合模式。用Windows身份登录SSMS，右键服务器属性，在"安全性"里改成"SQL Server和Windows身份验证模式"。改完之后记得重启SQL Server服务，否则不生效。
第二个是"Named Pipes Provider: Could not open a connection to SQL Server"。这种报错通常是SQL Server的服务没启动，或者连接字符串里的服务器名写错了。先用"SQL Server配置管理器"确认服务状态，再在SSMS里用127.0.0.1试一下，排除网络和名称解析问题。
第三个是安装SQL Server时看到一堆组件选项发懵。其实对大多数开发工作，只要装"数据库引擎服务"和"客户端工具连接"就够用了。SQL Server 2019里的"机器学习服务"组件，如果你想用R和Python跑数据，可以选上，但它占用空间很大，没有需求就别装。
5.2 数据操作中的经典翻车场景
场景一：导SQL文件导到一半报错。
用DBeaver、HeidiSQL或Navicat导入一个几百MB的SQL文件，结果跑到中间报错，回滚也不是，继续也不是，最后表结构混乱。我的建议是导入前先确认两件事：文件里有CREATE DATABASE语句吗？有没有指定USE某个库？没有的话，你自己要先建好目标数据库，并确保当前连接选中的就是它。另外，超大的SQL文件尽量用命令行工具导入，比如MySQL用mysql -u root -p 数据库名 < 文件.sql，DBeaver直接导入大文件会非常慢或者内存溢出。
场景二：两张表的数据同步更新。
热搜词里有"sql更新一个表中列为另外一个表中的列"，这典型解法是UPDATE JOIN。MySQL的语法是：
sql复制UPDATE A
JOIN B ON A.关联ID = B.关联ID
SET A.目标列 = B.源列
WHERE B.条件 = 1;
SQL Server的语法则是用FROM子句：
sql复制UPDATE A
SET A.目标列 = B.源列
FROM A
JOIN B ON A.关联ID = B.关联ID
WHERE B.条件 = 1;
数据库之间语法有差异，写之前先确认自己用的哪种。同样的思路也适用在INSERT ... SELECT批量导入数据。
场景三：替换NULL和空字符串之后数据对不上。
做数据清洗时，我习惯先把数据分布摸一遍：这个字段到底有多少NULL？多少空字符串？多少空格？在SQL Server里可以直接查：
sql复制SELECT
COUNT(*) AS 总数,
COUNT(手机号) AS 非空数量,
SUM(CASE WHEN 手机号 IS NULL OR 手机号 = '' THEN 1 ELSE 0 END) AS 缺失数量
FROM 客户表;
COUNT(某列)不会统计NULL，这个特性可以用来快速判断缺失情况。
5.3 几个让我印象深刻的优化案例
第一个是Flowable工作流引擎里有人问"flowable能写SQL吗"。Flowable本身提供了API来查询流程实例、任务等数据，但当报表要从几十张流程相关表里汇总数据时，很多人还是会直接写原生SQL。这当然可以，但有几个原则：查询只读数据用原生SQL没问题，涉及流程状态流转的数据不要直接UPDATE，否则容易破坏引擎的内部一致性。简单说，查可以，写要慎重。
第二个是一个我印象很深的慢查询案例。某业务系统的报表SQL要关联5张表，每张表都有一百万行以上，一次查询跑两分多钟。我通过执行计划发现罪魁祸首是两张表关联时没走索引，因为隐式类型转换——一边是VARCHAR，一边是INT，索引压根用不上。解决方式就是统一字段类型，把VARCHAR改成INT，查询直接从120秒降到1.2秒。
第三个案例是关于SELECT *的。一个内部工具每查一条记录就把整行所有字段都拉回来，这些字段总共有80多列，其中包含好几个TEXT大字段。后来我改成只查需要的字段，顺便把大字段拿掉，同一页面打开速度快了近10倍。这也是我要强调的：高级SQL不一定要炫技，但一定要有成本意识——你和数据库交互的每一字节，都有代价。
说实话，高级SQL学到后面，最值钱的不是你会多少函数，而是你在写一条SQL之前，脑海里已经能预判它怎么走索引、大概消耗多少资源、有没有隐含的边界问题。这个能力只能靠踩坑和刻意练习积累。我的建议是拿一个真实业务场景，比如把最近一个月的订单表拉下来，试着用不同的写法完成同一个需求，然后对比执行计划和耗时。用不了多久，你就能建立起那种"这样写不太对"的直觉。
最后再分享一个小技巧：如果你的日常开发里经常要写复杂SQL，强烈建议在本地搭一套和线上同版本的数据库环境，专门用来做SQL实验。很多语法和优化手段，在线上不敢试，在本地随便造。我见过太多人因为"怕搞坏环境"而从来没跑过EXPLAIN，这其实是最可惜的事——执行计划不咬人，你怕它干嘛？大胆点，多试几次，高级SQL的大门就是这么一脚踹开的。