MySQL 查询结果本质是数学意义上的集合
因为关系型数据库的理论根基是**集合论**和谓词逻辑，不是“表格”或“列表”。你执行
SELECT * FROM users，MySQL 返回的不是一个按插入顺序排列的“数组”，而是一个无序、无重复（除非显式允许）、不保证顺序的**数学集合**——就像 {3, 1, 4} 和 {1, 3, 4} 是同一个集合一样。 表本身没有行序概念；
INSERT顺序 ≠ 查询返回顺序 不加
ORDER BY的查询，结果顺序是**未定义的**，可能随索引变化、MySQL 版本升级、缓冲区状态甚至服务器负载而改变 这意味着：
LIMIT 10不带
ORDER BY，每次执行可能取到完全不同的 10 行——这不是 bug，是符合标准的行为
UNION / UNION ALL 是最典型的集合操作体现
真正暴露“集合思维”的地方，是当你用
UNION合并两个查询时：它不是拼接字符串，而是做**集合并运算**（
UNION去重，
UNION ALL保留重复），且要求两个结果集结构严格一致——列数相同、对应列类型兼容、顺序对齐。
SELECT id, name FROM active_users UNION SELECT id, name FROM archived_users;
UNION隐含
DISTINCT，会额外排序去重，性能开销大 如果确定无重复或不需要去重，直接用
UNION ALL，快得多 MySQL 目前（截至 2025）**不原生支持
INTERSECT和
EXCEPT**，得用
INNER JOIN或
NOT EXISTS模拟
为什么写 SQL 时总出错？大概率是用了“面向过程”思维
比如习惯性先查出一批 ID 存进临时表，再用这些 ID 去查详情——这本质上是在模拟循环，既慢又难维护。SQL 的正确姿势是声明式地描述“我要什么”，让优化器决定“怎么拿”。
❌ 错误模式：SELECT id FROM orders WHERE status = 'paid'→ 取出 IDs → 在应用层循环调用
SELECT * FROM users WHERE id = ?✅ 正确做法：用
JOIN一次性关联获取：
SELECT u.* FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'子查询也容易误用：
NOT IN (SELECT ...)遇到 NULL 会全失效，应改用
NOT EXISTS
实际开发中必须显式处理的三个“集合特性”
别指望数据库替你记住顺序、去重或补空值——所有关键行为都得靠 SQL 显式表达。
顺序必须靠ORDER BY：哪怕你只想要最新一条记录，也要写
ORDER BY created_at DESC LIMIT 1去重要么？选
UNION还是
UNION ALL？ 别默认以为“合并就要去重”，先确认业务是否真需要 空值参与集合运算会静默失败：比如
IN (1, 2, NULL)等价于
IN (1, 2) OR column = NULL，但后者永远为 FALSE —— 所以涉及 NULL 时优先用
EXISTS或
IS NULL
集合不是抽象概念，是你每次写
SELECT时 MySQL 真正交付给你的东西。忽略它，就等于在用 C 语言写代码却假装自己在用 Python —— 不是不能跑，只是迟早被 undefined behavior 打脸。
