BIT_COUNT是MySQL特有函数，用于统计整数二进制中1的个数，适用于权限掩码等场景；PostgreSQL、SQL Server等不支持，需用字符串处理或位运算模拟；使用时须用无符号类型并注意索引失效问题。
BIT_COUNT函数在MySQL中直接统计位数，但其他数据库不支持
MySQL原生提供BIT_COUNT()函数，能直接对整数的二进制表示中1的个数计数，适合状态位（如权限掩码、开关组合）的快速统计。PostgreSQL、SQL Server、SQLite等均无同名函数——硬套会报错Unknown function BIT_COUNT或类似提示。
常见误用场景：把MySQL脚本直接迁移到PostgreSQL，或查文档时没注意数据库方言差异。
- MySQL 5.7+ 和 8.0 都支持
BIT_COUNT(n)，参数为TINYINT/INT/BIGINT，返回BIGINT - PostgreSQL需用
bin(n)::text::int[]+array_length(string_to_array(...), 1)或更稳妥的length(replace(to_char(n, 'FM999999999999999999'), '0', '')) - SQL Server可用
(n & 1) + ((n >> 1) & 1) + ((n >> 2) & 1) + ...（最多64位，手动展开或用CTE递归）
用BIT_COUNT统计用户多选权限时要注意数据类型和符号位
假设用一个TINYINT字段perms存8个布尔权限（bit0～bit7），值为13（二进制00001101）表示启用了第0、2、3位权限，此时BIT_COUNT(perms)返回3，正确。
但若字段定义为TINYINT SIGNED且值为-1（补码全1），BIT_COUNT(-1)在MySQL中返回8（按无符号8位解释），不是预期的“所有位都置1”的逻辑计数——这容易在权限初始化或边界测试时漏掉。
- 务必用无符号类型：
TINYINT UNSIGNED、INT UNSIGNED等，避免符号扩展干扰 - 插入前校验：用
IF(n 拦截负值写入 - 查询时加范围限制：
WHERE perms BETWEEN 0 AND 255（对应TINYINT UNSIGNED）
替代方案：用位运算+条件聚合在跨库场景下保持兼容
当需要兼容多种数据库，或仅需统计特定几位（比如只看低4位权限是否启用），硬依赖BIT_COUNT()反而增加维护成本。更通用的做法是显式检查每一位：
SELECT (user_perms & 1 > 0) + (user_perms & 2 > 0) + (user_perms & 4 > 0) + (user_perms & 8 > 0) AS active_low_bits FROM users;
这段SQL在MySQL、PostgreSQL、SQL Server（语法微调）、SQLite中均可运行，语义清晰，且可精确控制统计范围。
- 每个
(user_perms & X > 0)返回1或0，相加即得置1位数 - 比字符串转换快：避免
to_char/CONVERT等开销，尤其在大表聚合时 - 便于加条件：比如只统计
user_perms & 15（低4位）再计数，无需改函数逻辑
性能陷阱：BIT_COUNT在WHERE子句中无法走索引
WHERE BIT_COUNT(status_flags) = 3这类条件会让MySQL放弃使用status_flags字段上的索引，因为函数作用于列会导致全表扫描。
真实业务中常需要“找出恰好启用3种状态的记录”，若数据量大，响应会明显变慢。
- 预计算列：添加生成列
flag_count TINYINT AS (BIT_COUNT(status_flags)) STORED，并为其建索引 - 或反向建模：用单独的关联表存“启用的状态ID”，用
COUNT(*) GROUP BY user_id代替位运算 - 避免在高并发OLTP查询中频繁调用
BIT_COUNT()做过滤，优先前置到应用层或物化视图
位运算本身很快，但一旦和索引、执行计划、数据分布耦合起来，实际表现可能和直觉相反——这点最容易被忽略。
