SQL筛选逗号分隔值？多表查询的3种有效技巧

SQL 技巧：如何基于另一表筛选含逗号分隔值的行

处理数据库时，我们有时会遇到不太理想的数据结构，比如在一列中存储了逗号分隔的多个值。当需要根据另一张表的单列值来筛选这些包含列表的行时，标准的 JOIN 操作就不够用了。本文将探讨如何解决这个问题。

问题场景

假设我们有两张表。第一张表 Table1-Released-Software 记录了软件发布及其部署环境：

Table1-Released-Software

Release	Environment
release1	environment1
release2	production
release3	test
release4	test2
release5,release6,release7	production
release8,release9,release10	test3
release11,release12,release13	alpha
release14,release15,release16	beta

注意 Release 列，有些行包含单个发布，而另一些则包含逗号分隔的多个发布。

第二张表 Table2-Monitored-Releases 列出了我们需要重点关注的特定发布和环境组合：

Table2-Monitored-Releases

Release	Environment
release3	test
release4	environment5
release12	alpha
release16	beta

我们的目标是生成一个新表 Table3-filtered-monitored-releases，它只包含 Table1 中那些与 Table2 匹配的记录。匹配规则如下：

1. 两张表的 Environment 列必须完全匹配。
2. Table2 中的 Release 值必须存在于 Table1 的 Release 列中。如果 Table1.Release 是单个值，则需精确匹配；如果是逗号分隔列表，则列表需 包含 Table2.Release 的值。

基于以上规则，期望的输出结果 Table3-filtered-monitored-releases 如下：

Release	Environment
release3	test
release11,release12,release13	alpha
release14,release15,release16	beta

这里解释一下为什么得到这个结果：

• release3 | test：在 Table1 和 Table2 中都存在，完全匹配。
• release4 | test2：虽然 release4 在 Table2 中出现，但 Table2 中的环境是 environment5，与 Table1 的 test2 不匹配，因此排除。
• release11,release12,release13 | alpha：Table1 的环境是 alpha，Table2 中有一条记录 release12 | alpha，环境匹配。同时，Table1 的 Release 列表包含了 Table2 的 release12。因此包含此行。
• release14,release15,release16 | beta：与上一条类似，Table1 的环境 beta 与 Table2 中 release16 | beta 的环境匹配。并且 Table1 的 Release 列表包含 Table2 的 release16。因此包含此行。

标准的 INNER JOIN T1 ON T1.Release = T2.Release AND T1.Environment = T2.Environment 无法处理 Table1.Release 列包含逗号分隔列表的情况。

问题根源分析

这个问题的核心障碍在于 Table1 的 Release 列违反了数据库设计的第一范式（1NF）。第一范式要求表的每个字段都应该是原子的，不可再分的。将多个值（如 release5,release6,release7）存储在一个字段中，使得基于单个值的精确匹配变得复杂。

当你需要查询这个字段中是否 包含 某个特定值时，简单的等号 (=) 比较就行不通了。你需要使用更复杂的字符串搜索技术。

另外，问题中提到，使用的查询语言不支持 FIND_IN_SET 这种专门用于处理逗号分隔字符串的函数，这排除了一个常见的便捷解决方案。

解决方案

针对这种无法使用 FIND_IN_SET 且存在逗号分隔值的情况，我们可以采用以下几种方法。

方案一：使用 LIKE 操作符进行模式匹配

这是最直接的方法，利用 SQL 的 LIKE 操作符进行模糊匹配。但简单的 LIKE '%value%' 存在风险，例如搜索 release1 时可能会错误地匹配到包含 release10 或 release12 的行。

为了确保只匹配完整的发布名称，我们需要一个更健壮的模式。技巧是在待搜索的字符串（Table1.Release）和要查找的值（Table2.Release）两侧都加上逗号，然后进行匹配。

原理与作用:

通过给 Table1.Release 字符串和 Table2.Release 值两边都添加逗号，我们将每个发布名称都“包裹”起来。例如，release5,release6,release7 变成 ,release5,release6,release7,。然后我们查找的模式是 %,release6,%。这样就能确保 release6 是作为一个独立的单元被匹配，而不是作为 release66 或 myrelease6 的一部分。

操作步骤与代码示例:

假设你的 SQL 方言使用 || 进行字符串连接（标准 SQL）或 CONCAT() 函数（如 MySQL/MariaDB）。

使用 CONCAT()（常见于 MySQL 等）：

SELECT T1.Release, T1.Environment
FROM Table1_Released_Software AS T1
INNER JOIN Table2_Monitored_Releases AS T2
  ON T1.Environment = T2.Environment
WHERE
  -- 精确匹配单个 Release 值
  (T1.Release = T2.Release)
  OR
  -- 处理逗号分隔列表的情况
  (
    T1.Release LIKE '%,%' -- 确保 T1.Release 包含逗号，表示它是一个列表
    AND
    CONCAT(',', T1.Release, ',') LIKE CONCAT('%,', T2.Release, ',%')
  );

使用 ||（常见于 PostgreSQL, Oracle, SQLite）：

SELECT T1.Release, T1.Environment
FROM Table1_Released_Software AS T1
INNER JOIN Table2_Monitored_Releases AS T2
  ON T1.Environment = T2.Environment
WHERE
  -- 精确匹配单个 Release 值
  (T1.Release = T2.Release)
  OR
  -- 处理逗号分隔列表的情况
  (
    T1.Release LIKE '%,%' -- 确保 T1.Release 包含逗号
    AND
    ',' || T1.Release || ',' LIKE '%,' || T2.Release || ',%'
  );

注意: 上述 WHERE 子句包含了两种情况：

1. T1.Release = T2.Release：处理 Table1.Release 中只有一个发布名称，且与 Table2.Release 精确匹配的情况 (例如 release3 | test)。
2. CONCAT(',', T1.Release, ',') LIKE CONCAT('%,', T2.Release, ',%') (或 || 版本): 处理 Table1.Release 中包含逗号分隔列表的情况。通过在两端添加逗号，可以确保匹配到的是列表中的一个完整项。T1.Release LIKE '%,%' 是一个优化，可以先判断T1.Release 是否确实包含逗号，如果确定是列表再去进行复杂的 CONCAT + LIKE 判断。

安全与性能建议:

• 性能: LIKE 操作符，尤其是模式以 % 开头时 (LIKE '%,...%')，通常无法有效利用标准 B-Tree 索引。在大型表上，这种查询可能会导致全表扫描，性能较差。如果可能，考虑数据库是否支持针对文本内容的全文索引（Full-Text Indexing），虽然配置和使用更复杂，但性能会好很多。
• 数据一致性: 逗号、空格等分隔符的使用必须严格一致。如果有些地方用了逗号加空格（, ），有些地方只用逗号（,），这个 LIKE 模式就会失效。需要清理或规范数据。
• SQL 注入: 如果 Table2.Release 的值来源于不可信的用户输入，需要确保进行适当的参数化查询或转义，以防止 SQL 注入攻击。在这个场景下，Table2 通常是内部维护的，风险较低，但保持警惕是好习惯。

进阶使用技巧:

• 如果你确定 Table1.Release 要么是单个值，要么是逗号分隔值，可以简化 WHERE 子句。但是保留两种情况的检查更具鲁棒性。
• 如果你的数据库支持正则表达式 (REGEXP 或类似函数)，也可以使用正则表达式来匹配。模式可能类似 (^|,)${T2.Release}(,|$)，表示匹配开头、逗号后的值，且值后面跟着逗号或字符串结尾。这通常比 LIKE 更灵活但也可能更复杂，性能特性也需要单独考量。例如，在 MySQL 中：

  -- 注意：需要根据具体 REGEXP 语法调整
  WHERE T1.Environment = T2.Environment
    AND T1.Release REGEXP CONCAT('(^|,)', T2.Release, '(,|$)')
  

方案二：应用程序层面处理

如果数据库端的查询性能实在无法接受，或者 SQL 方言的字符串处理能力非常有限，可以考虑将部分逻辑移到应用程序代码中。

原理与作用:

先从数据库中获取可能相关的更广泛的数据集，然后在应用程序（如 Python, Java, C#）的代码中进行精确的筛选。应用程序通常有更强大的字符串处理库。

操作步骤:

1. 在 SQL 查询中，先进行环境匹配，并可能进行一个初步的、不太精确的 Release 过滤（例如，只用 LIKE '%T2.Release%'，接受一些误报）。

   SELECT T1.Release, T1.Environment, T2.Release AS MonitoredRelease
   FROM Table1_Released_Software AS T1
   INNER JOIN Table2_Monitored_Releases AS T2
     ON T1.Environment = T2.Environment
   -- 初步过滤，可能返回比最终结果多的行
   WHERE T1.Release LIKE CONCAT('%', T2.Release, '%');
   

2. 获取查询结果到应用程序。
3. 在应用程序代码中遍历结果集。对每一行：
   • 获取 Table1.Release 字符串。
   • 将其按逗号分割成一个列表/数组。
   • 检查 MonitoredRelease 值是否精确存在于这个列表/数组中。
   • 只保留匹配成功的行。

代码示例 (伪代码 Python):

# results = execute_sql(above_query) # 假设获取了数据库结果列表
final_results = []
for row in results:
    table1_releases = row['Release']
    monitored_release = row['MonitoredRelease']
    
    # 处理 Table1.Release 可能不是列表的情况
    if ',' not in table1_releases:
        if table1_releases == monitored_release:
            # Keep only T1 columns for the final result
            final_results.append({'Release': table1_releases, 'Environment': row['Environment']})
    else:
        # Split the comma-separated string into a list
        release_list = [r.strip() for r in table1_releases.split(',')] # strip() removes potential spaces
        if monitored_release in release_list:
            # Keep only T1 columns for the final result
            final_results.append({'Release': table1_releases, 'Environment': row['Environment']})

# 去重，因为同一个 T1 行可能因为匹配 T2 中的多个 release 而被初步查询选出多次
unique_final_results = [dict(t) for t in {tuple(d.items()) for d in final_results}]

print(unique_final_results) 

安全与性能建议:

• 性能: 这种方法将计算负载从数据库转移到了应用程序。如果初步 SQL 查询返回的数据量非常大，网络传输和应用程序处理的开销可能会很高。适用于数据库字符串处理能力弱，但应用服务器资源充足的情况。
• 复杂性: 增加了应用程序的逻辑复杂度。数据处理逻辑分散在数据库和应用代码两处。
• 一致性: 需要确保应用代码中的字符串分割逻辑（如处理空格、空条目等）与数据存储格式一致。

方案三：改进数据库设计（推荐，如果可行）

这是治本的方法。当前的设计（在单列中存储逗号分隔列表）是反模式的，违反了数据库规范化原则。长远来看，最好的解决方案是重新设计表结构。

原理与作用:

遵循数据库第一范式 (1NF)，将 Table1 的 Release 列拆分，使得每一行只代表一个发布与一个环境的关联。

操作步骤:

1. 创建一个新的表，例如 Table1_Normalized，结构如下：

   Table1_Normalized

   ReleaseName	Environment	OriginalReleaseString	(可选) RowID
   release1	environment1	release1	1
   release2	production	release2	2
   release3	test	release3	3
   release4	test2	release4	4
   release5	production	release5,release6,release7	5
   release6	production	release5,release6,release7	5
   release7	production	release5,release6,release7	5
   release8	test3	release8,release9,release10	6
   release9	test3	release8,release9,release10	6
   release10	test3	release8,release9,release10	6
   release11	alpha	release11,release12,release13	7
   release12	alpha	release11,release12,release13	7
   release13	alpha	release11,release12,release13	7
   release14	beta	release14,release15,release16	8
   release15	beta	release14,release15,release16	8
   release16	beta	release14,release15,release16	8

   • ReleaseName: 存储单个发布名称。
   • Environment: 存储环境。
   • OriginalReleaseString (可选): 如果需要回溯到原始的逗号分隔字符串，可以保留它。
   • RowID (可选): 可以添加一个ID来关联回原始 Table1 的某一行，如果需要按原始行分组。

2. 将 Table1-Released-Software 的数据转换填充到这个新表 Table1_Normalized 中。这通常需要一次性的脚本来完成。

3. 之后，查询就变得非常简单直接了，只需要一个标准的 INNER JOIN：

   SELECT DISTINCT T1N.OriginalReleaseString, T1N.Environment 
   -- 使用 DISTINCT 和原始字符串，得到期望的输出格式
   -- 如果只想看匹配的单个 Release 和环境，可以 SELECT T1N.ReleaseName, T1N.Environment
   FROM Table1_Normalized AS T1N
   INNER JOIN Table2_Monitored_Releases AS T2
     ON T1N.ReleaseName = T2.Release
     AND T1N.Environment = T2.Environment;
   

   这条查询会返回：

   | OriginalReleaseString         | Environment |
   | ------------------------------- | ------------- |
   | release3                      | test        |
   | release11,release12,release13 | alpha       |
   | release14,release15,release16 | beta        |
   

   这正是我们想要的结果。

优点:

• 查询简单高效: 标准 JOIN 操作通常可以很好地利用索引，性能最佳。
• 数据完整性: 避免了因分隔符不一致、解析错误等导致的数据问题。
• 易于维护: 对单个发布的增删改查变得非常简单。
• 符合数据库设计原则: 是长期来看最健壮、最可扩展的方案。

缺点:

• 需要修改表结构: 可能涉及数据迁移，如果系统已在线上运行，改动成本较高。
• 可能需要修改相关的应用程序代码。

结论:

面对包含逗号分隔值的列进行筛选，且缺乏 FIND_IN_SET 等专用函数时：

• 使用 LIKE 配合逗号填充 (CONCAT(',', col, ',') LIKE '%,value,%') 是一个直接的 SQL 解决方法，但要注意性能和边缘情况。
• 将部分逻辑移至应用程序处理是备选方案，适用于数据库能力有限或性能瓶颈在数据库端的情况。
• 长远来看，强烈建议 重新设计数据库结构，将列表拆分成多行，实现规范化。这能从根本上解决问题，提升系统整体的性能和可维护性。

选择哪种方案取决于具体的技术限制、性能要求、以及是否有权限和资源来修改数据库模式。