FIND_IN_SET仅适用于已存在反范式设计的旧表临时查询，不能替代规范数据库设计；它会导致索引失效、排序失败、JOIN低效等问题，新建表必须使用关联表而非逗号分隔字段。
为什么 FIND_IN_SET 不能替代正规的数据库设计
FIND_IN_SET 不是为“存储逗号分隔字符串”这个做法正名的，它只是 MySQL 提供的一个补救式函数，用来在**已存在反范式设计**（比如把多个 ID 存成 "1,3,7"）的旧表上临时查数据。直接用它做主查询逻辑，意味着后续会遇到排序失效、索引完全失效、无法高效 JOIN、UPDATE 难以原子化等问题。
如果你正打算新建表并考虑用逗号分隔字段存多值——别这么做。立刻停下来建关联表。FIND_IN_SET 只该出现在迁移过渡期或只读报表场景里。
FIND_IN_SET 的基本用法和参数陷阱
FIND_IN_SET 接收两个参数：FIND_IN_SET(needle, haystack)，其中 needle 必须是单个不含逗号的字符串（不能是变量拼接出的逗号串），haystack 是逗号分隔的字符串字段（如 "1,2,5"）。返回值是位置索引（从 1 开始），没找到返回 0。
-
FIND_IN_SET('3', '1,2,3,4')→ 返回3 -
FIND_IN_SET('3', '1,2,30,4')→ 返回0（注意：不会误匹配30中的3，这是它比LIKE '%3%'安全的地方） -
FIND_IN_SET('a,b', 'a,b,c')→ 返回0（needle里不能含逗号） - 字段值开头/结尾有空格？
FIND_IN_SET不自动 trim，' 1,2,3 '会导致查找'1'失败
WHERE 条件中正确使用 FIND_IN_SET 的写法
想查“用户标签包含 'vip'”的记录，假设字段叫 tags，值形如 "normal,vip,trial"：
SELECT * FROM users WHERE FIND_IN_SET('vip', tags) > 0;必须显式判断返回值 > 0，因为 FIND_IN_SET 在布尔上下文中 0 被当作 false，但非 0 值（如 1、2…）都算 true —— 这点容易忽略导致逻辑错乱。另外注意：
- 不能在
ORDER BY或GROUP BY里用FIND_IN_SET做排序依据，MySQL 8.0+ 会报错或结果不可靠 - 无法利用
tags字段上的普通 B-Tree 索引加速，哪怕你给它加了索引也没用 - 如果
tags是NULL，整个表达式返回NULL，不是 0，所以WHERE FIND_IN_SET(...) > 0会跳过这些行
替代方案：什么时候该放弃 FIND_IN_SET
当出现以下任一情况，说明你已经踩进坑里，该重构了：
- 需要按“包含某标签”的用户数做聚合统计（
COUNT(DISTINCT ...)配合FIND_IN_SET性能极差） - 要查“同时包含
'vip'和'beta'”的用户（FIND_IN_SET('vip', tags) AND FIND_IN_SET('beta', tags)可行但难维护，且无法用索引） - 前端传来的是一组 ID（如
[3,7,9]），你想查所有“至少包含其中一个”的记录（这时得写多个OR FIND_IN_SET(...)，可读性和性能双崩） - 字段长度经常超过 1000 字符，或逗号分隔项超过 50 个（
FIND_IN_SET内部是逐字符扫描，O(n) 时间复杂度）
真正可靠的解法只有一个：拆成关联表，比如 user_tags(user_id, tag)，然后走标准 JOIN 或 EXISTS。FIND_IN_SET 是创可贴，不是止血钳。
