我的應用程序使用JPA和Hibernate，我發現hibernate在我的日誌文件中生成了一些有趣的SQL查詢，並且有很多連接。該應用程序現在沒有很多用戶，我擔心一些由hibernate生成的查詢會在數據庫規模增大時導致問題。SQL查詢解釋的結果是否取決於數據庫的大小？
我已經通過EXPLAIN命令運行一些由休眠生成的sql查詢來查看生成的查詢計劃。
EXPLAIN的輸出是否依賴於數據庫的大小？當我的數據庫大小增長時，查詢規劃器會爲相同的SQL查詢生成不同的計劃？
在開發/部署週期中的什麼時候我應該查看由休眠生成的SQL查詢的SQL查詢計劃？什麼時候適合使用EXPLAIN？
如何解釋的輸出用於確定查詢是否會成爲問題，當數據庫非常小以至於每個查詢無論在0.5秒內運行多麼複雜？
我使用Postgres 9.1作爲我的應用程序的數據庫，但我對上述問題的一般答案感興趣。
1是EXPLAIN的輸出依賴於數據庫的大小？當我的數據庫規模增大時，查詢規劃器會爲相同的SQL查詢生成不同的計劃嗎？
這一切都取決於你的數據和有關數據的統計信息。出現許多性能問題的原因是缺少統計信息，有時忘記ANALYZE或關閉auto_vacuum（包括分析）。
2在開發/部署週期的什麼時候我應該查看由hibernate生成的SQL查詢的SQL查詢計劃？ 什麼時候適合使用EXPLAIN。
Hibernate有一個發送大量查詢到數據庫的習慣，即使是簡單的連接。打開你的querylog，並密切關注那一個。稍後，您可以對日誌中的所有查詢運行自動解釋。
3怎麼能輸出講解來確定是否查詢將成爲一個問題，當數據庫是如此之小，每個查詢 無論看多麼複雜的運行在不到0.5秒了嗎？
沒有，因爲這一切都取決於數據。當95％的用戶是男性時，搜索男性時不會使用性別指數。當你在尋找一個女人時，這個指數是有意義的，並且會被使用。性別=女性記錄的功能指數甚至更好：索引永遠不會從索引獲益並且索引將小得多的索引是無用的。
預測索引使用情況的唯一方法是使用set enable_seqscan = off;進行測試，這將顯示可以使用某種索引，但僅此而已。
s /功能指數/部分指數/ g？ –
弗蘭克像往常一樣死了，而且@ams認爲並非所有查詢都受益於或應該使用索引。如果你沒有任何過濾器加入兩個中小型表，seqscan和mergejoin可能只是最好的計劃。 –
當然，如果語句在服務器端*準備好*，它必須使用* generic *計劃，而不是基於每次運行使用的參數的計劃;所以你可能在描述的性別示例優化時遇到麻煩。請參閱PostgreSQL JDBC驅動程序的'prepareThreshold'選項。 – kgrittn
實際上，@ams您在評論中是正確的 - 對少量數據使用解釋通常是毫無意義的。
如果一張表只有10行，那麼它很可能在一個頁面中全部被讀取，並且與讀取一行的成本相當（大致）相同。首先訪問索引然後獲取頁面將比只是讀了很多東西，而忽略了你不想要的東西。 PostgreSQL的計劃器有configured costs用於索引讀取，表讀取，磁盤訪問與高速緩存訪問，排序等事情。它根據表的（近似）大小以及它們中的distribution of values來確定它們的大小。它沒有做什麼（截至9.2版本）是交叉列或交叉表相關性的考慮因素。它也不提供手動提示，讓您覆蓋計劃者的選擇（與MS-SQL或Oracle不同）。
每個RDBMS的規劃師都有不同的優缺點，但我認爲可以公平地說MySQL是最弱的（特別是在舊版本中）。
所以 - 如果您想知道您的系統將如何執行100個併發用戶和數十億行，您需要生成測試數據並加載相當大的一部分。更糟糕的是，你會希望有大致相同的值分佈。如果大多數客戶有大約10張發票，但少數客戶有1000張，那麼這就是測試數據需要反映的東西。如果您需要維護多個RDBMS的性能，那麼在所有這些測試中重複測試。
這與系統的整體性能完全不同，當然這取決於服務器的大小和功能以及所需的負載。系統可以在負荷穩步上升應付，然後突然你會看到快速的緩存大小都超過了性能下降等
HTH
智能數據庫使用* statistics *來幫助對如何創建計劃進行有根據的猜測。這些*統計*可能會隨着新數據的變化而變化。確切的範圍，收集，提示等都是非常特定於數據庫的。但是，這很可能不是現在需要擔心的事情:)只要專心創建一個乾淨的模型。 – 2012-09-07 07:35:56
@pst所以這意味着當數據庫仍然很小時，它是無意義的解釋。 – ams
請注意，對於PostgreSQL版本比即將發佈的9.2更早版本，您應該'PREPARE'語句然後'EXPLAIN EXECUTE'它匹配Hibernate將如何執行您的語句。準備和未準備的報表中的查詢計劃在9.1和更低版本中可能有所不同。 –