本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

比較控制項

在 SQL 中，常值比較會將資料集中的資料欄與直接輸入查詢中的常值相符。資料欄比較會將來自兩個不同資料欄的值互相比對，無論是在同一資料表內或跨聯結的資料表。

預設行為

比較控制項是允許清單。設定 後allowedLiteralComparisonColumns，只能將您列出的資料欄與常值進行比較，而且您未列出的每個資料欄都會遭到封鎖。資料column-to-column比較allowedColumnComparisonColumns也同樣適用於 。將資料欄新增至一個允許清單並不會將其新增至另一個允許清單。

如果您未設定 comparisonControls， 不會 AWS Clean Rooms 套用比較限制 — 查詢可以將任何資料欄與常值或另一個資料欄進行比較。

如果您未設定 ，comparisonControls但已設定最低彙總閾值，則比較會保持不變。不過， AWS Clean Rooms 絕不允許對 中列出的資料欄進行常值比較identityColumns。該限制來自閾值本身，因此無論您是否設定比較控制項，都會套用該限制。如需詳細資訊，請參閱最小彙總閾值。

如果您將 與不允許的輸出資料欄comparisonControls一起設定，這兩個控制項是獨立的，並且兩者都適用。比較控制項控制查詢可以比較哪些資料欄；不允許的輸出資料欄控制查詢結果中可以顯示哪些資料欄。可以在比較中允許資料欄，並且仍然從結果中封鎖。如需詳細資訊，請參閱不允許的輸出資料欄。

文字比較

常值比較會根據單一硬式編碼常數 （字串、數字或日期） 評估資料欄。在查詢執行期間，運算子的右側永遠不會變更。語法範例包括：

當您使用 時最小彙總閾值， AWS Clean Rooms 不允許對 identityColumns值進行常值比較。這可防止查詢執行器將篩選後的查詢提交至個別或特定的一組使用者。避免允許對低基數資料欄進行常值比較，這些資料欄可以單獨列出小型群組或個別資料主體。

{
  "comparisonControls": {
    "allowedLiteralComparisonColumns": [
      "status",
      "price"
    ]
  }
}

範例：允許對行銷活動資料欄進行文字比較

發佈者會設定具有最低彙總閾值的自訂分析規則，以便每個輸出列代表至少 100 個不同的使用者 (user_id)。廣告商會針對此資料表執行查詢，但需要將其分析範圍限定為特定廣告行銷活動，例如測量一次一個行銷活動的觸及範圍。

由於 user_id是身分資料欄，因此無法與常值進行比較，導致廣告商無法將結果篩選為單一使用者。但 campaign_id和 event_date是高基數、無法識別的維度，因此發佈者會將它們新增至 allowedLiteralComparisonColumns，讓廣告商依行銷活動篩選，並將分析範圍限定為日期範圍：

{
  "aggregationThresholds": [
    {
      "identityColumns": ["user_id"],
      "minimumIdentityCount": 100
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": ["campaign_id", "event_date"]
  }
}

根據上述組態，允許此查詢：

-- Allowed: campaign_id and event_date are both in allowedLiteralComparisonColumns
SELECT campaign_id, COUNT(DISTINCT user_id) AS reach
FROM impressions
WHERE campaign_id = 'CMP-1024'
  AND event_date >= '2026-01-01'
GROUP BY campaign_id;

鑑於相同的組態，此查詢會遭到封鎖：

-- Blocked: user_id is the identity column and can never be compared to a literal
SELECT campaign_id, COUNT(DISTINCT user_id) AS reach
FROM impressions
WHERE user_id = 'U-88231'
GROUP BY campaign_id;

第一個查詢仍然只會傳回至少由 100 個不同使用者支援的資料列，而 上的常值比較campaign_id和event_date篩選要考慮的資料列。第二個查詢會遭到拒絕，因為它會嘗試單一化個別資料主體。

資料欄比較

資料欄比較會為每個單一資料列動態評估一個資料欄的值與另一個資料欄的值。語法範例包括：

使用 時最小彙總閾值，資料提供者可以允許對需要跨資料表聯結的使用案例identityColumns值進行資料欄比較，例如對象重疊報告。

{
  "comparisonControls": {
    "allowedColumnComparisonColumns": [
      "user_id"
    ]
  }
}

範例：允許對重疊報告的身分資料欄進行資料欄比較

發佈者和廣告商想要測量其受眾重疊 — 兩個資料集顯示多少使用者 — 而不會得知誰是任何個別使用者。這需要聯結 上的兩個資料表user_id，這是column-to-column的比較。發佈者允許廣告商執行範圍為特定行銷活動 IDs對象重疊分析。

由於 user_id是身分欄，因此發佈者已封鎖其常值比較 （因此沒有人可以篩選給特定人員）。若要啟用跨資料表的聯結，發佈者會將 user_id新增至 allowedColumnComparisonColumns。若要啟用行銷活動篩選，發佈者會campaign_id新增至 allowedLiteralComparisonColumns。

{
  "aggregationThresholds": [
    {
      "identityColumns": ["user_id"],
      "minimumIdentityCount": 100
    }
  ],
  "comparisonControls": {
    "allowedLiteralComparisonColumns": ["campaign_id"],
    "allowedColumnComparisonColumns": ["user_id"]
  }
}

根據上述組態，允許此查詢：

-- Allowed: user_id is compared against another column (column-to-column join)
SELECT COUNT(DISTINCT p.user_id) AS overlapping_users
FROM publisher_audience p
  JOIN advertiser_audience a
ON p.user_id = a.user_id;

鑑於相同的組態，此查詢會遭到封鎖：

-- Blocked: email is not in allowedColumnComparisonColumns
SELECT COUNT(DISTINCT p.user_id) AS overlapping_users
FROM publisher_audience p
  JOIN advertiser_audience a
  ON p.email = a.email;

聯結成功，因為column-to-column比較會動態評估每一列，而且不會讓查詢執行器鎖定已知值。結果會強制執行最小彙總閾值，確保只有在重疊計數代表至少 100 個不同的使用者時才會傳回。第二個查詢會遭到封鎖，因為 email 不在allowedColumnComparisonColumns允許清單中，且無法用於比較 — 只有 user_id可以。

比較控制項和表達式

比較控制項遵循間接常值比較，而不只是直接WHEREcolumn = 'literal'述詞。如果您允許透過 ANY_EXPRESSION進行內部彙總函數allowedAggregateExpressionType，比較控制項仍會封鎖不在 中的資料欄上的常值比較allowedLiteralComparisonColumns。即使常值巢狀在表達式內，這也適用。

下列範例顯示的查詢保持封鎖狀態，因為 zip_code 不在允許清單中，即使常值位於CASE表達式內，而不是寫成直接述詞：

-- Blocked: zip_code is not in allowedLiteralComparisonColumns,
-- even though the literal comparison is nested inside a CASE expression
SELECT SUM(CASE WHEN zip_code = '00001' THEN salary ELSE 0 END) AS total
FROM employees;

這就是兩個控制項互補的原因：允許彙總內的表達式會擴大查詢可以運算的內容，而比較控制項仍然會限制查詢可以依值區分的資料欄。如需詳細資訊，請參閱允許彙總函數中的巢狀運算式。