FIND_IN_SET仅适用于无空格、无引号、无嵌套逗号的纯逗号分隔字符串，不支持JSON或SET类型；误用会导致报错、误匹配或全表扫描，根本解法是规范数据建模，改用关联表或JSON函数。
FIND_IN_SET 不是为“集合类型字符串”设计的，它只适用于逗号分隔的纯字符串（且不能含空格、引号、转义字符），直接用它查 JSON 或 SET 类型字段会失败或误匹配。
为什么 FIND_IN_SET 不能处理真正的集合数据
MySQL 的 FIND_IN_SET 函数底层是字符串扫描：它把第一个参数当作子串，在第二个参数（必须是逗号分隔、无空格的字符串）里逐段比对。只要出现完全相等的字段就返回位置，否则返回 0。
常见误用场景包括：
- 在
JSON字段上直接调用：FIND_IN_SET('a', json_column)→ 报错或永远返回 0（因为json_column是对象/数组，不是逗号分隔字符串） - 在
SET类型字段上使用但值含空格：FIND_IN_SET('val 1', set_col)→ 匹配失败（SET存储时自动去空格，但FIND_IN_SET不做清洗） - 字段值含英文逗号但非分隔符：
'apple,banana'被当成两个元素 → 实际只应是一个值
正确使用 FIND_IN_SET 的前提条件
仅当满足全部以下条件时，FIND_IN_SET 才安全可靠：
- 目标字段是
VARCHAR或TEXT，内容格式严格为'a,b,c'（无首尾空格、无引号、无嵌套逗号） - 要查找的值本身不含逗号、空格、单双引号
- 业务允许模糊前缀匹配风险（例如查
'a'会命中'ab,cd'中的'ab'？不会 ——FIND_IN_SET要求**完全相等**，这点比LIKE安全） - 表数据量不大（该函数无法使用索引，全表扫描）
示例有效用法：
SELECT * FROM users WHERE FIND_IN_SET('admin', roles) > 0;其中 roles 字段值为 'user,admin,editor' 或 'admin'，不能是 'user, admin'（含空格）或 '["user","admin"]'（JSON 格式）。
替代方案：什么时候该换别的方法
遇到以下任一情况，请立刻放弃 FIND_IN_SET：
- 字段是
JSON类型 → 改用JSON_CONTAINS(json_col, '"value"')或JSON_SEARCH() - 字段是
SET类型 → 直接用位运算：set_col & 1 << (FIND_IN_SET('val', 'val1,val2,val3') - 1)，或更推荐用原生set_col LIKE '%val%'（需确保枚举值互不为子串） - 需要走索引 → 拆表，用关联表替代逗号分隔字符串（这是根本解法）
- 值含特殊字符 → 先用
REPLACE清洗，但代价高，不治本
比如查 JSON 数组：
SELECT * FROM posts WHERE JSON_CONTAINS(tags, '"mysql") ;（注意
tags 是 JSON 类型，值如 ["mysql","sql"]）
真正麻烦的不是语法怎么写，而是字段设计阶段没想清楚：用逗号分隔字符串存集合，等于主动放弃关系型数据库的约束、索引和一致性能力。哪怕现在 FIND_IN_SET 能跑通，半年后加个统计需求或并发更新，大概率卡在这里。
