FIND_IN_SET()是 MySQL 里一个「看着简单、用着危险」的字符串查找函数——它只适合小数据量、低频查询、临时补救场景，绝不该出现在核心业务表结构设计中。
什么时候必须用 FIND_IN_SET()
？
只有当你面对的是已上线、无法改表结构的遗留系统，且字段存的是逗号分隔值（如
roles字段值为
'admin,user,editor'），又急需快速查出含某个角色的用户时，才考虑它。 ✅ 合理场景：后台运营临时导出“带 vip 标签的用户”，表没建关联表、也没 JSON 字段 ✅ 合理场景：测试环境快速验证逻辑，不追求性能 ❌ 绝对避免：高并发接口、日活百万级系统的 WHERE 条件、订单/用户主表查询 ❌ 绝对避免：把
FIND_IN_SET()套在索引字段上幻想能走索引（它完全不走索引）
SELECT * FROM users WHERE FIND_IN_SET('vip', user_tags) > 0;
FIND_IN_SET()
的三个致命限制
不是语法写错才出问题，而是设计层面就埋了雷：
逗号是硬分隔符，不能处理含逗号的值：比如查FIND_IN_SET('a,b', 'a,b,c') → 返回 0（因为函数把整个
'a,b'当作一个待匹配项，而列表里只有
'a'、
'b'、
'c'三个独立项） 大小写敏感：
FIND_IN_SET('Admin', 'admin,user') → 返回 0NULL 和空字符串全返回 NULL 或 0，但含义不同：
FIND_IN_SET(NULL, 'a,b')→
NULL；
FIND_IN_SET('', 'a,b') → 0；
FIND_IN_SET('a', '') → 0—— 判断时必须写成
> 0，不能只写
IS NOT NULL
比 FIND_IN_SET()
更靠谱的替代方案
如果还能动表结构，立刻停用它。以下方案按推荐优先级排序：
关联表（最优）：新建user_roles(user_id, role_id)，用 JOIN + 索引，支持任意复杂查询 JSON 字段（MySQL 5.7+）：把
roles改成
JSON类型，用
JSON_CONTAINS(roles, '"admin"')，可配合生成列+索引加速 SET 类型（仅限固定枚举值）：定义
roles SET('admin','user','vip')，此时 FIND_IN_SET()会被优化为位运算，但灵活性极差
别信“加个函数索引就能提速”——
FIND_IN_SET()本身无法被索引覆盖，所谓“优化”只在
strlist是
SET列时才生效，普通字符串字段无效。
真要用，至少守住这三条底线
WHERE 条件里永远写FIND_IN_SET('xxx', field) > 0，别漏掉 > 0确保
str参数不含逗号、单引号、反斜杠等特殊字符（否则需预处理或转义） 在 WHERE 中避免嵌套调用，例如不要写
FIND_IN_SET(UPPER('a'), LOWER(tags)) —— 性能雪崩
说到底，
FIND_IN_SET()是数据库设计欠债后的止痛片，不是维生素。用它一时爽，查慢报警火葬场。
