优先选COALESCE。它标准、跨数据库兼容，支持多参数且类型推导更安全；ISNULL是SQL Server私有函数，仅两参数并强制转为第一参数类型，易致截断或隐式转换错误，且不兼容PostgreSQL/MySQL/Oracle。
视图里NULL值不显示，用ISNULL还是COALESCE？
优先选COALESCE。它标准、跨数据库兼容，且支持多参数；ISNULL是SQL Server私有函数，只认两个参数，还强制返回第一个参数的数据类型——容易悄悄截断或隐式转换出错。
比如ISNULL(name, 'N/A')中，如果name是VARCHAR(10)，那'N/A'也会被截成VARCHAR(10)，看着没事，但万一后续改成VARCHAR(2)字段，就真截了。
-
COALESCE按参数顺序取第一个非NULL值，类型由所有参数共同推导（更安全） -
ISNULL只看第一个参数类型，第二个参数强行转成它——哪怕你写ISNULL(price, 999.999)，结果也可能变成999.99 - PostgreSQL/MySQL/Oracle都不认
ISNULL，视图一迁移就报错
在CREATE VIEW里写NULL处理，要注意字段别名和类型推导
视图字段类型由SELECT子句表达式决定，而COALESCE的类型推导规则会直接影响下游应用读取结果的精度和长度。
例如：COALESCE(phone, mobile, 'N/A')，如果phone是VARCHAR(20)、mobile是VARCHAR(15)，那最终字段类型通常是VARCHAR(20)；但加个'Not provided'进去，长度就可能跳到VARCHAR(15)甚至更高，取决于数据库实现。
- 显式用
CAST包裹，比如COALESCE(CAST(phone AS VARCHAR(50)), CAST(mobile AS VARCHAR(50)), 'N/A')，避免类型抖动 - 别依赖“看起来一样”——
COALESCE(col, '')和COALESCE(col, ' ')在某些版本SQL Server里推导出的长度不同 - 视图一旦创建，字段类型就固定了；改源表字段长度，不自动更新视图定义
WHERE条件里对NULL视图字段过滤，为什么col = NULL永远不成立？
因为NULL参与任何比较运算（=、!=、>等）都返回UNKNOWN，不是TRUE也不是FALSE，所以WHERE col = NULL查不到任何行——包括NULL本身。
正确写法永远是WHERE col IS NULL或WHERE col IS NOT NULL。就算你在视图里用COALESCE(col, 'MISSING')把NULL转成了字符串，那过滤也得针对那个新值，而不是原字段。
- 别在视图里“掩盖”NULL后，还在外面用
WHERE original_col IS NULL——该字段已不存在于视图输出中 - 如果视图输出的是
COALESCE(status, 'unknown')，那想查“原始为NULL”的记录，得写WHERE status_view = 'unknown' - 索引对
COALESCE表达式列默认无效，除非建计算列并索引它
性能敏感场景下，COALESCE会不会拖慢视图查询？
单次调用基本没开销，但嵌套深、参数多、或作用在大字段（如TEXT、JSON）上时，可能触发额外拷贝或类型转换，尤其在WHERE或JOIN条件里用它。
典型问题：把COALESCE(long_text_col, '') LIKE '%abc%'放在WHERE里，数据库没法走索引，还可能对每行都做一次空值判断+字符串拼接。
- 能提前在源表用计算列或默认值解决NULL，就别全压到视图里
- 避免在JOIN ON条件中对字段用
COALESCE，比如ON COALESCE(a.id, -1) = COALESCE(b.id, -1)——这会让优化器放弃哈希连接 - SQL Server中，
COALESCE会被重写成CASE，而ISNULL保留为内置函数，理论上略快，但差异微乎其微，不该为此牺牲可移植性
'N/A'容易，但别人看到它，真能区分“查不到”和“确实为空”吗？ 
