FIND_IN_SET函数用于判断值是否在逗号分隔字符串中，但不走索引、不支持通配符、要求参数无空格和逗号、类型须一致；推荐改用JSON类型+JSON_CONTAINS或规范化表结构。
FIND_IN_SET函数的基本用法和限制
FIND_IN_SET 是 MySQL 提供的字符串查找函数，用于判断某个值是否出现在以逗号分隔的字符串中。它不支持通配符、不走索引、不能用于 WHERE 子句中对字段做函数运算后匹配（比如 FIND_IN_SET('a', CONCAT(col1, ',', col2)) 会失效），且只接受两个参数：要查找的字符串和目标列表字符串。
常见错误现象：FIND_IN_SET('1', '1,2,3') 返回 1（正确），但 FIND_IN_SET('1', '10,11,12') 也返回 0（正确），而误以为能模糊匹配；更典型的是写成 FIND_IN_SET(id, tags) 却忘记 id 是数字类型，MySQL 会隐式转成字符串，导致 '1' 和 '01' 被视为不同——所以务必确保类型一致。
- 第二个参数必须是纯逗号分隔、**无空格**的字符串（
'1,2,3'可以，'1, 2, 3'不行） - 第一个参数不能含逗号，否则整个匹配逻辑崩溃（函数直接返回 0）
- 如果字段值为
NULL或空字符串，FIND_IN_SET恒返回 0
在WHERE中安全使用FIND_IN_SET查询多选标签
典型场景：用户表有个 roles 字段存着 'admin,editor' 这类值，想查所有有 editor 角色的用户。直接写 WHERE FIND_IN_SET('editor', roles) 是可行的，但要注意以下几点：
- 确保
roles字段是VARCHAR类型，且长度足够容纳所有可能组合（比如VARCHAR(255)） - 避免在大表上高频使用——因为无法利用索引，全表扫描不可避免
- 若需同时匹配多个值（如“既是 admin 又是 editor”），不能链式调用
FIND_IN_SET('admin', roles) AND FIND_IN_SET('editor', roles)，虽然语法合法，但性能极差；应优先考虑规范化设计 - 插入或更新时，务必用程序层去重并排序（如
sort(array_unique(explode(',', $str)))），否则容易出现'admin,admin,editor'这种脏数据
替代方案：JSON列 + JSON_CONTAINS（MySQL 5.7+）
如果你用的是 MySQL 5.7 或更高版本，且可以修改表结构，JSON 类型比逗号分隔字符串更可靠。把 roles 改成 JSON 类型后存为 ["admin","editor"]，就能用 JSON_CONTAINS(roles, '"editor"') 查询。
优势明显：
-
JSON_CONTAINS在有生成列+索引的情况下可走索引（配合CAST(roles->"$" AS CHAR)生成虚拟列） - 天然防逗号/空格歧义，支持嵌套和类型校验
- 插入时可用
JSON_ARRAY_APPEND安全追加，不用手动拼字符串 - 但注意：JSON 列不支持全文索引，且
JSON_CONTAINS第二个参数必须是带双引号的字符串字面量（"\"editor\""），容易漏转义
为什么不该在生产环境长期依赖FIND_IN_SET
根本问题不在函数本身，而在数据建模层面。用逗号分隔字符串本质上是把关系型数据当成了序列化文本处理，导致：UPDATE 时难以原子更新单个 tag；无法约束值域（比如禁止插入不存在的角色名）；无法高效统计某角色的用户数（COUNT 配合 FIND_IN_SET 得全表扫）；备份恢复时可能因字段过长被截断。
真正复杂的地方往往不是怎么写 FIND_IN_SET，而是发现线上慢查询后才意识到：那个当初图快没拆表的 user_tags 字段，现在连加个新索引都救不了。
