數據庫查詢和插入速度取決於什麼？

Question

在我的工作中，我們有一個小型數據庫（如在兩百張表中，可能總共有一百萬行左右）。

我一直認爲它的速度相當快，每秒插入數十萬次，連接建立後查詢需要幾毫秒。

恰恰相反，我們遇到了一些性能問題，以至於我們每秒只能得到幾百次插入和查詢，即使是最簡單的插入也要花費很長時間。

我不確定這是標準行爲/表現還是我們做錯了。例如，1500個查詢意味着在單個鍵列上連接4個表需要大約10秒。使用簡單的插入將數據以xml格式載入數據庫需要3分鐘的時間，而不會違反任何約束條件。

該數據庫是SQL Server 2005，具有豐富的關係依賴關係模型，這意味着數據上的很多關係和分類以及分類代碼和其他一些檢查約束的全套集合。

這些時間是正確的嗎？如果不是，可能會影響性能？ （所有查詢均在索引列上完成）

Answer 1

要進行粗略比較：TPC-C benchmark record for SQL Server每分鐘大約爲1.2密爾交易，在過去4年左右一直如此（受64 CPU操作系統限制）。這是在〜16k交易每秒的balpark中的事情。這是超高端機器，64個CPU，大量的RAM，每個NUMA節點的關聯客戶端以及一個服務器級別較短的I/O系統（僅佔每個主軸的1-2％左右）。記住這些是TPC-C事務，所以它們包含幾個操作（我認爲是4-5次讀取，平均1-2次寫入）。

現在您應該將這個頂級硬件配置降低到您的實際部署範圍，並且將獲得大型OLTP事務處理的預期設置。

對於數據上傳當前world record is about 1TB in 30 minutes（如果仍然是最新的...）。每秒數以萬計的插入是相當雄心勃勃的，但如果在嚴格的硬件上正確完成，就可以實現。鏈接中的文章包含ETL高吞吐量的提示和技巧（例如，使用多個上傳流並將它們關聯到NUMA節點）。

對於你的情況我建議首先措施所以你找出瓶頸，然後問具體問題如何解決具體botlenecks。一個好的起點是Waits and Queues whitepaper。

Answer 2

「富關係相關性」模型不利於快速插入速度。必須爲每個插入的記錄檢查每個約束（主鍵，值檢查，特別是外鍵）。這比「簡單的插入」要多得多。

而且它並不是說你的插入沒有違反約束條件，這個時間可能會全部用來檢查你的外鍵。除非你也有觸發器，因爲它們更糟糕。

當然，唯一可能的錯誤是你的插入表是父子FK必須有孩子「FK關係的另一個表忘記爲子FK添加一個索引（這不是自動的，經常被人遺忘）當然，這只是希望能夠幸運。:-)

Answer 3

索引是一個主要因素，如果正確完成，他們可以加快Select語句不過請記住索引會導致插入錯誤，服務器不僅會更新數據，而且還會更新索引。這裏的技巧是：

1）確定真正關鍵的查詢，這些查詢守ld對它們有最佳指標。

2）填充因子在這裏也很重要。這爲索引頁面提供了空的空間供稍後填寫。當索引頁面已滿（插入了足夠的行）時，需要花費更多時間創建新頁面。但空白頁佔用磁盤空間。

我的絕招是這樣的，因爲我設置優先級如下每個應用程序：

1）讀取速度（SELECT，在一些更新，有些DELETE） - 此優先級越高，更多的索引創建
2寫的）速度（INSERT，一些更新，有些DELETE） - 較高的這個優先級，越少的索引創建
3）磁盤空間效率 - 高此優先級越高我的填充因子

注意這方面的知識一般適用於SQL Server，您的里程可能因不同的DBMS而異。

SQL語句評估也可以在這裏幫助，但這需要一個真正的專業人士，小心WHERE和JOIN分析可以幫助確定瓶頸和您的查詢遭受的地方。打開SHOWPLAN並查詢計劃，評估您看到的內容並相應地進行計劃。

另外看看SQL Server 2008，索引加入！

Answer 4

約束增加了一個小的性能損失。它還必須更新每個插入索引。如果您不將多個插入操作放入單個事務中，那麼數據庫服務器必須將每個插入操作作爲新的單獨事務執行，從而進一步減慢插入操作的速度。

150個查詢/秒加入4個表格聽起來很正常，但我對你的數據瞭解不多。

Answer 5

「我一直認爲它的速度非常快，每秒插入數十萬次，查詢一旦連接建立就花費毫秒。」 （a）數據庫性能取決於物理I/O數量的99％（除非您在某個使用內存數據庫的小型站點中，這可以無害地承擔延遲所有物理I/O直到一天完成）。 （b）數據庫I/O不僅涉及數據文件的實際物理I/O，而且還涉及持久存儲日誌/日誌/ ...的物理I/O（並且日誌通常甚至以雙模式即兩次），因爲說大約二十年左右）。 （c）「插入量」與「物理I/O量」對應的方式完全取決於數據庫設計人員可用於優化物理設計的多少選項。一般來說，只有一件事可以說：SQL系統大多失敗（提供將「成千上萬個插入」轉換成僅僅幾百個物理I/O所需的選項）。意思是「成千上萬的插入」通常也意味着「成千上萬的物理I/O」，這通常意味着「幾十秒」。這就是說，你的消息似乎表達了一種期望，即某種程度上「插入速度非常快」（「每秒數萬」），而「查詢速度較慢」（「每個查詢的毫秒數」，意味着「少於1000條查詢每秒」）。這種期望是荒謬的。