应使用 SUM(CASE WHEN gender='男' THEN 1 ELSE 0 END) 替代 COUNT(CASE...) 避免 NULL 漏计，配合 TRIM、NULLIF、ROUND(x*1000.0/y)/10.0 等确保准确性与鲁棒性。
用 SUM(CASE WHEN ...) 替代子查询或多次扫描
直接在 GROUP BY 中对性别做条件累加，比写两个子查询或 JOIN 男女统计快得多——因为只扫一遍表，避免重复 I/O 和连接开销。
常见错误是写成 COUNT(CASE WHEN gender = '男' THEN 1 END)，看似合理，但遇到 NULL 性别时会漏计（COUNT 忽略 NULL）；而 SUM 对布尔表达式结果更可控。
- 用
SUM(CASE WHEN gender = '男' THEN 1 ELSE 0 END)确保每行都贡献 0 或 1 - 部门字段必须非空，否则
GROUP BY dept会把NULL归为一组，容易被误认为“未知部门” - 如果
gender是ENUM或带空格/大小写不一致（如'Male'、'female'），先统一清洗或加UPPER(TRIM())
避免除零错误：用 NULLIF 包裹分母
当某个部门全员为女性时，男性人数为 0，直接除会导致 Division by zero 错误（PostgreSQL）或 NULL 结果（MySQL 默认），但业务上更希望显示 0.0% 或明确提示无男性。
NULLIF(total, 0) 是最轻量的防御写法：它把分母为 0 的情况转成 NULL，再配合 COALESCE 可控兜底。
- 写法示例：
ROUND(SUM(CASE WHEN gender='男' THEN 1 ELSE 0 END) * 100.0 / NULLIF(COUNT(*), 0), 2) - 不要用
WHERE gender IN ('男','女')预过滤——会丢掉该部门其他性别记录，导致总数不准 - MySQL 8.0+ 支持
SAFE_DIVIDE，但跨库兼容性差，NULLIF更通用
MySQL 与 PostgreSQL 在字符串比较上的隐式陷阱
gender = '男' 在 MySQL 默认 utf8mb4_general_ci 排序规则下不区分大小写和尾部空格，可能把 '男 ' 也匹配进来；PostgreSQL 则严格按字节匹配。
这不是 bug，是设计差异，但会导致比例计算偏差——尤其当录入数据有空格、全角/半角混用时。
- 统一用
TRIM(gender) = '男'消除空格干扰 - 若字段含全角字符（如‘Ｍａｌｅ’），需提前标准化，或用正则：
gender REGEXP '^男$'（MySQL）/gender ~ '^男$'（PG） - 别依赖
COLLATE utf8mb4_unicode_ci解决所有问题——它不处理空格，也不保证跨版本行为一致
当需要精确到小数点后两位且四舍五入时，注意浮点精度边界
ROUND(x * 100.0 / y, 2) 看似稳妥，但 x * 100.0 先转成浮点，再除，可能引入微小误差（如 0.0459999999 显示为 4.59% 而非 4.60%）。
真正稳定的写法是先放大再截断，尤其在报表导出场景下用户对“0.01%”级差异很敏感。
- 推荐：
ROUND(x * 1000.0 / y) / 10.0（先算千分位再降一位，减少中间浮点误差） - 或者用定点数：
CAST(ROUND(x * 10000.0 / y) AS DECIMAL(5,2)) / 100 - 别用
FORMAT()函数——它返回字符串，无法参与后续数值计算或排序
部门男女比例看着简单，但只要数据有空格、编码不一、除零没兜底、或浮点四舍五入多算一位，报表就可能被业务方当场质疑。这些点不在主逻辑里，却决定结果能不能被信任。
