排序數據庫的時間複雜性

Question

我目前正在開發一個移動應用程序並使用Codeigniter MySQL。我現在面臨的情況是，我有一張桌子的書（這張桌子將有100K +的記錄）。在這張表中我有一個名爲NotSelling的專欄。 db的示例：

Book A 45 
Book B 0 
Book C 159 
Book D 78 
. 
. 
. 
Book Z 450 

上面的數字出現在數據庫的NotSelling列中。我需要從這張大桌子上提取前20本書。現在我的解決方案是對錶格進行排序，然後使用TOP來提取前20條記錄。

我想知道的是關於排序表的性能。因爲我確定不斷排序表格以簡單得到前20個結果需要花費很長時間。我已經給出瞭解決問題的方法：

• 索引NotSelling問題。
• 緩存查詢（但我讀過有關粗無效這可能會導致問題，因爲我的情況下失效頻率會很高）
• 排序表中取前20條記錄，將它們放置在另一張表，然後定期剛更新表格說每小時左右。

但是，這一切說有沒有人知道這個問題的更好的解決方案或有一種方法/方法來優化功能的性能，我期待做的？注意我是一個新手，所以任何人都應該能夠指向正確的方向，在那裏我可以閱讀關於數據庫性能的內容，我真的很感激它。

Answer 1

我想你在這裏想的太多了。絕對是一個過早優化的例子。儘管上述所有解決方案都是完全有效的。你應該知道100K +記錄是否可以存放到Mysql中。我們過去常常在有三千萬行以上的表格上使用order，並且表現出色。

但是你必須必須對列上的索引進行排序並仔細檢查您的表模式。註冊。緩存也不用擔心，當表格沒有改變時，mysql會爲你重複查詢。但是欄目索引是必須的，主要的和最重要的要求。

Answer 2

不要擔心排序的性能。如果事實證明這是一個問題，那麼可以在以後通過添加一個索引來在數據庫中修復這個問題。

在設計階段，優化是一個分心。相反，應關注實現代表問題的功能和直接性。只要這些目標達到了目標，其他任何事情都可以比較容易地解決。

Answer 3

根據支持列的索引的數據結構中保存的元數據類型，遍歷可能在O（n）時間內完成，n是返回的項目數。

這意味着從理論上講，無論您有100萬還是200萬億記錄，只要您有索引，拉前20就會一樣快。在實踐中，會有一個性能差異，因爲一個小索引將適合內存，而一個大索引將不得不使用該磁盤。

所以總之，你太擔心了。至於Srikar Appal，一份正確索引的100k記錄表對於MySQL來說並不是什麼好東西