Postgresql
比較跨 DBMS 的查詢性能
我有一個查詢列表，我想比較 3 個不同 DBMS 的執行時間：SQLite、MariaDB 和 postgreSQL。
我一直在研究每個系統的命令行工具以獲取查詢執行時間。
- 對於 SQLite，我使用 .timer ON 命令在每次查詢後顯示真實/使用者/系統時間
- 對於 MariaDB，我設置了分析並呼叫“顯示分析”來獲取每個查詢的持續時間
- 對於 PostgreSQL，我使用“analyze”執行查詢以顯示完整的查詢計劃，包括執行時間。
我的問題是我無法找到這些工具的文件來指定實際時間：CPU 與實際時間等，其中一些值非常不同。例如，我使用 MariaDB 嘗試的連接查詢需要 33 分鐘，但使用 postgreSQL 只需要幾秒鐘。
有沒有人了解這些指標實際上是如何衡量查詢時間的，以及它們是否可以準確地相互比較？或者，我應該使用更好的工具來完成這項任務嗎？任何幫助表示讚賞。
我認為你不應該依賴任何一個。唯一真正的衡量標準是從客戶端測量查詢實際花費了多長時間。如果您
EXPLAIN (ANALYZE)在 PostgreSQL 中使用，這也避免了您在查詢執行期間獲得的成本。所以我會這樣做：
- 在客戶端測量目前時間
- 向伺服器發送查詢
- 等到執行完成並且客戶端得到結果
- 再次測量時間併計算差異
對於 MariaDB/MySQL，PROFILE 幾乎是工具所能得到的無用的。幾乎總是，幾乎所有的時間都集中在一個條目中，例如“發送數據”，即使這是用詞不當。
查詢記憶體應該關閉，否則你會得到虛假的結果。
一個“冷”系統，然後是一次查詢，會導致幾乎無用的計時。第一次執行可能比第二次執行慢 10 倍——僅僅是因為記憶體了磁碟塊。
mysqlslap 和一些 percona 工具擅長一次又一次地執行相同的查詢，可以選擇從單獨的連接中執行。（在我看來，這也不是很有用。）
至於比較產品，以下可能會使事情複雜化：
- 一般來說，每個產品都會以同樣快的速度執行簡單的查詢。這是因為所有簡單的東西都已經過優化。被大家。
- 多個 CPU 和並行性如何——無論是在連接之間還是在單個連接內。MySQL在單個連接中基本上沒有並行性；它在連接之間確實具有良好的並行性。如果你的基準測試只測試一個執行緒，MySQL 將處於劣勢。但是如果您的應用程序是單執行緒的，那麼這是需要注意的一點。
- HDD vs SSD——SSD速度更快，因此可以隱藏產品的一些低效率。
- 設置——糟糕的設置會導致比經過良好調整的產品更多的 I/O。I/O，尤其是大表和 HDD，是查詢時間的主要組成部分。
- 網路延遲——如果您使用的是雲，那麼每個查詢會引入幾毫秒；對於簡單的查詢，這是“總”時間的大部分（正如 Laurenz 所討論的）。這可以通過擁有多個執行緒來緩解。但哪個更重要？ 延遲（一個查詢完成的速度）或吞吐量（多個執行緒每秒可以執行多少次查詢）。
- 性能懸崖。如果你有“太多”的連接爭奪資源，舊版本的 MySQL 將會失敗。在吞吐量停滯和延遲達到頂峰之前，目前版本可以達到大約 100 - 所有這些都是由於必須共享 cpus/IO/網路。 很少有生產系統同時擁有 100 個活動執行緒，即使它們每秒執行數千個查詢！
- 最好的基準是從實時系統中獲取查詢的轉儲，然後根據轉儲開始時拍攝的數據庫快照盡可能快地重放它們。