[[["わかりやすい","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,["# Why are there nulls in my secondary merged results query?\n\n[Merged Results](/looker/docs/merged-results) is a convenient feature for combining data from different Explores quickly and without developing in LookML. Merged results effectively perform a left join\nbetween the primary query and secondary queries --- meaning that field names, matching\nvalues, and the ending results table are dependent upon how data from the secondary\nqueries match to the primary.\n\n\nThis can potentially cause unexpected results when you are performing merges between Explores. The merged results documentation addresses a few of these conditions,such as:\n\n- When [one query doesn't have a matching data value](/looker/docs/merged-results#what_if_one_query_doesnt_have_a_matching_data_value)\n- When [one query has multiple rows for the same value](/looker/docs/merged-results#what_if_one_query_has_multiple_rows_for_the_same_value)\n\n\u003cbr /\u003e\n\n\nHowever, what do you do when you expect a value from a secondary query to match a value in the primary query, but the end result displays null values?\n\n\nThis page addresses how to troubleshoot this unexpected result.\n\nExample use case\n----------------\n\n\nThe following example use case is based on a sample e-commerce dataset that contains user and order information. For this example, you want to merge one query --- a count of users per city (**Users Count** grouped by **Users City** ) --- with a secondary query --- a count of orders (**Orders Count** ) grouped by **Users City** and **Users State**:\n\n\n**Primary query**\n\n\nThe primary query is **Users Count** grouped by **Users City**:\n\n\n**Secondary query**\n\n\nThe secondary query is **Orders Count** grouped by **Users City** and **Users State**:\n\n\nThe merge rule is set to merge both queries by **Users City**, the field both queries have in common. Given familiarity with the dataset and expected merged results behavior explained by the documentation linked previously, you know thatin each row, every city should be matched with a state and a count of users. You are expecting that your merged results will match all values and display no null values.\n\n\nHowever, there *are* nulls in the results. Over half of the cities are not matched with a state or a count of orders:\n\n\nSolutions\n---------\n\n\n**Don't panic.** If you are certain there are matching values in your data (try running a separate query to confirm that this is the case), there are several possible solutions to remedy this outcome, including:\n\n- Sort each source query the same way.\n- Increase the source query row limit.\n\n\u003cbr /\u003e\n\n### Sort each source query the same way\n\n\nBecause merged results are based on Explores, which are [limited](/looker/docs/best-practices/row-limits-in-looker) to 500 rows by default, sometimes the query results you are merging are not included in the final result.\n\n\nTo fix this, you can [edit](/looker/docs/merged-results#editing_the_source_queries) and [sort](/looker/docs/creating-and-editing-explores#sorting_data) your individual source queries to better match each other.\n\n\nIn the example use case, the primary query is sorted by **Users City** ascending. The secondary query is not. To better match the results of the two queries, you can **sort** the secondary query the same way as the primary query --- in this case, by **Users City** ascending.\n\n\nSorting the secondary query similarly to the primary query matches the results more accurately in the final merge:\n\n\n### Increase the source query row limit\n\n\nSimilarly to the first solution outlined previously, unexpected nulls can be caused by the [row limits](/looker/docs/filtering-and-limiting#row_limits) set in the source queries. Specifically in this case, the secondary query (limited by the 500 row default) does not have enough rows to match all of the rows generated by primary query, causing null results to be displayed in the final merge.\n\n\nTo increase the number of rows in the secondary query to match the primary query, you can increase the secondary query row limit. This results in more possible rows to match to the primary query and fewer null values in the secondary query columns:\n\n\nSummary\n-------\n\n\nWhen faced with unexpected merged results, you can take the following steps to troubleshoot:\n\n1. Select the [**Clear Cache and Refresh**](/looker/docs/caching-and-datagroups#forcing_new_results_to_be_generated_from_the_database) option from the Explore's gear menu to ensure the query is pulling the most up-to-date results.\n2. Confirm that there are matching values between source queries where nulls are displayed, as outlined in the [What if one query doesn't have a matching data value?](/looker/docs/merged-results#what_if_one_query_doesnt_have_a_matching_data_value) section of the Merged Results documentation.\n3. Sort the source queries to better match each other.\n4. Increase the row limit of source queries beyond the default to expose more rows that can be matched and merged.\n5. If none of the solutions discussed here resolves the behavior, hardcode the [join](/looker/docs/reference/param-explore-join) logic into LookML for a more precise result, if possible."]]
