在什麼情況下SELECT可以通過PRIMARY KEY慢？

追溯相當典型的EclipseLink/JPA應用程序中的一些數據庫性能問題。在什麼情況下SELECT可以通過PRIMARY KEY慢？

我看到頻繁的查詢需要25-100ms。這些都是簡單的查詢，只需從主鍵等於某個值的表中選擇所有列即可。他們不應該慢。

我正在查看postgres日誌中的查詢時間，使用log_min_duration_statement，因此這應該消除任何網絡或應用程序開銷。

此查詢不是緩慢的，但它經常使用。

爲什麼選擇主鍵的速度會很慢？這是特定於postgres還是通用數據庫問題？我該如何加快速度？一般來說？對於postgres？從PG日誌

樣品查詢：

2010-07-28 08:19:08 PDT - LOG: duration: 61.405 ms statement: EXECUTE <unnamed> [PREPARE: SELECT coded_ele 
ment_key, code_system, code_system_label, description, label, code, concept_key, alternate_code_key FROM coded 
_element WHERE (coded_element_key = $1)]

表有大約350萬行。

我也對此查詢運行EXPLAIN和EXPLAIN ANALYZE，它只進行索引掃描。

來源

2010-07-28 Freiheit

數據集有多大？每一行有多大？查詢是什麼樣的？ – 2010-07-28 16:38:13

你有數據庫集羣嗎？發佈前您是否進行過真空全分析？什麼Pg版本？ – jmz 2010-07-28 19:08:31

沒有集羣，也不是真正的選項。我還沒有完成真空分析（我會），這是PG 8.1。 – Freiheit 2010-07-28 20:19:58

Select *使您的數據庫更難工作，而且作爲一般規則，這是一種不好的做法。有關於stackoverflow談論的問題/答案很多。

你試過用字段名替換*嗎？

來源

2010-07-28 16:44:28 dave

JPA根據字段名稱描述生成查詢。爲簡潔起見，我將其描述爲「Select *」。 – Freiheit 2010-07-28 16:54:52

啊 - 你不值得這麼做:-)還有其他一些事情可能會影響證書...壓縮表或重建索引可以提供幫助，設置索引填充比讀寫更有利於讀取，分區（是否在一個較慢的驅動器上），計算列，改變SELECT中的字段順序（爲什麼？我仍然不知道）等。 – dave 2010-07-28 17:22:42

接受的主要是後續評論，而不是最初的答案。給我一個理解和檢查的列表，以加快查詢速度。 – Freiheit 2010-08-02 14:42:16

你可能會得到某種鎖定爭用？執行這些查詢時，你正在使用什麼類型的鎖？

來源

2010-07-28 16:41:50 djna

我不確定。有沒有辦法讓PG或JPA告訴我何時發出鎖？ – Freiheit 2010-07-28 16:55:25

那麼，我不太瞭解postgres SQL，所以我會給你一個適用於MS SQL Server的技巧。

MS SQL Server具有「羣集索引」的概念，該羣集索引是磁盤上數據的物理佈局。在你要尋找值之間的範圍（主要是日期字段）的領域使用它是很好的。如果你正在尋找一個確切的值（比如主鍵查找），這沒什麼用處。但是，有時主鍵索引被無意設置爲聚簇索引。這使索引查找到表掃描。

來源

2010-07-28 16:42:41

如何使用主鍵的聚集索引將主鍵上的索引查找轉化爲表掃描？ – 2010-07-28 21:16:35

因爲表是索引。因此「索引掃描」==「表掃描」 – 2010-07-28 23:15:56

但是索引查找不會成爲索引掃描，除非我把我的術語搞砸了。 – 2010-08-03 19:20:47

select *幾乎總是一個非常非常糟糕的主意。

~~如果字段的順序發生變化，它會破壞你的代碼。~~ 根據評論，這並不重要，因爲你正在使用的抽象庫。
您可能從表中返回的數據比實際需要的數量多。選擇您想要的特定字段可以節省傳輸時間。

25ms是幾乎任何類型的SQL查詢都會看到的下限 - 只有兩個磁盤訪問！您可能想要考慮減少查詢運行次數的方法，而不是嘗試優化查詢。

來源

2010-07-28 16:45:03

我真的希望人們會在他們倒退時嚇倒評論！ – 2010-07-28 17:56:34

@比利，你在兩個賬戶中是錯誤的：1.除非你刪除表格，否則字段順序不會改變。 25ms對於PK來說是非常長的時間。然而，這不是倒退的原因。你沒有回答這個問題，那就是如何解決這個問題，而不是你在25ms內獲得多少次隨機磁盤訪問。 – jmz 2010-07-28 19:06:07

@jmz：ALTER也可以更改字段順序。至於這個問題，我相信這是'爲什麼主鍵選擇慢*'，接着是'我怎樣才能加快速度？'，在這種情況下，我看不出這怎麼回答這個問題。 – 2010-07-29 02:35:16

該行異常大或包含BLOB和大二進制字段？

這是直接通過控制檯還是這個查詢通過一些數據訪問API，如jdbc或ADO.NET運行？您提到JPA看起來像數據訪問API。對於短的查詢，數據訪問API會佔用更大的執行時間 - 創建命令，創建對象來保存行和單元格等。

來源

2010-07-28 17:17:15 MatthewMartin

這些查詢速度是從postgres日誌中記錄的，所以它是實際的查詢時間，而不是數據API（JPA）時間。 – Freiheit 2010-07-28 17:25:37

在什麼情況下SELECT可以通過PRIMARY KEY慢？

回答

相關問題