= 不能查 NULL 值，需用 IS NULL；数值类型不一致时 MySQL 静默转换、PostgreSQL 报错；浮点数比较应避免 =，改用范围判断。

直接用 = 就行，但要注意 NULL 和数据类型隐式转换这两个坑。

为什么 = 查不到 NULL 值

SQL 中 NULL 不等于任何值，包括它自己。所以 WHERE column = NULL 永远不返回结果。

• 错误写法：SELECT * FROM users WHERE age = NULL; → 无结果
• 正确写法：SELECT * FROM users WHERE age IS NULL;
• 想同时查“等于 25”和“是 NULL”，得拆开写：WHERE age = 25 OR age IS NULL

数值类型不一致时 = 可能静默转换出错

比如把字符串 '123' 和整数 123 用 = 比较，MySQL 会转成数字比，PostgreSQL 则直接报错（类型不匹配）。

• MySQL 示例：SELECT 123 = '123'; → 返回 1（true），但 SELECT 123 = '123abc'; 也返回 1（因为截取开头数字后变成 123 = 123）
• PostgreSQL 示例：SELECT 123 = '123'; → 报错：operator does not exist: integer = text
• 安全做法：显式转换，如 CAST(age AS TEXT) = '25' 或 age::TEXT = '25'（PostgreSQL）

浮点数用 = 比较大概率不准

二进制浮点表示导致 0.1 + 0.2 != 0.3 是常见现象，直接 = 判断几乎必错。

• 别这么写：WHERE price = 19.99（哪怕存的是 DECIMAL，如果计算过程用了 FLOAT 就可能失真）
• 改用范围比较：WHERE ABS(price - 19.99)
• 更稳妥：字段定义为 DECIMAL(10,2)，且所有写入/计算都走定点数运算

真正麻烦的不是语法，而是你查的那列到底是什么类型、有没有被函数或表达式包裹过、上游是否混入了浮点计算——这些都会让看似简单的 = 变成玄学。