WHERE中不能用= NULL判断NULL值，必须用IS NULL或IS NOT NULL；视图字段NULL行为继承自底层表；推荐在视图定义中用COALESCE或CASE预处理NULL；JOIN时NULL会导致匹配失败，应优先用LEFT JOIN加主键关联；ORDER BY需显式声明NULLS LAST/FIRST以保证跨库一致性。
WHERE条件里不能用= NULL判断NULL值
视图本身不存储数据，只是封装了SELECT语句；所以视图中字段的NULL行为，完全继承自底层表和查询逻辑。最常见的错误是：在基于视图的查询中写 WHERE email = NULL，结果永远查不到任何记录——因为=、!=、对NULL一律返回UNKNOWN，而WHERE只接受TRUE行。
必须改用标准语法：
-
WHERE email IS NULL—— 查出视图里该列为NULL的行 -
WHERE email IS NOT NULL—— 排除NULL，只取有值的行 - 若视图定义中用了表达式（如
COALESCE(phone, mobile)），需对最终别名判断，而非原始列名
视图定义中用COALESCE或CASE提前处理NULL
与其让调用方反复处理NULL，不如在创建视图时就做归一化。比如用户联系方式字段可能来自多个源，直接暴露NULL容易引发下游计算异常。
推荐写法示例：
CREATE VIEW customer_contact AS
SELECT id,
name,
COALESCE(work_phone, home_phone, mobile, '未提供') AS phone_display,
CASE WHEN email IS NULL THEN '缺失' ELSE '已填写' END AS email_status
FROM customers;
这样外部查询无需再判NULL，直接用phone_display参与连接或展示即可。注意：COALESCE按参数顺序取第一个非NULL值，且所有参数类型需兼容（必要时显式转换）。
JOIN时NULL导致匹配失败，LEFT JOIN + IS NULL更可靠
视图常被用于JOIN。如果视图某列含NULL，而你用它去INNER JOIN另一张表，那些NULL值行会直接被过滤掉——不是bug，是SQL标准行为。
想保留NULL行并识别“无匹配”，应：
- 用
LEFT JOIN确保主表行不丢失 - 在ON条件中避免对视图NULL列做等值匹配（如
ON v.phone = t.phone会跳过v.phone为NULL的行） - 改用
ON v.id = t.customer_id这类主键关联，再用WHERE t.id IS NULL找未匹配项
若必须用NULL字段JOIN，可用COALESCE(v.phone, '') = COALESCE(t.phone, '')，但要注意空字符串与NULL语义不同，且可能影响索引使用。
聚合和排序时NULL位置不可控，显式声明NULLS LAST/FIRST
视图上跑ORDER BY phone DESC，不同数据库默认把NULL排最前（PostgreSQL）或最后（MySQL 8.0+、SQL Server）。这会导致业务逻辑错乱，比如“最新联系人”排到了顶部。
解决方法是强制指定：
- PostgreSQL / Oracle / SQL Server（2022+）：
ORDER BY phone DESC NULLS LAST - MySQL不支持
NULLS LAST，改用ORDER BY phone IS NULL, phone DESC - 聚合函数如
AVG()、SUM()天然忽略NULL，但COUNT(*)和COUNT(phone)结果不同，视图文档里得写清楚
真正麻烦的是跨数据库迁移——同一个视图定义，在MySQL和PostgreSQL里ORDER BY行为可能相反，这点容易被忽略。
