LIKE '%tag%'在JOIN中导致全表扫描，索引失效，1万×1万行需1亿次运算；位运算用二进制位映射标签（如news→1、live→4），实体存为bit值（如news+live=5），关联用(a.tag_bits & b.tag_bits) != 0，支持索引、毫秒响应，但要求标签≤64个、写入预计算、无重名/层级/权重。
SQL里用LIKE做标签模糊关联，为什么一跑就卡死？
因为LIKE '%tag%'在JOIN条件中会强制数据库对每一对行做全表扫描式字符串比对，索引完全失效。比如A表1万行 × B表1万行，光匹配就要执行1亿次LIKE运算——这不是慢，是根本没法等。
用位运算替代字符串包含，前提是你能改数据结构
位运算是把标签映射成整数的二进制位，例如：标签A→1（即0001），标签B→2（即0010），标签C→4（即0100）。一个实体带A+B+C三个标签，就存为7（0111）。此时两表关联只需：(a.tag_bits & b.tag_bits) != 0。
这种写法天然支持“任意交集”逻辑，且能走索引、毫秒级响应。但必须满足两个硬条件：
- 标签总数不能超过64个（否则超出
BIGINT位宽） - 标签集合在写入时就要预计算好整数值，不能运行时动态解析字符串
- 业务上允许“标签不可重名+无层级+无权重”，否则位图语义会失真
MySQL里怎么安全地把逗号分隔标签转成位值？
别用FIND_IN_SET()或LIKE CONCAT('%',...)——它们都扫全表。正确做法是在应用层或ETL阶段预处理：
假设你有固定标签集：['news','video','live','article']，对应位权分别是1,2,4,8。Python处理示例：
bit_val
- 位运算做主关联条件（可走索引）
- 其他过滤条件尽量用等值或范围查询（如
status = 1、created_at > '2025-01-01'） - 真要文本搜索，单独走
MATCH AGAINST或ES，别塞进JOIN
位运算不是银弹，它只解决“标签集合关系”的那一小块问题；一旦你开始混用字符串模糊逻辑，整个优化就归零了。
