FIND_IN_SET是MySQL中唯一能正确判断逗号分隔字符串中是否包含指定值的内置函数，因IN适用于独立值匹配、LIKE易误匹配且无法处理边界，而FIND_IN_SET按完整token拆分比对；但其不走索引、性能差，且暴露设计缺陷，应优先重构为关联表或JSON字段。
Find_in_set 不能替代正规的关系建模，但当你必须查一个用逗号存了多个 ID 的字段（比如 role_ids 字段值是 "1,3,5"），它确实是 MySQL 里唯一能正确做「成员判断」的内置函数——LIKE 或正则会误匹配，IN 又完全不适用。
为什么不能用 IN 或 LIKE？
因为 IN 是用来查「多个独立值」的，不是查字符串里的子项：SELECT * FROM users WHERE role_ids IN ('1', '3') 实际是在比对整个字段值是否等于 '1' 或 '3'，而你的字段存的是 '1,3,5'，永远不匹配。
LIKE 更危险：WHERE role_ids LIKE '%1%' 会把 '11'、'21'、'1,3' 全部拖进来。哪怕加逗号边界 LIKE '%,1,%'，也漏掉开头和结尾的值（如 '1,3,5' 中的 1 和 5）。
Find_in_set 是专为这个场景设计的：它把第一个参数当作「要找的值」，第二个参数当作「逗号分隔的字符串」，内部按完整 token 拆分比对。
Find_in_set 的基本用法和参数顺序
语法固定：FIND_IN_SET(needle, haystack)，返回非零整数表示存在（位置从 1 开始），返回 0 表示不存在。
常见写法：
SELECT * FROM users WHERE FIND_IN_SET('3', role_ids) > 0;注意点：
-
needle必须是字符串字面量或字符串表达式，不能是数字字段（如FIND_IN_SET(role_id, '1,2,3')是错的；若要反向查，得用其他方式） -
haystack字段值**不能含空格**，FIND_IN_SET('3', '1, 3, 5')会失败，因为空格被当作文本一部分，实际查找的是'3'是否等于' 3' - 该函数**不走索引**，字段值越长、记录越多，性能越差——别在百万级表上无条件用它
如何安全地配合其他条件提升查询效率
单靠 FIND_IN_SET 很难优化，但可以缩小扫描范围：
- 先用主键、状态、时间等高区分度字段过滤：
WHERE status = 'active' AND FIND_IN_SET('3', role_ids) > 0 - 如果业务上角色 ID 有层级（比如 1 总是管理员），可加前置判断：
WHERE role_ids LIKE '1%' OR FIND_IN_SET('3', role_ids) > 0（LIKE '1%'可走索引） - 避免在
ORDER BY或GROUP BY中使用它，会导致全表计算 - 临时补救：给
role_ids加生成列 + 索引（MySQL 5.7+）：ALTER TABLE users ADD COLUMN role_3 TINYINT GENERATED ALWAYS AS (FIND_IN_SET('3', role_ids) > 0) STORED;然后建索引：CREATE INDEX idx_role_3 ON users(role_3)。但这只对固定 ID 有效，不通用。
真正该警惕的，是那个逗号分隔的字段本身
很多人用 FIND_IN_SET 是为了“快速上线”，结果半年后发现：无法高效查「同时拥有角色 2 和 4 的用户」，无法统计「每个角色有多少用户」，连加个新角色都要 CONCAT + REPLACE 防重复——这些都不是函数能解决的。
如果表已上线且数据量不大，优先考虑一次性拆表（新建 user_roles 关联表）；如果改不动，至少把 role_ids 字段类型改成 JSON，用 JSON_CONTAINS 替代，至少语义清晰、支持部分索引。
