이 오류의 가장 일반적인 원인은 쿼리에 고유하지 않은 기본 키가 포함되어 있기 때문입니다. 측정기준에서 primary_key: yes를 사용하여 기본 키를 지정합니다. 이는 반복되는 값이 없는 측정기준이어야 합니다.
빠른 해결 방법
쿼리에서 기본 키 측정기준을 식별하면 다음 쿼리로 Looker의 SQL Runner에서 고유성을 테스트할 수 있습니다.
SELECT
COUNT(*),
COUNT(DISTINCT your_primary_key)
FROM
your_table_name
이 쿼리의 개수가 일치하는 경우 기본 키가 고유합니다. 개수가 일치하지 않는 경우 기본 키가 고유하지 않으며 여러 행에 표시됩니다. 새 측정기준을 기본 키로 선택하거나 만들어야 합니다. 완전히 고유한 값이 포함된 단일 측정기준이 없는 경우 자체 기본 키 측정기준을 만들기 위해 필드를 연결해야 할 수도 있습니다.
row_number를 사용하여 파생 테이블의 기본 키 생성
파생 테이블에서 이 오류가 발생하면 Postgres 및 Redshift 데이터베이스의 row_number() 윈도우 함수를 사용하여 고유한 필드를 만들 수 있습니다. 이 필드를 기본 키로 사용할 수 있습니다.
view: derived_table_name {
derived_table {
sql:
SELECT
row_number() OVER(ORDER BY created_at) AS prim_key,
*
FROM orders ;;
}
dimension: prim_key {
type: number
primary_key: yes
sql: ${TABLE}.prim_key ;;
}
}
MySQL에서는 모든 행을 반복하는 변수를 사용하여 동일한 효과를 얻을 수 있습니다.
view: derived_table_name {
derived_table {
sql:
SELECT
CAST(@rownum := @rownum + 1 AS UNSIGNED) AS prim_key, t.*
FROM orders t,
(SELECT @rownum := 0) r ;;
}
dimension: prim_key {
type: number
primary_key: yes
sql: ${TABLE}.prim_key ;;
}
}
sql_distinct_key의 잘못된 사용
쿼리의 측정값 중 하나라도 sum_distinct 유형이면 해당 측정값의 sql_distinct_key 매개변수와 sql 매개변수 사이에 고유성 불일치가 있을 수 있습니다.
쿼리는 뷰 A의 측정값을 사용할 수 있지만 측정값은 뷰 B의 필드를 참조합니다. 이 경우 Looker는 뷰 A의 기본 키를 사용하여 해당 측정값을 계산합니다. 쿼리에 팬아웃이 포함된 경우 올바른 기본 키를 사용하지 못할 수 있습니다. (팬아웃에 대해 자세히 알아보려면 관련 커뮤니티 게시물을 확인하세요.)
빠른 해결 방법
이 문제를 해결하려면 sql_distinct_key 매개변수를 사용하여 뷰 B의 기본 키를 문제 측정값에 추가하세요.
나열된 원인 중 해당되는 사항이 없는데 오류가 계속 발생하는 경우
기본 키가 고유할 수 있는 매우 구체적인 상황이 있으며 이 문제의 다른 원인은 쿼리에 적용되지 않지만 이 오류는 계속 발생합니다. 첫째, 쿼리에 relationship: one_to_many의 여러 조인이 포함되어 있습니다. 둘째, 쿼리의 측정값 중 하나가 여러 조인된 뷰의 값을 결합하는 측정기준을 참조합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-31(UTC)"],[],[],null,["# Error: Non-Unique value/primary key (or sql_distinct_key), value overflow or collision when computing sum\n\nThis page will help you troubleshoot this Looker error: \n\n Non-unique value/primary key (or sql_distinct_key), value overflow or collision when computing sum\n\n\nOne of several issues can cause this error:\n\n- [A non-unique primary key (most common)](#non_unique_primary_key)\n- [Incorrect usage of `sql_distinct_key`](#incorrect_usage_of_sql_distinct_key)\n- [Referencing a field across views when fanouts are involved](#referencing_fields_across_views_with_fanouts)\n\nNon-unique primary key\n----------------------\n\n\nThe most common cause of this error is that your query involves a non-unique primary key. You specify a primary key by using `primary_key: yes` on a dimension, and it must be a dimension without any repeated values.\n\n### Quick fix\n\n\nOnce you identify the primary key dimensions in your query, you can test them for uniqueness in Looker's [SQL Runner](/looker/docs/sql-runner-basics) with this query: \n\n```\nSELECT\n COUNT(*),\n COUNT(DISTINCT your_primary_key)\nFROM\n your_table_name\n```\n\n\nIf the counts in this query match, the primary key is unique. If the counts do *not* match, the primary key is not unique and appears in multiple rows. You will need to choose or create a new dimension as your primary key. If no single dimension contains entirely unique values, you may need to concatenate fields to [create your own primary key dimension](/looker/docs/reference/param-field-primary-key#compound_primary_key).\n\n### Using `row_number` to generate a primary key for a derived table\n\n\nIf you receive this error with a [derived table](/looker/docs/derived-tables), you can use the `row_number()` window function in Postgres and Redshift databases to make a unique field. This field can then be used as a primary key: \n\n```\n view: derived_table_name {\n derived_table {\n sql:\n SELECT\n row_number() OVER(ORDER BY created_at) AS prim_key,\n *\n FROM orders ;;\n }\n\n dimension: prim_key {\n type: number\n primary_key: yes\n sql: ${TABLE}.prim_key ;;\n }\n }\n \n```\n\n\nIn MySQL, you can use a variable that iterates every row to achieve the same effect: \n\n```\n view: derived_table_name {\n derived_table {\n sql:\n SELECT\n CAST(@rownum := @rownum + 1 AS UNSIGNED) AS prim_key, t.*\n FROM orders t,\n (SELECT @rownum := 0) r ;;\n }\n\n dimension: prim_key {\n type: number\n primary_key: yes\n sql: ${TABLE}.prim_key ;;\n }\n }\n \n```\n\nIncorrect usage of `sql_distinct_key`\n-------------------------------------\n\n\nIf any of the measures in your query are of the type `sum_distinct`, there may be a uniqueness mismatch between the `sql_distinct_key` and `sql` parameters of that measure.\n\n### Quick fix\n\n\nCheck out our [`sum_distinct` documentation page](/looker/docs/reference/param-measure-types#sum_distinct) for these parameters' requirements.\n\nReferencing fields across views with fanouts\n--------------------------------------------\n\n\nYour query may use a measure from view A, but the measure references a field from view B. In this situation Looker will use the primary key from view A to calculate that measure. If your query involves a fanout, that may not be the correct primary key to use. (To become familiar with fanouts, check out our [related Community post](https://www.googlecloudcommunity.com/gc/Technical-Tips-Tricks/Aggregate-functions-gone-bad-and-the-joins-who-made-them-that/ta-p/588767).)\n\n### Quick fix\n\n\nTo resolve this problem, add the primary key from view B to the problem measure with the `sql_distinct_key` parameter.\n\nWhat if none of the listed causes apply, but the error still occurs?\n--------------------------------------------------------------------\n\n\nThere is a very specific situation in which your primary key can be unique, and the other causes of this problem don't apply to your query but this error still occurs. First, your query will involve multiple joins of `relationship: one_to_many`. Second, one of the measures in your query will reference a dimension that combines values from multiple joined views.\n\n\nTo fix this problem, make a note of that measure, and then follow these steps:\n\n1. Find the dimension within the measure that combines values from multiple joined views.\n2. Find the views that are referenced by that dimension.\n3. Concatenate the primary keys from those views using your SQL dialect's concatenation function.\n4. Place that concatenated key into a `sql_distinct_key` parameter on the measure that caused the problem."]]