MySQL将NULL视为最小值，ORDER BY时NULL总排最前；不支持NULLS FIRST/LAST语法，需用ISNULL()、字段IS NULL或IF()等表达式绕过。
MySQL 把 NULL 当作比所有非 NULL 值都小的值，所以 ORDER BY col ASC 时 NULL 自然排最前。这不是 bug，是 MySQL 的明确设计选择，和 PostgreSQL、Oracle 等默认把 NULL 当“最大”处理的逻辑正好相反。
MySQL 默认把 NULL 视为最小值
执行 SELECT * FROM t ORDER BY score ASC 时，只要 score 列有 NULL，它们一定出现在结果集开头。这是因为 MySQL 内部在比较阶段对 NULL 的语义定义就是 “less than any non-NULL value”。你不需要额外触发条件，只要字段允许为 NULL，这个行为就生效。
-
NULL = 5返回UNKNOWN，不是FALSE；但排序不依赖布尔结果，而是依赖底层比较协议 - 该行为从 MySQL 5.7 到 8.0 一直保持一致，官方文档明确写为 “
NULLvalues are considered less than any non-NULL value” - 它影响所有类型：数值、字符串、日期——哪怕
DATE是NULL，也会排在'1970-01-01'前面
为什么不能直接用 NULLS LAST？
因为 MySQL（截至 8.0.33）**不支持** SQL:2003 标准的 NULLS FIRST/NULLS LAST 语法。你写 ORDER BY score DESC NULLS LAST 会报错：ERROR 1064 (42000)。
- PostgreSQL/Oracle/SQL Server 2012+ 都原生支持，且位置必须紧贴单个排序项，如
ORDER BY score DESC NULLS LAST, name ASC - MySQL 只能靠表达式绕过：核心思路是先按 “是否为 NULL” 分组，再按字段本身排序
- 别信网上说的 “加负号” 技巧（如
-col），它对字符串或DATE完全无效，且可能引发隐式类型转换错误
怎么让 NULL 排最后？三个可靠写法
本质都是构造一个布尔/整数辅助排序键，把 NULL 行统一归到同一侧。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 用
ISNULL(col)（推荐）：ORDER BY ISNULL(score), score→NULL变成1，非NULL是0，升序后NULL在后 - 用
col IS NULL（更标准）：ORDER BY score IS NULL, score→ 同样生效，且在 PostgreSQL 中也兼容（布尔值可直接排序） - 用
IF显式控制：ORDER BY IF(score IS NULL, 1, 0), score→ 逻辑最清晰，适合复杂条件嵌套
注意：如果原排序是 DESC，想让 NULL 排最后，别改第二项为 score DESC，而应保持 score 升序 + 辅助键调整，否则顺序会乱。正确写法是 ORDER BY score IS NULL, score DESC。
GROUP BY + ORDER BY 混用时 NULL 更容易踩坑
当分组字段本身含 NULL（比如 GROUP BY category，而 category 有空值），这个 NULL 分组在最终结果里的位置完全不可控——它可能在第一行，也可能在最后一行，取决于优化器选的执行计划。
- 别依赖
ORDER BY category，它对NULL分组的位置没约束力 - 必须显式写成
ORDER BY category IS NULL, category（NULL分组在最前）或ORDER BY category IS NULL DESC, category（NULL分组在最后） - 如果业务上需要把
NULL分组显示为'Uncategorized'，优先用CASE WHEN category IS NULL THEN 'Uncategorized' ELSE category END替代原字段参与GROUP BY和ORDER BY
跨数据库迁移时最容易翻车的地方，往往就藏在这类看似无害的 NULL 排序默认行为里——它不报错，只悄悄改变结果顺序。
