视图中百分比计算必须同时处理除零和整数截断，否则报错或结果为0；应使用NULLIF(den,0)防除零，并用num1.0/NULLIF(den,0)100转浮点避免截断，且不拼接'%'符号。
视图里一查就报错：Msg 8134, Level 16, State 1
只要视图定义中包含 num / den 这类裸除法，且某条记录的 den 字段值为 0，PostgreSQL 和 SQL Server 就会直接中断整个查询，抛出 Divide by zero error encountered。这不是数据缺失，是语法级报错——连 NULL 都不给你返回。
原因在于：视图的定义是静态的，数据库不会提前扫描所有分母是否为 0；它会在执行时逐行计算，遇到第一个 0 就崩。CASE WHEN 在聚合场景（如 SUM(a) / COUNT(b)）中根本不可用，因为聚合函数不能出现在 WHERE 或 CASE 的判断条件里。
-
NULLIF(den, 0)是唯一能嵌入任意表达式位置的安全兜底：当den = 0时返回 NULL，否则返回原值 - 后续再做除法时，任何数 ÷ NULL = NULL，不报错，也不中断查询
- 别写
CASE WHEN den = 0 THEN 0 ELSE num / den END—— 视图里它看起来能用，但一旦den来自 JOIN 或子查询，逻辑就不可靠
为什么只用 NULLIF 还不够：整数除法先截断，结果还是 0
即使加了 NULLIF 防住了除零，如果 num 和 den 都是整型字段，num / NULLIF(den, 0) 仍可能返回 0。比如 3 / 5 在整数上下文中就是 0，不是 0.6；再乘 100 还是 0。
必须同步解决类型问题：
- 最轻量写法：
num * 1.0 / NULLIF(den, 0)——* 1.0强制提升为浮点，兼容所有主流数据库 - 需要控制小数位时，PostgreSQL/SQL Server 推荐：
ROUND(num * 100.0 / NULLIF(den, 0), 2)::DECIMAL(5,2) - MySQL 中避免用
DECIMAL(10,2)做 CAST，容易因精度声明引发隐式截断；100.0比100.00更安全
要不要给百分比加 % 符号或格式化？
不要。视图里拼接 '%' 或调用 FORMAT()、TO_CHAR()，会让字段变成字符串类型。后果很实际：
- 导出到 Excel 后无法直接求均值、排序、画趋势图
- 下游应用做
WHERE rate > 5会失败（字符串比较 vs 数值比较） - SQL Server 的
FORMAT()不可索引，性能差；PostgreSQL 的TO_CHAR()返回text，类型污染严重
正确做法：视图只返回纯数值，例如 ROUND(num * 100.0 / NULLIF(den, 0), 2)；格式化交给 BI 工具、前端或报表层做。
性能陷阱：NULLIF + 类型转换在复杂视图里会被反复执行
如果 den 本身来自多表 JOIN 或窗口函数（比如 COUNT(*) OVER (PARTITION BY category)），那么每次查询该视图，数据库都会重新算一遍 NULLIF(den, 0) 和类型转换。这个开销在大数据量下会明显放大。
这时候得权衡：
- 宁可在源表或中间物化视图里冗余一个非空标志字段（如
den_safe），或预计算好分母值 - 避免在核心视图里嵌套过深的 NULLIF + CAST + ROUND 组合
- 尤其注意：视图定义不缓存中间结果，每查一次，整条表达式重跑一次
真正容易被忽略的是——你写的那行看似简洁的 ROUND(a * 100.0 / NULLIF(b, 0), 2)，背后可能正拖慢整个报表接口的响应时间。
