bit_count函数统计整数二进制中1的个数，遇null返回null而非0，需用coalesce转0；不支持字符串或json直接输入，注意mysql 5.7/8.0在类型转换和大整数处理上的差异。
BIT_COUNT 函数怎么用才不踩空值坑
BIT_COUNT 只接受整数类型（TINYINT 到 BIGINT），传入 NULL 会直接返回 NULL，不是 0。这在聚合统计时容易漏掉记录，比如你查「有多少用户开启了至少一个权限位」，却因某行 permission_mask 为 NULL 导致结果少算。
- 用
COALESCE(permission_mask, 0)包一层再进BIT_COUNT，确保空值转为 0 - 别在
WHERE条件里直接写BIT_COUNT(col) > 0——如果col是NULL，整个表达式为NULL，该行被过滤掉，但你可能想把它当「无权限」处理 - 注意字段类型：如果存的是字符串如
'1010'，BIT_COUNT会先转成十进制整数 10，再算二进制 1010 的 1 的个数（即 2），而不是按字符串逐位解析
和 BIT\_AND / BIT\_OR 搭配做权限交集或并集统计
单靠 BIT_COUNT 只能算“总开启数”，真要分析权限重叠（比如「同时有编辑+删除权限的用户有几个」），得先用位运算收缩维度，再计数。
- 查「同时拥有第 1 位和第 3 位权限（假设从 0 开始编号）」的用户数：
SELECT COUNT(*) FROM users WHERE (permission_mask & 5) = 5（因为5 = 101₂） - 查「任意开启第 0 或第 2 位权限」的人数：
SELECT COUNT(*) FROM users WHERE permission_mask & 5 > 0 -
BIT_COUNT配合BIT_AND可算「全员公共权限位数」：SELECT BIT_COUNT(BIT_AND(permission_mask)) FROM users，但要注意：只要有一行是0或NULL，BIT_AND结果就崩成0或NULL
为什么 BIT\_COUNT(15) 返回 4 而不是 15
这是最常被误解的一点：BIT_COUNT 数的是整数**二进制表示中 1 的个数**，不是数值本身。15 的二进制是 1111，所以返回 4。
- 常见误用：
BIT_COUNT(255)→ 实际是11111111₂，结果为 8，不是 255 - 想还原「某个掩码值对应哪些权限位被设为 1」，不能只靠
BIT_COUNT，得用循环位移或联合POW(2, n)做掩码测试 - 性能上，
BIT_COUNT是内置 C 函数，比手写CONV+ 字符串拆分快一个数量级，但比普通整数比较仍略重，高频查询中避免在ORDER BY或GROUP BY里裸用
MySQL 5.7 和 8.0 在 BIT\_COUNT 行为上的关键差异
主要差在隐式类型转换和大整数支持：
- MySQL 5.7 对超
BIGINT UNSIGNED范围的值（比如18446744073709551615）会静默截断，BIT_COUNT算的是截断后的值；8.0 支持完整 64 位无符号，行为更可预期 - 5.7 中若字段是
DECIMAL类型，BIT_COUNT会先转成DOUBLE再转整数，可能丢失精度（如BIT_COUNT(9223372036854775807.0)在某些版本返回错误值）；8.0 改进后优先走整数路径 - 所有版本都不支持对 JSON 字段直接用
BIT_COUNT，必须先CAST(json_col AS UNSIGNED)，且仅当 JSON 值是纯数字时才安全
NULL 掩码正在悄悄吃掉一行数据，或者没发现 DECIMAL 字段在 5.7 下早把高位比特吞掉了。
