sql:2016标准规定执行顺序为from→where→group by→having→select→order by，故where中不可用select定义的列别名；order by后须加fetch first/limit才能确保结果确定性；group by非聚合字段必须出现在分组子句中；字符串拼接与null处理因方言而异。
SELECT 在 SQL:2016 标准中仍是核心查询语句，但写法细节和兼容性边界比多数人想象得更窄。直接说结论：**标准写法 ≠ 实际可用写法**，多数数据库（MySQL、PostgreSQL、SQL Server）只实现子集，且对 OFFSET/FETCH、FETCH FIRST 等语法支持程度不一。
WHERE 子句里不能用列别名
这是最容易踩的坑之一。SQL:2016 明确规定执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。所以你在 SELECT 里写的别名（比如 total_amount AS amt），在 WHERE 里根本不可见。
错误写法：SELECT order_id, total_amount * 1.1 AS amt FROM orders WHERE amt > 1000;
会报错，因为 amt 在 WHERE 阶段尚未生成。
正确做法：
• 复写表达式：WHERE total_amount * 1.1 > 1000
• 或改用 HAVING（需配合 GROUP BY）
• 或套一层子查询 / CTE
ORDER BY 后必须加 FETCH 或 LIMIT 才能保证结果确定性
SQL:2016 要求：如果查询未指定 ORDER BY，返回行序是未定义的；但如果指定了 ORDER BY 却没加 LIMIT 或 FETCH FIRST n ROWS ONLY，标准仍允许数据库返回任意满足排序条件的行——尤其在有重复排序值时（比如多个订单同为 created_at = '2026-07-01'）。
这意味着：
• SELECT * FROM orders ORDER BY created_at DESC; 不保证每次取到的是“最新5条”
• 正确写法应明确截断：FETCH FIRST 5 ROWS ONLY（标准写法）或 LIMIT 5（PostgreSQL/MySQL 兼容，但非标准）
• SQL Server 必须用 OFFSET 0 ROWS FETCH NEXT 5 ROWS ONLY
GROUP BY 的列必须严格出现在 SELECT 列表中或被聚合函数包裹
SQL:2016 强制要求：若使用 GROUP BY，则 SELECT 列表中的每个非聚合项，必须是 GROUP BY 子句中出现的列（或其确定性表达式）。MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY 才符合这点，旧版本或关闭该模式后可能返回不可靠结果。
例如：SELECT dept, AVG(salary), MAX(age) FROM staff GROUP BY dept; ✅ 合规SELECT dept, name, AVG(salary) FROM staff GROUP BY dept; ❌ 错误，name 未分组也未聚合，标准下非法
常见绕过方式：
• 改用窗口函数：AVG(salary) OVER (PARTITION BY dept)
• 或明确聚合 name，如 MAX(name)（但语义已变）
字符串拼接和空值处理在不同方言中行为不一致
SQL:2016 定义了 CONCAT() 函数（接受任意数量参数，自动跳过 NULL），但很多数据库仍用方言操作符：
• PostgreSQL / Oracle：用 ||
• SQL Server：用 +（但任一操作数为 NULL 时整结果为 NULL）
• MySQL：默认用 CONCAT()，但开启 PIPES_AS_CONCAT 后支持 ||
关键差异点：
• CONCAT('a', NULL, 'b') → 'ab'（标准行为）
• 'a' || NULL || 'b' → NULL（多数数据库实际行为）
• 所以跨库迁移时，IFNULL()、COALESCE() 必须显式补全，不能依赖拼接函数自动忽略 NULL
真正难的不是记住标准语法，而是判断你手头的数据库到底实现了哪一部分——比如 SQLite 根本不支持 FETCH，而 SQL Server 对 OFFSET 要求必须配 ORDER BY，否则报错。写之前先查文档，比背标准有用得多。
