我目前有一個數據庫，有很多很多關聯。我有許多變化的服務，有許多工作人員誰可以執行的變化，然後有他們自己的細節如名稱，角色等...許多協會導致查詢緩慢
在10服務3變化各20人中最多4附加到每個服務甚至做一些事情，因爲獲得所有變化和與他們相關的工作人員需要4s。
有沒有辦法減少這些需要一段時間才能處理的查詢？我通過在DBM中進行急切的加載來減少查詢，以減少1 + N問題帶來的問題，但仍然只是一個測試階段的長時間查詢。
是否有一個結構可以幫助使這種嵌套的多對多關聯更快地選擇？
也許將過去服務級別的所有內容合併到一個帶'TYPE'列的單個表中？我只是不知道足夠的知道解決方案，將這個4S查詢變成300MS查詢...任何建議都會有所幫助。
表格模式將很高興看到這個問題。就一般的MySQL性能而言，確保您研究磁盤對齊，設置適當的塊大小，並針對此特定問題檢查執行計劃並評估添加索引。
答：可能重構數據以提高查詢效率。這通常意味着冗餘（重複值）的折衷，這會使插入/更新/刪除算法過於複雜。
沒有看到架構以及正在運行的查詢（查詢？），無法診斷問題。
我認爲最可能的解釋是，MySQL沒有合適的索引可用來有效地滿足正在運行的查詢（查詢？）。運行EXPLAIN query對於顯示訪問路徑非常有用，並提供合適的索引是否可用，是否正在考慮索引，是否統計數據是最新的等等。
但是，您還提到了「N + 1「的性能問題和」急切加載「，這使我相信你可能會使用ORM（比如ADO Entity Framework，Hibernate等）。這些是性能問題的臭名昭着的來源，發佈大量SQL語句（N + 1），或者做一個單獨的查詢，它連接了幾條不同的路徑，這些查詢產生了一個龐大的結果集，查詢本質上是在進行半交叉連接。
爲了真正診斷性能問題，您確實需要發佈實際的SQL語句，並且在開發環境中，啓用MySQL通用日誌將捕獲正在發佈的SQL以及基本時序。
我建議你添加你當前正在使用的數據庫表模式。 – Sparky
請添加您的數據庫架構，一些示例數據和您正在使用的查詢。製作一個小平臺也是有幫助的。 – Barmar