不能直接用 limit 1 offset 1 获取第二高薪水，因为重复薪水会导致跳过记录而非跳过等级；正确做法是用相关子查询统计严格大于当前薪水的去重薪水数量，等于1即为第二高。
为什么不能直接用 LIMIT 1 OFFSET 1 获取第二高薪水
因为存在薪水重复时，LIMIT 1 OFFSET 1 会跳过一条记录，而非跳过一个薪水等级。比如薪水为 [10000, 9000, 9000, 8000]，OFFSET 1 后取到的是第二个 9000，不是真正的“第二高”（即 8000）。
用相关子查询数“有多少个不同薪水高于当前行”
核心思路：对每条员工记录，统计表中**严格大于**该员工薪水的**去重薪水数量**；若这个数量恰好为 1，说明该员工薪水就是第二高。
- 必须用
COUNT(DISTINCT salary)，否则重复薪水会导致计数偏大 - 子查询需关联外层：
WHERE t2.salary > t1.salary，且别名要清晰（如t1为外层，t2为内层） - MySQL 5.7+ 和 PostgreSQL 均支持；SQLite 支持但性能较差；SQL Server 需改用
TOP或窗口函数更稳妥
SELECT * FROM employees t1 WHERE 1 = ( SELECT COUNT(DISTINCT t2.salary) FROM employees t2 WHERE t2.salary > t1.salary );
当没有第二高薪水时返回 NULL 的安全写法
如果所有员工薪水相同，或仅有一人，上述查询会返回空结果集——但业务上常需明确返回 NULL 或默认值。此时不能只靠 WHERE 过滤，得把子查询结果作为字段参与判断：
- 用
(SELECT ...)作为标量子查询，在SELECT列表中计算，再用WHERE或HAVING控制输出 - 更可靠的做法是先查出第二高薪水值，再查匹配员工：
SELECT * FROM employees WHERE salary = (SELECT DISTINCT salary FROM employees ORDER BY salary DESC LIMIT 1 OFFSET 1)——但这依赖 LIMIT/OFFSET，仍不解决重复问题，所以还是推荐第一种相关子查询方式 - 注意：相关子查询在大数据量下性能差，因为对每行都执行一次内层扫描；真实场景建议建
INDEX(salary)
相关子查询里容易漏掉的 DISTINCT 和别名作用域
常见错误是写成 COUNT(t2.salary) 或漏掉 t2. 前缀，导致语法错误或逻辑错乱：
-
COUNT(t2.salary)→ 统计行数，不是去重薪水个数 -
WHERE salary > t1.salary（没写t2.salary）→ 可能被解析为自比较，或报 “ambiguous column” 错误 - 子查询中若引用了外层表未出现在
SELECT中的字段（如t1.name），多数数据库允许，但可读性差，建议只在 WHERE 中关联主键或关键列
真正难的不是写出这个子查询，而是意识到它必须同时满足“去重计数”和“逐行关联”两个约束——少一个，结果就不可靠。
