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处理示例：
tags = ['news','live'] bit_val = sum(1 << i for i, t in enumerate(['news','video','live','article']) if t in tags) # → bit_val = 1 + 4 = 5
然后INSERT时直接写入bit_val字段。后续JOIN就写成：
SELECT * FROM content c JOIN tag_rule r ON (c.tag_bits & r.required_bits) = r.required_bits;
注意：= r.required_bits表示“必须包含全部指定标签”，若只要求“至少一个”，就用!= 0。
位运算JOIN的坑：别在WHERE里再套LIKE
常见错误是“先位运算粗筛，再LIKE细筛”——比如：
ON (a.bits & b.bits) != 0 WHERE a.name LIKE '%xxx%'
这会导致优化器放弃位运算的索引优势，退化回全表扫描。真正高效的组合是：
- 位运算做主关联条件（可走索引）
- 其他过滤条件尽量用等值或范围查询（如
status = 1、created_at > '2025-01-01'） - 真要文本搜索，单独走
MATCH AGAINST或ES，别塞进JOIN
位运算不是银弹，它只解决“标签集合关系”的那一小块问题；一旦你开始混用字符串模糊逻辑，整个优化就归零了。
