find_in_set无法走索引，因其本质是逐行字符串解析函数，需对每行字段按逗号切分并完整比对，破坏索引有序性，导致explain显示type:all、key:null；而join关联表方案通过范式化建模，使role_id等值查询可真正利用索引，执行计划清晰且支持复杂操作。
为什么FIND_IN_SET无法走索引
FIND_IN_SET本质上是个字符串函数，MySQL必须对每一行的字段值执行完整解析：先按逗号切分、再逐个比对。这意味着即使column_name上有索引，优化器也完全无法利用——因为索引是按完整字符串排序的，而FIND_IN_SET的操作破坏了索引的有序性。
常见错误现象：EXPLAIN显示type: ALL（全表扫描），key: NULL，哪怕表有几百万行，也会扫到底。
- 它不支持前缀索引或函数索引（MySQL 8.0+ 的函数索引也对 FIND_IN_SET 无效）
- 如果字段是
TEXT或长VARCHAR，还会触发额外的磁盘临时表或内存排序 - 在
WHERE子句里嵌套子查询（如FIND_IN_SET(id, (SELECT GROUP_CONCAT(...) FROM ...))），会导致子查询被反复执行，次数 = 主表行数
为什么JOIN替代方案更可靠
把逗号分隔值“摊平”成独立行后，用标准JOIN查，就能真正用上索引。这不是语法糖，而是数据模型回归关系型本质。
使用场景：比如原表users.role_ids VARCHAR(255)存'1,3,7'，应拆出user_roles(user_id, role_id)关联表。
-
user_roles.role_id建普通索引或联合主键，JOIN时直接走ref或eq_ref类型 - 查询逻辑从「在字符串里找」变成「查匹配的外键行」，执行计划清晰可预测
- 支持
COUNT、GROUP BY、范围条件（如role_id BETWEEN 10 AND 20），FIND_IN_SET做不到
临时表法能救急但有边界
当无法改表结构时，用临时表+JOIN是比FIND_IN_SET更可控的兜底方案，尤其适合大IN列表场景。
实操建议：
- 用
CREATE TEMPORARY TABLE temp_ids (id INT PRIMARY KEY)，主键自动建索引 - 批量插入用多值
INSERT，每批≤1000条，避免单次SQL过长或内存溢出 - 别用
MEMORY引擎存超大列表——它受限于max_heap_table_size，超限会静默转磁盘，反而更慢 - 临时表只在当前连接有效，不用手动
DROP，但务必确认连接未复用（如连接池中可能残留）
LIKE和正则只是权宜之计
column_name LIKE '%value%'或REGEXP '(^|,)value(,|$)'看着像能替代，实际更危险。
容易踩的坑：
-
LIKE '%value%'彻底无法走索引，且可能误匹配（'high_value'会被'value'命中） -
REGEXP在MySQL中不支持索引加速，5.7及之前版本甚至不支持[[:<:>这类单词边界，匹配不准</:> - 全文索引（
MATCH ... AGAINST）要求字段类型为TEXT且最小词长，默认停用词干扰大，不适合精确ID匹配
真正难处理的从来不是“怎么写SQL”，而是字段设计时就让FIND_IN_SET成了唯一选择——这时候重构表结构的成本，远低于长期忍受不可控的慢查询。
