MAKE_SET(bits, str1, str2, ...) 将整数位掩码转为逗号分隔字符串，位索引从0开始对应str1、str2…，bits为0返回空字符串，超出参数个数的位返回空字符串，适用于固定权限集合映射。
MAKE_SET函数怎么用，参数顺序别搞反
MAKE_SET 是 MySQL 里把整数位掩码转成逗号分隔字符串的函数，语法是 MAKE_SET(bits, str1, str2, ...)。第一个参数是整数，后面每个字符串对应一个二进制位（从右往左，第0位对应str1，第1位对应str2，以此类推）。常见错误是以为高位在前，结果传参顺序一错，整个输出就全偏了。
比如：SELECT MAKE_SET(5, 'a', 'b', 'c'); 返回 'a,c' —— 因为 5 的二进制是 101，第0位和第2位为1，所以取第1个和第3个字符串。
- 位索引从0开始，不是从1
- 如果某一位超出你提供的字符串数量（比如
MAKE_SET(8, 'x', 'y')，8 是1000，需要第3位，但只给了两个参数），对应位置返回空字符串，不报错也不跳过 -
bits为0时返回空字符串（不是NULL）
为什么用MAKE_SET而不是FIND_IN_SET或JSON？
当字段存的是位掩码整数（如 TINYINT 存用户权限：1=读、2=写、4=删、8=管理），MAKE_SET 能直接映射出可读标签，比用多个 BIT_AND 判断再拼接更简洁。它比 FIND_IN_SET 快，因为不涉及字符串分割；也比构造 JSON 更轻量，没有序列化开销。
典型场景：权限表里有个 perm_mask 字段存整型权限码，想查出当前用户拥有的权限名列表：
SELECT id, username, MAKE_SET(perm_mask, 'read', 'write', 'delete', 'admin') AS perms FROM users;
- 适合固定集合、成员数 ≤64（MySQL 限制
bits参数最大为BIGINT UNSIGNED，即64位） - 不适合动态增减选项的场景——每次加新权限就得改 SQL 里的参数列表
- 不能用于 WHERE 条件过滤（比如
WHERE MAKE_SET(...) LIKE '%write%'会强制全表扫描，应改用perm_mask & 2）
和BIT_OR、| 运算配合构建集合值
插入或更新时，常需把多个权限“合并”成一个整数。不能靠字符串拼接，得用位运算：|（按位或）组合，~（按位取反）或 & ~ 清除某位。
例如：给用户添加「写」和「删」权限（假设写=2，删=4），当前权限是5（即101，含读+删），要加写权限：
UPDATE users SET perm_mask = perm_mask | 2 WHERE id = 123;
- 新增权限用
|，不是+（虽然数值上有时等价，但语义不清，且+在溢出或负数时行为不可靠） - 撤销权限用
& ~bit，比如清除「写」权限：perm_mask & ~2 - 判断是否拥有某权限必须用
perm_mask & bit≠ 0，不能用=或IN—— 否则会漏掉复合权限
容易被忽略的字符集与排序问题
MAKE_SET 返回结果的字符集继承自第一个字符串参数。如果混用不同字符集（比如前几个是 utf8mb4，最后一个是 latin1），MySQL 可能隐式转换失败或截断，尤其在严格模式下会报错 Illegal mix of collations。
- 所有字符串参数统一用
utf8mb4字符集，可在 SQL 前加SET NAMES utf8mb4; - 返回值默认无排序保证——位顺序决定输出顺序，不是按字母或定义顺序；如果业务要求固定顺序（比如总让 'admin' 排最后），得靠应用层后处理
- 如果集合项含逗号、单引号等特殊字符，
MAKE_SET不做转义，直接拼入结果，下游解析时需注意
位掩码本身不难，难的是整个链路的一致性：建表时约定好每位含义、应用写入时用位运算、查询展示用 MAKE_SET、权限校验仍回到 & 判断——少一环，集合就变成黑盒。
