嘿，这个问题我之前踩过坑！咱们先搞清楚为啥你的SQL没拿到预期结果，再聊聊几种解决办法，包括最推荐的长期优化方案～

核心问题出在你对IN操作符的理解上：MySQL的IN是用来匹配离散的、独立的值列表的，但你的f.field_containing_values_separated_by_comma是一个完整的字符串（比如'1,3,5'）。

举个例子，当b.id=1时，你的条件b.id IN(f.field_containing_values_separated_by_comma)其实等价于1 IN ('1,3,5')——MySQL会把整个字符串当成单个元素去匹配，显然1和'1,3,5'不是同一个值，所以匹配失败。它根本不会去解析字符串里的逗号，把它拆成多个值来判断。

根据你的场景，我推荐三种方案，优先级从高到低：

1. 重构数据库表结构（最优解） #

从数据库设计的角度来说，把多个值塞进一个VARCHAR字段里，违反了第一范式（1NF）——每个列应该只存储原子值。长期来看，最好的做法是新建一张关联表（比如foo_bar），用来存储foo和bar的多对多关系：

然后你的查询可以改成这样：

SELECT DISTINCT f.* 
FROM foo f
INNER JOIN foo_bar fb ON f.id = fb.foo_id
INNER JOIN bar b ON fb.bar_id = b.id
WHERE b.id IN (1,2,3);

用DISTINCT或者GROUP BY f.id可以避免返回重复的foo记录。这个方案的优势非常明显：

• 可以给foo_bar的foo_id和bar_id建立联合索引，查询性能拉满
• 数据结构更规范，后续维护、扩展（比如统计关联数量）都更方便
• 完全避免了字符串解析带来的各种坑

2. 使用MySQL的FIND_IN_SET函数（临时过渡方案） #

如果暂时没法改表结构，可以用MySQL专门为逗号分隔字符串设计的FIND_IN_SET函数，它会在字符串里查找指定值的位置，找到就返回大于0的数字：

SELECT f.* 
FROM foo f 
INNER JOIN bar b ON FIND_IN_SET(b.id, f.field_containing_values_separated_by_comma) > 0
WHERE b.id IN (1,2,3);

这个方法能解决你的问题，但要注意：它无法利用索引，如果foo表的数据量很大，全表扫描会导致查询速度很慢，所以只适合小数据集临时用。

3. PHP端预处理条件（应急方案） #

如果以上两种都暂时没法实施，也可以在PHP端构造精确的LIKE条件，避免误匹配（比如防止把10当成1）：

// 目标ID列表
$targetIds = [1, 2, 3];
$conditions = [];

// 为每个ID构造覆盖开头、中间、结尾的匹配条件
foreach ($targetIds as $id) {
    // 注意：这里一定要用预处理语句转义，避免SQL注入！
    $escapedId = $pdo->quote($id);
    $conditions[] = "
        f.field_containing_values_separated_by_comma LIKE CONCAT('%,', {$escapedId}, ',%')
        OR f.field_containing_values_separated_by_comma LIKE CONCAT({$escapedId}, ',%')
        OR f.field_containing_values_separated_by_comma LIKE CONCAT('%,', {$escapedId})
        OR f.field_containing_values_separated_by_comma = {$escapedId}
    ";
}

$whereClause = implode(' OR ', $conditions);

// 最终SQL
$sql = "
    SELECT f.* 
    FROM foo f 
    INNER JOIN bar b ON b.id IN (1,2,3)
    WHERE ({$whereClause})
";

⚠️ 特别提醒：一定要用PDO或mysqli的预处理/转义方法处理ID，绝对不能直接拼接字符串，否则会有SQL注入风险！这个方案同样存在性能问题，只适合应急。

内容的提问来源于stack exchange，提问作者Joseph Bada