结论：limit 1 offset 1 单独使用不返回 null，只返回空结果集；必须嵌套于外层 select(子查询) 中，利用标量子查询空结果自动转 null 的语义，才能稳定返回 null 值。
直接说结论：用 LIMIT 1 OFFSET 1 配合 DISTINCT 和外层 SELECT 嵌套，才能稳定返回 NULL —— 单靠 LIMIT 1 OFFSET 1 本身不返回任何行，不是 NULL。
为什么 LIMIT 1 OFFSET 1 单独用会漏掉 NULL？
MySQL 的 LIMIT / OFFSET 是“跳过再取”，不是“取第 N 行”。当结果集不足 2 行（比如只有一条薪水、或所有薪水相同），SELECT DISTINCT salary FROM employee ORDER BY salary DESC LIMIT 1 OFFSET 1 执行后**返回空结果集**，不是 NULL。而题目/业务要求是必须返回一行一列，值为 NULL。
-
OFFSET 1意味着跳过第 0 行（即最高薪），从第 1 行开始读 - 如果总共只有 1 行，跳过之后没得读 → 查询结果为空（0 行）
- SQL 标准中，空结果集 ≠
NULL；字段不存在，自然不满足“返回一个NULL值”的契约
嵌套查询怎么写才真正生效？
核心是把内层查询当作一个表达式，让外层 SELECT 对它求值 —— 如果内层无结果，外层就得到 NULL。
正确写法：
SELECT ( SELECT DISTINCT salary FROM employee ORDER BY salary DESC LIMIT 1 OFFSET 1 ) AS SecondHighestSalary;
- 外层
SELECT (子查询)是标量子查询语法，强制要求子查询最多返回 1 行 1 列；若子查询无结果，整体表达式值就是NULL - 必须加
DISTINCT，否则重复薪水（如 [500,500,400]）会导致排序后第二行仍是 500，而非真正的“第二高” -
ORDER BY salary DESC不可省略，否则OFFSET无意义
IFNULL 能不能替代嵌套？
可以，但有兼容性风险，且逻辑绕弯。
常见写法：
SELECT IFNULL( (SELECT DISTINCT salary FROM employee ORDER BY salary DESC LIMIT 1 OFFSET 1), NULL ) AS SecondHighestSalary;
- 看起来更直白，但
IFNULL是 MySQL 特有函数；PostgreSQL 用COALESCE，SQL Server 用ISNULL - 其实
IFNULL(..., NULL)是冗余的 —— 子查询本身在无结果时已是NULL，再套一层只是增加可读性假象 - 某些旧版 MySQL（如 5.6）在子查询为空时，
IFNULL可能报错或行为异常，反不如纯嵌套稳妥
和“排除最大值再取最大”方案比有什么区别？
另一种主流解法：SELECT MAX(salary) FROM employee WHERE salary
- 语义清晰：先找最高，再找比它小的最大值
- 天然返回
NULL：当WHERE条件无匹配行时，MAX()聚合结果就是NULL - 性能差异不大，但该写法在有索引（
salary列上有 B-tree 索引）时可能略快，因避免了排序 - 注意：必须用
MAX(salary)，不能用salary—— 否则无匹配时会返回空结果集，同样不满足NULL要求
真正容易被忽略的是：无论选哪种方案，DISTINCT 和外层包裹缺一不可。很多人调试时看到本地数据能出数，一提交就错，问题往往出在边界 case（单行、全同值、空表）没压测到。
