使用组合合成主键替代多字段关联是否存在性能损耗？

场景说明 #

现有两张业务表：

winners表 #

points表 #

原本通过多字段关联获取数据的SQL：

SELECT
    W.PLAYER
  , W.TEAM
  , P.POINTS
FROM WINNERS W
INNER JOIN POINTS P
    ON W.PLAYER = P.PLAYER AND W.TEAM = P.TEAM

为简化SQL写法，考虑用CTE生成合成主键的方式替代多字段关联：

WITH WINNERS_NEW AS (SELECT
                         PLAYER || '_' || TEAM AS ID
                       , PLAYER
                       , TEAM
                     )
   , POINTS_NEW AS (SELECT PLAYER || '_' || TEAM AS ID, 
                           POINTS
                    )
SELECT
    WN.PLAYER
  , WN.TEAM
  , PN.POINTS
FROM WINNERS_NEW WN
INNER JOIN POINTS_NEW PN
    ON WN.ID = PN.ID;

实际业务中需要关联7个以上字段，想通过这种合成主键方式简化SQL，但不确定是否会带来显著性能损耗，特此咨询。

性能影响分析 #

• 拼接计算开销：每次执行都要对7个字段做字符串拼接，数据量较大时，CPU消耗会明显增加；如果涉及不同数据类型（比如数字、日期）的字段，还要先做类型转换，进一步提升开销。
• 索引失效风险：原多字段关联可通过联合索引（如winners表上的(Player, Team, ...)联合索引）快速定位匹配行，但合成的ID是计算字段，除非专门为该计算字段创建函数索引，否则关联时只能做全表/全索引扫描，性能会大幅下降。
• 哈希冲突隐患：不同的字段组合可能拼接出相同的ID（比如A+B_C 和 A_B+C 拼接后均为A_B_C），导致关联结果错误，这是比性能问题更严重的功能性故障。
• 优化器适配限制：多数数据库优化器对计算字段的处理效率远低于原生字段，可能无法生成最优执行计划（比如无法使用嵌套循环关联，只能用哈希/合并关联），数据量越大，性能差距越明显。

替代方案 #

• 保留原生多字段关联：虽然SQL语句较长，但数据库对联合关联的优化更成熟，配合合适的联合索引，性能会更稳定。
• 持久化合成主键：如果业务允许，在表中新增ID字段，通过触发器或ETL流程提前计算并存储拼接后的主键，同时给该字段建索引。这种方式既简化SQL，又能保证查询性能，但会增加存储和数据维护的开销。
• 使用数据库原生组合键函数：部分数据库支持原生组合键处理函数（如PostgreSQL的ROW()、MySQL的CONCAT_WS()），这类函数的性能优于手动字符串拼接，还能降低哈希冲突概率，但仍需配合函数索引使用。

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