find_in_set仅适用于逗号分隔字符串中精确匹配完整值，不支持子串搜索；模糊匹配应使用like或instr，json数组则用json_contains。
FIND_IN_SET 不能用于“字段包含某个字符串”的模糊匹配场景，它只适用于逗号分隔的字符串列表中精确查找单个值。如果你误用它来查类似 LIKE 的效果，结果会出人意料甚至全为空。
为什么 FIND_IN_SET 不等于字符串包含匹配
FIND_IN_SET 的设计目标很窄：判断一个**完整、无空格、无修饰的值**是否存在于一个由逗号分隔的枚举字符串中。它不支持子串搜索、大小写忽略、正则或通配符。
- 输入必须是纯逗号分隔，比如
'apple,banana,cherry'；含空格如'apple, banana'会导致banana查不到 - 被查找项必须完全相等，
FIND_IN_SET('ban', 'apple,banana')返回 0（未找到），哪怕'ban'是'banana'的前缀 - 字段值如果是自由文本（如
'用户提交了香蕉和苹果'），FIND_IN_SET完全无效
真正想查“字段包含某字符串”，该用 LIKE 还是 INSTR
绝大多数情况下，用 LIKE 最直接；需要位置信息或避免 % 模糊开销时，可选 INSTR。
-
WHERE column_name LIKE '%keyword%'—— 简单、通用，注意前后加%才是“包含” -
WHERE INSTR(column_name, 'keyword') > 0—— 返回首次出现位置，0 表示未找到；对索引不友好，但语义更明确 - 若字段是 JSON 数组（如
["apple","banana"]），应改用JSON_CONTAINS，而非FIND_IN_SET - 区分大小写取决于列的 collation；如需强制不区分，可用
LOWER(column_name) LIKE LOWER('%keyword%')
什么情况下才该坚持用 FIND_IN_SET
仅当数据模型本身就把多个离散值存为逗号分隔字符串（反范式设计），且你确定要查的是其中一个完整取值。
- 典型场景：权限字段存为
'read,write,delete'，查用户是否有'write'权限 →FIND_IN_SET('write', permissions) > 0 - 注意：这种设计无法走索引，大数据量时性能差；更好的做法是拆成关联表
- MySQL 5.7+ 推荐用
JSON_CONTAINS存数组，比逗号分隔更安全、可索引
很多人卡在第一步：没确认字段实际存储格式就套用 FIND_IN_SET。先 SELECT column_name FROM table LIMIT 5 看一眼真实值，比翻文档更快定位问题。
