FIND_IN_SET不能用=或LIKE替代，因=需整串匹配而LIKE会误匹配“13”等子串，该函数专为逗号分隔字符串设计，仅精确匹配完整子项，且要求str不含逗号、strlist为合法逗号分隔格式，参数顺序错误将恒返回0。
为什么 FIND_IN_SET 不能用 = 或 LIKE 替代
因为字段存的是逗号分隔的字符串（比如 "1,3,5"），直接用 = '3' 会完全匹配整串，LIKE '%3%' 又可能误中 "13" 或 "31"。而 FIND_IN_SET 是专为这种场景设计的内置函数，它把字符串按逗号切开、逐项比对，只认完整子项。
注意：它只支持单个查找值，不支持通配符或正则，也不能反过来查“某个集合是否包含字段值”（即不能把字段当 search 参数）。
FIND_IN_SET 的参数顺序和常见错误
语法是 FIND_IN_SET(str, strlist)，第一个参数是你要找的值（必须是字符串），第二个参数是逗号分隔的字符串字段或字面量。顺序反了会返回 0（即“没找到”），但不会报错，容易误判。
- ✅ 正确：
FIND_IN_SET('3', category_ids)—— 查字段category_ids是否含'3' - ❌ 错误：
FIND_IN_SET(category_ids, '3')—— 永远返回0，因为category_ids是一串带逗号的文本，不是合法的strlist格式 - ⚠️ 注意：
str不能含逗号，否则会被截断；strlist开头/结尾/中间的空格会被忽略，但两端引号必须一致（全用单引号或全用双引号）
在 WHERE 和 ORDER BY 中怎么安全使用
它返回的是位置序号（从 1 开始）或 0，所以通常配合 > 0 判断存在性，而不是直接用返回值做逻辑运算。
SELECT * FROM products
WHERE FIND_IN_SET('2', tags) > 0;如果想按匹配位置排序（比如让含 '2' 且排第一的记录靠前），可以：
SELECT * FROM products
ORDER BY FIND_IN_SET('2', tags) DESC;但要注意：NULL 字段或空字符串会导致 FIND_IN_SET 返回 NULL，参与比较时可能被排除——需要显式处理：
- 加
IS NOT NULL过滤：WHERE FIND_IN_SET('2', tags) IS NOT NULL AND FIND_IN_SET('2', tags) > 0 - 或用
COALESCE统一为 0：WHERE COALESCE(FIND_IN_SET('2', tags), 0) > 0
性能差的根本原因和替代建议
FIND_IN_SET 无法使用索引，每次都要全表扫描 + 字符串拆分，数据量一过万就明显变慢。它本质是反范式设计的补救措施，不是长期方案。
真正该做的，是拆表：把多值关系建一张关联表（如 product_tags(product_id, tag_id)），然后用 JOIN 或 EXISTS 查询。如果暂时不能改结构，至少确保被查字段加了 GENERATED COLUMN + INDEX（MySQL 5.7+）来加速固定模式的查找，但依然不如原生关系模型可靠。
临时应急时，别在大表的 ORDER BY 里用它做排序依据，也别嵌套在子查询里反复调用——这些地方最容易暴露性能瓶颈。
