FIND_IN_SET不能用=或IN替代，因为后者匹配整个字符串而非逗号分隔的单个值；它专为反范式设计，按位置返回索引（从1开始），但不支持空格、不走索引、性能差且难以维护。
为什么 FIND_IN_SET 不能用 = 或 IN 替代
当你字段存的是 1,3,5 这种逗号分隔字符串时，WHERE status = '3' 会完全匹配整串，WHERE status IN ('3') 同样无效——因为数据库把它当做一个完整字符串，不是集合。而 FIND_IN_SET 是 MySQL 专门为此类反范式设计提供的函数，它把第一个参数当作「要找的值」，第二个参数当作「逗号分隔的字符串」，内部逐项比对（注意：不支持空格、不区分大小写、不走索引）。
-
FIND_IN_SET('3', '1,3,5')返回2（位置从 1 开始） -
FIND_IN_SET('4', '1,3,5')返回0 -
FIND_IN_SET('3', '1, 3, 5')返回0（含空格就失败）
基本用法：查单个值是否在列表中
最常见场景是权限或状态字段，比如用户有多个角色 ID 存在 role_ids 字段里：
SELECT * FROM users WHERE FIND_IN_SET('5', role_ids) > 0;注意必须加 > 0 判断，因为函数返回 0 表示未找到；直接写 WHERE FIND_IN_SET('5', role_ids) 在某些旧版本 MySQL 中可能被当成布尔真（非零即真），但语义不清且不可靠。
- 参数顺序固定：
FIND_IN_SET(needle, haystack)，不能颠倒 -
haystack必须是字符串类型（VARCHAR、TEXT），不能是数字或 NULL - 如果
haystack为NULL，整个函数返回NULL，导致该行被过滤掉
多值查询：一次查多个 ID 怎么办
FIND_IN_SET 本身不支持数组或多个待查值，想查「是否包含 2 或 7 或 9」，只能用 OR 拼接：
SELECT * FROM users
WHERE FIND_IN_SET('2', tags) > 0
OR FIND_IN_SET('7', tags) > 0
OR FIND_IN_SET('9', tags) > 0;这种写法性能差，且无法利用索引。更糟的是，如果字段里有空格、全角逗号、或开头结尾有空格（如 ' 1,2 ,3 '），FIND_IN_SET 就失效。
- 别试图用
REPLACE清理空格再套用：FIND_IN_SET('2', REPLACE(tags, ' ', ''))会破坏原始数据语义，且无法索引 - 真正需要多值匹配又要求性能，应改用关联表（
user_tags）+JOIN或EXISTS - MySQL 8.0+ 可考虑
JSON_CONTAINS配合 JSON 字段，但前提是数据已规范存储为 JSON
替代方案和上线前必须检查的坑
线上系统一旦用了 FIND_IN_SET，往往意味着 schema 设计已偏离关系型原则。上线前务必确认：
- 字段内容是否真的没有空格、制表符、全角字符（可用
SELECT tags, LENGTH(tags), HEX(tags) FROM users LIMIT 5抽样检查） - 查询量大时，该字段是否出现在高频 WHERE 条件中——若如此，响应延迟和慢查询日志会立刻暴露问题
- 应用层有没有做缓存？因为这类查询几乎无法有效缓存结果（值组合太多）
- 备份/同步工具（如 mysqldump、Canal）能否正确处理该字段？某些工具对特殊字符敏感
最麻烦的不是语法怎么写，而是当某天业务要支持「标签搜索+排序+分页」时，你会发现所有基于 FIND_IN_SET 的查询都得重写，而且没法加索引加速。
