SQL中整数相除结果为0是因为截断小数，解决方法是将分子或分母转为非整数类型，如乘1.0；需防范除零错误，推荐用NULLIF配合COALESCE；百分比应实时计算而非存储。
SQL里直接用 / 算百分比为什么结果是0？
因为整数除整数在多数SQL引擎（如MySQL、PostgreSQL默认行为、SQL Server）里会截断小数，返回整数。比如 3 / 5 得 0，不是 0.6。
- 解决办法：至少让分子或分母变成非整数类型——最简单是乘
1.0或加.0 - MySQL中也可用
CAST(3 AS DECIMAL)，但3.0 / 5更轻量 - 注意：PostgreSQL对
INT / INT默认也返回INTEGER，一样要干预 - 别写
3 / 5 * 100，这还是先算整数除法再乘，结果仍是0
保留两位小数的三种可靠写法（按兼容性排序）
不同数据库对四舍五入、截断、显示格式的处理差异大，不能只靠 ROUND() 一招打天下。
-
ROUND(x * 100.0 / y, 2)：通用，但只是四舍五入数值，不控制显示位数（比如25.0可能显示为25） - MySQL用
FORMAT(x * 100.0 / y, 2)：返回字符串，强制补零（25.00），但无法参与后续计算 - PostgreSQL/SQL Server建议用
ROUND(x * 100.0 / y, 2)::DECIMAL(5,2)：既算值又定精度，适合导出或报表字段
分母为0时怎么避免 division by zero 错误？
线上SQL一旦遇到分母动态为0（比如统计某天无订单的转化率），整个查询就崩，不是返回NULL而是报错。
- MySQL：用
NULLIF(y, 0)把分母0转成NULL，再配合COALESCE(..., 0)填默认值 - PostgreSQL/SQL Server：同样用
NULLIF(y, 0)，但注意NULLIF是标准函数，兼容性好 - 别用
CASE WHEN y = 0 THEN 0 ELSE x*100.0/y END——逻辑对，但写法冗长，且容易漏掉ELSE分支里的类型转换 - 真实场景中，分母为0往往意味着指标无意义，返回
NULL比硬填0更合理
百分比字段要不要存进表里？
绝大多数情况——不要。存原始分子、分母，查时实时计算。
- 存百分比会导致数据冗余、更新不一致（比如分母变了，百分比字段忘了同步）
- 如果为了加速查询而加计算列，MySQL 5.7+ 支持
GENERATED COLUMN，PostgreSQL 支持STORED表达式索引，但前提是表达式确定、无副作用 - 真正需要“快”的地方，通常该优化的是索引和聚合逻辑，而不是把计算结果固化
- 唯一常见例外：BI工具要求字段名含
%符号且不允许表达式，这时才考虑视图封装
小数点后留几位，得看业务容忍度；分母是不是0，得看数据有没有空档期；而“存不存结果”，本质是权衡一致性与便利性——后者常被高估。
