最稳做法是用count() over()获取全表总行数作分母，再与group by后的count()相除；必须乘100.0防整除截断，并用round(,2)保留两位小数，避免子查询性能损耗和类型转换导致null。
用 GROUP BY + 窗口函数算分组占比最稳
直接在 GROUP BY 后除以总数容易出错——因为聚合后无法直接访问原始行数。正确做法是用窗口函数 COUNT(*) OVER() 拿到总行数，再和分组计数相除。这样既保持分组逻辑，又不丢失全局上下文。
常见错误是写成 COUNT(*) / COUNT(*) 或硬编码总数，结果全为 1 或报错；也有人用子查询，但性能差、可读性低。
-
COUNT(*) OVER()是关键：它不依赖GROUP BY，始终返回全表行数 - 务必显式转换为浮点数，否则整数除法会截断（如 PostgreSQL/MySQL 默认整除）
- 示例：
ROUND(COUNT(*) * 100.0 / COUNT(*) OVER(), 2)得到带两位小数的百分比
MySQL 8.0+ 和 PostgreSQL 写法基本一致
这两者都支持标准窗口函数，语法几乎无差异。但要注意 MySQL 5.7 及更早版本不支持 OVER()，必须改用自连接或变量模拟，可靠性差很多。
SQLite 3.25+ 也支持，但旧版不行；SQL Server 从 2005 就支持，写法一样。
- 别用
SELECT COUNT(*) FROM table嵌套子查询——每次分组都执行一次，N次扫描 - 避免在
WHERE过滤后才算占比：如果先过滤，COUNT(*) OVER()默认仍算全表，需加PARTITION BY或改用FILTER（PostgreSQL） - 若要按条件统计占比（比如只算 status = 'active' 的组内占比），用
COUNT(*) FILTER (WHERE status = 'active') OVER (PARTITION BY category)（PostgreSQL），MySQL 需用SUM(IF(status='active', 1, 0)) OVER (PARTITION BY category)
百分比结果为 NULL？检查空组和数据类型
如果某组没数据，COUNT(*) 为 0，0 除以总数得 0；但更常见的是除零错误或隐式类型转换失败导致 NULL。
尤其在 SQLite 或某些 JDBC 驱动下，整数除法结果为 NULL 而非 0，容易误判为缺失数据。
- 强制转浮点：加
* 1.0或::DECIMAL（PostgreSQL）、CAST(... AS DECIMAL) - 防除零：用
NULLIF(COUNT(*) OVER(), 0)包裹分母，再配合COALESCE(..., 0) - 注意
NULL值是否参与计数——COUNT(col)忽略NULL，COUNT(*)不忽略
导出时百分比显示为小数？格式化留到应用层更安全
SQL 本身不负责展示格式。用 ROUND(..., 2) 是为了计算精度，不是为了加 % 符号。强行拼字符串（如 CONCAT(ROUND(...), '%')）会让字段变成文本，后续排序、求和都失效。
前端或报表工具处理格式更灵活，比如保留小数位、自动补零、本地化千分位等。
- 数据库里存数值型百分比（如
12.34），不是字符串'12.34%' - 如果必须 SQL 层输出带 %，仅限一次性查看，且确认下游不依赖数值运算
- Excel 导入时若识别为文本，大概率是因为 SQL 返回了字符串类型，回头检查
CAST或表达式类型
实际跑起来最常卡在类型转换和空值处理上，不是语法写不对，而是除法那一下没兜住。
