EntityFramework VS SQL存儲過程

Question

我有一個超過10,000,000行的表。

我通過

需要一些過濾器（有些in查詢和一些like查詢）和動態訂單我不知道什麼是大數據，分頁，篩選和排序工作的最佳途徑。

當然它很容易與實體框架的工作，但我覺得性能上存儲過程

Answer 1

更好，我有一個表1000多萬行。

你有一個小桌子，幾乎很小，對於任何濫用服務器的人都沒有問題。

說真的。

我不知道什麼是大數據工作的最佳方式，

與具有大數據開始。這通常定義爲低成本服務器的多倍RMA。其中今天有大約16個內核和大約128GB內存。之後，它變得昂貴。

一般規則是：

• 切勿PAGE。開始分頁很容易，但是最終結果很慢 - 要麼預先計算頁面並存儲它們，要麼只是爲了丟棄結果而重新執行查詢。它在第1-2頁很好，然後它變慢。

當然它很容易與實體框架的工作，但我覺得 性能上存儲過程

更好，爲什麼會是這樣？生成查詢的開銷很小，與經常重複的妄想相反--SQL Server對所有內容都使用查詢計劃緩存。如果編譯開銷很大（即SMALL數據），或者通過網絡拉取大量數據以便將結果發送回來（僅在數據庫中處理），則SP更快。

對於anyhing否則「一般」的性能的影響接近於零。

OTOH它可以讓你發送更多的定製SQL不進歌廳非常糟糕和醜陋的存儲過程 - 要麼發出動態SQL內部，或有噸可選參數的複雜情況。

什麼要小心：

• IN子句可以是可怕的性能。不要把數百個元素放在那裏。如果你需要的話 - 一個SP和一個表格變量，準備和加入是更好的方法。
• 正如我所說 - 小心尋呼。有人要求第100頁，只是前進就是重複處理TON。

And：態度調整。大約20年前一千萬行的時間。