クエリではビュー A の測定を使用しているが、その測定はビュー B のフィールドを参照している可能性があります。この場合、Looker はビュー A の主キーを使用してその測定を計算します。クエリにファンアウトが含まれる場合、使用する主キーが適切でない可能性があります(ファンアウトについて詳しくは、関連するコミュニティ投稿をご覧ください。)
一時的な解決方法
この問題を解決するには、ビュー B の主キーを sql_distinct_key パラメータを使用して問題の測定に追加します。
[[["わかりやすい","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."]]