Power BI 使用者能快速收集資料並產生有趣且強大的報告，從而做出智慧的商業決策，這種簡單與易用性也讓使用者能輕鬆產生表現不佳的查詢。 這種情況通常發生在兩個資料表之間，且其關聯方式類似外鍵與 SQL 資料表或 SharePoint 清單的關聯。 （順帶一提，這個問題並非 SQL 或 SharePoint 特有，且在許多後端資料擷取情境中都會發生，尤其是結構流動性高且可自訂的環境。）將資料存放在共享相同鍵的獨立資料表中本身並無問題——事實上，這是資料庫設計與正規化的基本原則。 但這確實暗示了一種更好的方式來擴展關係。
請考慮以下 SharePoint 客戶名單的範例。
以及它指涉的以下地點清單。
當首次連接到清單時，該地點會以紀錄形式顯示。
這些頂層資料是透過對 SharePoint API 的單一 HTTP 呼叫收集（忽略元資料呼叫），你可以在任何網頁除錯器中看到。
展開紀錄時，你會看到從次要資料表連接的欄位。
當將相關資料列從一個資料表展開到另一個時，Power BI 的預設行為是產生對 Table.ExpandTableColumn 的呼叫。 你可以在生成的公式欄位看到這點。 不幸的是，此方法會為第一表的每一列產生對第二個資料表的個別呼叫。
這會使主清單中每一列的 HTTP 呼叫次數增加一次。 這在上述五、六列的例子中看似不多，但在生產系統中，SharePoint 清單數量達數十萬列，這可能導致顯著的體驗下降。
當查詢進入此瓶頸時，最佳的緩解方法是使用經典的表格連接，避免逐行呼叫的行為。 這確保只有一次呼叫來取得第二個資料表，其餘擴充則可透過兩表間的共用金鑰在記憶體中完成。 在某些情況下，效能差異可能非常大。
首先，從原始表格開始，標註你想展開的欄位，並確保你有該項目的 ID，這樣你才能匹配。 通常外鍵的命名與欄位顯示名稱相似，並加上 Id 。 在這個例子中，是 LocationId。
第二，載入次要資料表，確保包含 Id，也就是外鍵。 在查詢面板上點右鍵以建立新的查詢。
最後，使用相符欄位名稱將兩個資料表連接起來。 通常你可以先展開欄位，再在預覽中尋找匹配欄位來找到這個欄位。
在這個例子中，你可以看到主清單中的 LocationID 與次要清單中的 ID 相符。 介面會將此欄位重新命名為 Location.Id ，使欄位名稱獨一無二。 現在讓我們用這些資訊來合併這些表格。
在查詢面板上點右鍵，選擇「 新查詢>合併>合併查詢為新」，你會看到一個友善的使用者介面，幫助你合併這兩個查詢。
從下拉選單中選擇每個表格，即可預覽查詢內容。
選中兩個資料表後，選擇邏輯上連接它們的欄位（在此範例中，主資料表的 LocationId ，次要資料表的 Id ）。 對話框會告知有多少行與該外鍵匹配。 你可能會想用預設的 join 類型（左外側）來處理這類資料。
選擇 確定 ，你會看到一個新的查詢，這是 join 的結果。 現在擴充紀錄並不代表需要額外呼叫後端。
當刷新這些資料時，SharePoint只會進行兩次呼叫——一次是對主要清單的呼叫，另一次是對次要清單的呼叫。 連接會在記憶體中執行，大幅減少呼叫 SharePoint 的次數。
此方法可用於 PowerQuery 中任意兩個具有匹配外鍵的資料表。
備註
SharePoint 使用者清單與分類法也可以表格形式存取，且只要使用者擁有足夠的權限存取這些清單，即可以上述方式加入。