-
匿名使用者2024-01-28我有幾個想法來解決問題，我通常這樣用，1億不是很多。
- 華麗的分界線---
如果是預言機資料庫。
如果我們把乙個普通的表改成乙個分割槽表，我們可以使用Oracle的**重定義包dbms redefinition來實現它。
同樣，如果該錶未插入並且僅可用於查詢，我們可以壓縮該錶並將其更改為收縮表。
壓縮插入效率低下，但查詢效率高。
如果是其他資料庫，比如sybase，只能定義一些索引，索引應該放在不同的段中，防止查詢時出現io爭用，降低查詢效果。
一般來說，1億條資料不算多，但還是比較容易處理的，我這邊的表格還是查詢了好幾十億美金。
還應該提醒的是，我們不能讓乙個表的資料一直增加，我們需要遷移表的資料。
例如，定期將乙個表的資料遷移到另乙個歷史表中。 如果是歷史表，我就沒說了，呵呵。
-
匿名使用者2024-01-27分表或分割槽查詢合併。 雙。
對於常見的條件列，索引也是必不可少的。
-
匿名使用者2024-01-26索引可以提高查詢修改和刪除的速度，前提是您在 where 條件中使用了帶有新增索引的字段 索引分為聚集索引和唯一索引，表中只允許乙個聚集索引，聚類表示資料的物理儲存。
-
匿名使用者2024-01-25建立乙個新錶，選擇不需要刪除的資料並將其放入其中。
然後刪除原始表，重新命名它，並重新生成索引。
我無法使用 Delete 在半天內執行所有內容。
-
匿名使用者2024-01-24全年的資料是不能刪除的，只能刪除整套賬戶的資料，因為速度沒有年終，不像其他品牌可以全年，年終是一整套賬戶組成的。 所以它是不同的。
-
匿名使用者2024-01-23資料量過大，分數庫被子表化。 否則，效率將極低。
-
匿名使用者2024-01-22愚蠢的方法是將其插入迴圈中，我暫時想不出乙個好技巧：alter table table name add val char（1） - 更改表以新增列。
declare @next int
set @next=1
while @next<=1000000000 --迴圈開始
插入到表名稱中 values（'1')set @next=@next+1
end -- 迴圈的結束。
alter table table name drop column val -- 刪除新增的列。
從表名中選擇 *。
-
匿名使用者2024-01-21使用儲存過程、insert 語句執行它，並迴圈 1 億次。
-
匿名使用者2024-01-20僅使用乙個自遞增表預構建 1 億個資料條目的目的是什麼？
-
匿名使用者2024-01-19應該根據具體的效能要求來做，不能一概而論，有的是更新，有的是查詢，有的是鏈結，應該具體分析。
-
匿名使用者2024-01-18你碰到的900萬條資料資料表是無法顯示的，也沒有人會用一頁看到900萬條資料，你可以從資料庫段分頁展示，一次只上傳1000條或者多少條，這樣速度就不會慢。 你的900資料庫不是查詢的問題，網路傳輸程式響應需要時間，只能減小國際的規模，縮短時間。
房東已經建立了索引，但是是全表掃瞄，但是沒有where語句索引，基本沒用，所以還是分頁。 每次檢索資料時，都是雙頂的，既可以使用索引，又可以減小返回資料集的大小。
-
匿名使用者2024-01-17根據您對需求的評價：
但是，程式需要查詢每行的所有資料"、“查詢全部900萬條資料”。
這個需求和索引沒有關係（因為肯定是全表掃瞄過了），提高效率的方法有：1、提高硬碟的I/O速度; 2. 增加記憶體，使 SQL Server 具有更多快取。
另外，你的程式不應該一次拿那麼多資料再回來，這樣會拖累死死，建議你考慮改變處理邏輯（比如，批量檢索——可以根據ID列的值進行批處理; 將資料直接儲存在伺服器上作為文字，然後將其傳送回本地程序）。
相反，您需要根據此資料一一執行其他功能，並且此應用程式未連線到網際網絡"
即便如此，你也無法一次取回900萬個資料，如果非要拿出來再做一遍，那就得考慮分批取。 或者，將處理邏輯寫入儲存過程，然後 SQL Server 本身執行邏輯處理。 總之，無論如何，你也必須優化你當前的處理邏輯（我認為這是不合理和低效的）。
當它實際部署到電網的伺服器時，速度會提高嗎？
當然，伺服器比你本地的要快很多，硬體配置也完全不在同一水平上，但無論如何，建議你按照上面的建議來優化你的處理邏輯，否則，你的系統效率會很低。
-
匿名使用者2024-01-16首先，檢索資料的目的是通過搜尋的結果獲取資訊，如流量記錄、對比記錄、統計等。
但是，**顯示 900w 記錄，搜尋者很難獲得所需的資訊。
因此，實際應用不是一次檢索大量資料，而是從大量資料中選擇一部分資料，或者對大量資料進行統計計算。
決定檢索速度的因素包括：
1.設計對檢索的影響：如合理的主鍵，即索引設計。
2、檢索語句的效率：如子句的應用、資料分組、排序、過濾等。
3、資料庫管理系統的配置：包括硬體配置和軟體配置。
-
匿名使用者2024-01-15您需要知道的第一件事是查詢所有記錄的目的，然後您可以為此目的對其進行修改。
建議根據目的製作乙個儲存過程或函式，並處理執行結果的輸出，而不是全部顯示，因為輸出也會消耗大量時間。
建議拆分此表，看看是否可以拆分為多個包含數百萬條記錄的表。 執行通過多個執行緒執行。
因為不知道查詢的目的，所以只能籠統地談談我的想法，具體的優化方案需要詳細分析。
-
匿名使用者2024-01-14如果在 where 條件中使用帶有索引的字段，則可以更快地修改和刪除索引。
索引分為聚簇索引、非聚簇索引和唯一索引，乙個表中只允許乙個聚簇索引，聚類代表資料的物理儲存，索引可以提高搜尋速度，但會降低修改和插入的速度，所以不適合在乙個表中建立更多的索引，我們不需要為簡單的表構建索引。
所以毫無疑問，自然事物的索引會查詢你的一億條記錄表！索引旨在提高資料庫效能。
使用索引檢視提高效能 使用索引提高查詢效能並不是乙個新概念;但是，索引檢視提供了一些標準索引無法實現的效能提公升。 索引檢視可以通過以下方式提高查詢效能： 可以預先計算聚合並將其儲存在索引中，從而在執行查詢時最大限度地減少昂貴的計算。
您可以預聯接各個表並儲存生成的資料集。
您可以儲存聯接或聚合的組合。
在實現索引檢視之前分析資料庫工作負載。 使用您對查詢和工具（例如 SQL 事件探查器）的了解來識別將從索引檢視中受益的查詢。
當聚合和聯接頻繁發生時，最好使用索引檢視。 無論它是否經常發生，如果查詢需要較長的響應時間，並且快速獲取響應的開銷很高，則索引檢視非常適合。 例如，一些開發人員發現建立查詢響應的索引檢視很有用，這些查詢是預先計算和儲存的，供高階管理人員在月底執行的報告。
並非所有查詢都可以從索引檢視中受益。 與常規索引類似，如果不使用索引檢視，則無法從中受益。 在這種情況下，不僅無法提高效能，而且在磁碟空間、維護和優化方面會產生額外的成本。
但是，當使用索引檢視時，資料訪問可以大大改善（數量級）。