bit_count函数统计的是整数的无符号二进制表示中1的个数，输入必须是非负整数，否则结果不可靠；对字符串、十六进制或有符号负数使用会导致错误或意外结果。
BIT_COUNT函数到底统计什么
BIT_COUNT 统计的是整数的**无符号二进制表示中 1 的个数**，不是字符串、不是十六进制文本，也不是有符号补码下的位模式。比如 BIT_COUNT(5) 返回 2，因为 5 的二进制是 101（两个 1）；BIT_COUNT(0) 返回 0；BIT_COUNT(-1) 在 MySQL 中会先转为无符号等价形式（如 18446744073709551615），结果是 64（在 64 位系统上），这往往不是你想要的。
所以第一步必须确认：你的字段或值确实是非负整数类型（TINYINT UNSIGNED、INT UNSIGNED 等），否则结果不可靠。
常见误用场景和修复方式
直接对字符串或 HEX 字符调用 BIT_COUNT 会出错或返回意外结果：
-
BIT_COUNT('1010') → 报错：Operand should be a number
-
BIT_COUNT(UNHEX('A')) → 返回 BIT_COUNT(10) = 2（因为 UNHEX('A') 得到字节 0x0A，即十进制 10），不是你想统计 "A" 这个字符的 ASCII 二进制中 1 的个数
- 想统计某列是否“启用多个开关位”，但该列是
TINYINT（有符号）且存了负值 → 结果跳变，难以调试
BIT_COUNT('1010') → 报错：Operand should be a number
BIT_COUNT(UNHEX('A')) → 返回 BIT_COUNT(10) = 2（因为 UNHEX('A') 得到字节 0x0A，即十进制 10），不是你想统计 "A" 这个字符的 ASCII 二进制中 1 的个数TINYINT（有符号）且存了负值 → 结果跳变，难以调试正确做法：
- 确保输入是无符号整数：用
CAST(col AS UNSIGNED)或建表时定义为INT UNSIGNED - 若原始数据是十六进制字符串（如
'FF'），先转数字：CONV('FF', 16, 10)，再套BIT_COUNT - 若需统计某标志字段中开启的 bit 数（如权限掩码），确认该字段语义上就是位图，且只写入非负值
实际查询示例与性能注意点
假设有一张用户权限表，perms 列是 INT UNSIGNED，每个 bit 代表一个功能开关：
SELECT user_id, perms, BIT_COUNT(perms) AS active_bits
FROM users
WHERE BIT_COUNT(perms) > 3;
这个查询能跑，但要注意：
-
BIT_COUNT是计算型函数，无法走索引 →WHERE BIT_COUNT(perms) > 3会全表扫描 - 如果频繁按“开启位数范围”查询，建议额外加一列
bit_count_cache TINYINT UNSIGNED并用触发器或应用层维护 - 在 MySQL 8.0+ 中，可建函数索引：
CREATE INDEX idx_bitcount ON users ((BIT_COUNT(perms)))，但仅限于生成列语法支持的上下文（如虚拟列）
跨数据库兼容性陷阱
BIT_COUNT 是 **MySQL 特有函数**，PostgreSQL、SQL Server、SQLite 都不支持同名函数：
- PostgreSQL：用
BIT_COUNT(CAST(x AS BIT(64))) 不行；得用 LENGTH(REPLACE(TRANSLATE(x::text, '0', ''), '1', ''))（低效）或自定义函数
- SQL Server：用
(x & 1) + ((x >> 1) & 1) + ... 手动展开，或 COUNT(*) 配合 CTE 拆位
- SQLite：无内置函数，需在应用层处理或用扩展
BIT_COUNT(CAST(x AS BIT(64))) 不行；得用 LENGTH(REPLACE(TRANSLATE(x::text, '0', ''), '1', ''))（低效）或自定义函数(x & 1) + ((x >> 1) & 1) + ... 手动展开，或 COUNT(*) 配合 CTE 拆位一旦代码可能迁移或对接多数据库，别把 BIT_COUNT 当成通用能力写死在 SQL 里。位统计逻辑尽量下沉到应用层，或者用可移植的表达式替代（尽管更啰嗦）。
最常被忽略的一点：BIT_COUNT 对 NULL 返回 NULL，不是 0 —— 如果字段允许为空，记得加 IFNULL(BIT_COUNT(col), 0) 显式处理。
