FIND_IN_SET()是MySQL唯一能精确匹配逗号分隔字符串中子项的函数，=仅支持全字段相等，LIKE会误匹配（如查'1'命中'11'），且该函数不走索引、参数不能含空格或NULL。
为什么 FIND_IN_SET 不能用 = 或 LIKE 替代
因为 FIND_IN_SET 是 MySQL 唯一能正确处理「逗号分隔字符串中精确匹配子项」的内置函数。用 = 只能全字段相等，LIKE '%value%' 会误匹配（比如查 '1' 会命中 '11,12'），而正则又慢且不索引友好。
它本质是把字符串按逗号切开、逐个比对，返回位置（从 1 开始），没找到返回 0。所以判断存在性必须写成 FIND_IN_SET('x', field) > 0，不是 > 1 或 != 0（虽然效果一样，但语义上 > 0 最准确）。
FIND_IN_SET 的参数顺序和类型限制
函数签名是 FIND_IN_SET(str, strlist)，第一个参数是你要查的值（必须是字符串），第二个是逗号分隔的源字符串字段。两个参数都不能是 NULL，否则整个表达式返回 NULL —— 这会导致 WHERE 条件过滤掉整行，即使该字段实际有值。
-
str不能含逗号，否则会被截断（只取第一个逗号前的部分） -
strlist开头/结尾的空格会被保留，所以'a, b, c'中查'b'会失败，得用' b'或先TRIM - 不支持列名作为第一个参数，即
FIND_IN_SET(tag_name, 'a,b,c')是合法的，但反过来不行
在 WHERE 和 ORDER BY 中的实际写法
常见场景是查「属于某标签集合的文章」：SELECT * FROM posts WHERE FIND_IN_SET('tech', tags) > 0。注意 tags 字段必须是 VARCHAR 类型，不能是 TEXT（老版本 MySQL 会报错，8.0+ 虽允许但性能差）。
如果要按匹配位置排序（比如让包含 'top' 的排前面）：ORDER BY FIND_IN_SET('top', priority_list) DESC，返回 0 的会排最后（因 NULL 或 0 在 DESC 下最小）。
性能上，FIND_IN_SET 完全无法走索引，大数据量时务必加缓存或考虑改用关联表。
替代方案：什么时候该放弃 FIND_IN_SET
当出现以下任一情况，说明设计已到临界点，硬扛只会更痛：
- 查询频率高且单表超 10 万行
- 需要同时查多个值，比如
FIND_IN_SET('a', x) > 0 AND FIND_IN_SET('b', x) > 0 - 字段里开始出现引号、反斜杠、中文逗号等非标准分隔符
- 应用层频繁做
explode(',', $str)再循环查 —— 这说明逻辑早该下沉到关系模型
真正省事的解法不是优化这个函数，是拆成 post_tags 关联表。FIND_IN_SET 只适合低频、小数据、临时救急的场景。
