❶ sql server中如何快速批量刪除表裡的百萬條記錄！直接用delete top(50000)還是有點慢...
刪除大量數據速度碰冊是州爛正常的。
如果表裡面數據都不要了，可以直接truncate
如果表裡面數據只有一小部分要得，可以把小的備份出來，然後冊吵漏truncate表，然後再把備份的數據導回來
如果只是刪除表中部分數據，可以寫成循環小批量刪除腳本；如果伺服器性能好，百萬數據刪除還是很快的
❷ 為什麼oracle資料庫在刪除一條數據時,執行非常慢,好像卡在了那裡死了一樣，也不報錯，請問這是怎麼回事
有些有其他的 正在操作鎖表。
PL/SQL devloper 有選項可以查看的。
是不是數據量過大，導致delete速度慢。看看執行計劃
❸ sql資料庫中怎麼批量刪除數據總共有1萬多條，一條一條的刪好慢啊~求大俠指點！比如：刪除1-100橫排
DELETEAFROMtalbeNameASA
WHEREEXISTS(SELECT1
FROM(SELECTTOP100IDFROMtalbeName)ASB
WHERE(A.ID=B.ID));
字元類型的ID要復雜些，如果ID是int類型的就更好辦了。
❹ 請問sql中為了起到更新效果，刪除後添加數據和直接更新數據的方法相比，運行速度會怎麼樣
你這表述的有點過大了，得具體肢森問題具體分析。首先你表上是否有主鍵或者索引，更新的欄位是否跟主鍵或者索引所在的欄位有關。其次：從理論上來說，更新（需要一次磁碟操作）比先刪除在插叢晌入速率會快些（需要兩次磁碟操作）。最後：速度的快慢取決於你的操作對索引的影響，先刪除在增加理論上會增加索引碎片。如歷鄭畝果你是更新操作的話直接更新索引欄位的話，也會導致索引重新排序。
大概就是這樣吧。
❺ MySQL刪除千萬級數據量導致的慢查詢優化
有人刪了千萬級的數據，結果導致頻繁的慢查詢。
線上收到大量慢查詢告警，於是檢查慢查詢的SQL，發現不是啥復雜SQL，這些SQL主要針對一個表，基本都是單行查詢，看起來應該不會有慢查詢。這種SQL基本上都是直接根據索引查找出來的，性能應該極高。
是否可能慢查詢不是SQL問題，而是MySQL生產伺服器的問題？特殊情況下，MySQL出現慢查詢還真不是SQL問題，而是他自己生產伺服器的負載太高，導致SQL語句執行慢。比如現在MySQL伺服器的
磁碟I/O負載高，每秒執行大量高負載的隨機I/O，但磁碟本身每秒能執行的隨機I/O有限，導致輪吵櫻正常SQL在磁碟執行時，若跑一些隨機IO，臘叢你的磁碟太忙，顧不上你了，導致你本來很快的一個SQL，要等很久才能執行完畢，這時就可能導致正常SQL也變成慢查詢。
也許網路負載高，導致你一個SQL語句要發到MySQL，光是等待獲取一個和MySQL的連接，都很難，要等很久或MySQL自己網路負載太高，碰知帶寬打滿，帶寬打滿後，你一個SQL也許執行很快，但其查出來的數據返回給你，網路都送不出去，也會變成慢查詢。
若CPU負載過高，也會導致CPU過於繁忙去執行別的任務，沒時間執行你的SQL。
所以慢查詢不一定是SQL本身導致，若覺得SQL不應該會慢查詢，結果他那個時間段跑這個SQL 就是慢，應排查當時MySQL伺服器的負載，尤其看看磁碟、網路及 CPU 的負載，是否正常。
當某個離線作業瞬間大批量把數據往MySQL里灌入的時，他一瞬間伺服器磁碟、網路以及CPU的負載會超高。
此時你一個正常SQL執行下去，短時間內一定會慢查詢，類似問題，優化手段更多是控制你導致MySQL負載過高的那些行為，比如灌入大量數據，最好在業務低峰期灌入，別影響高峰期的線上系統運行。
但看了下MySQL伺服器的磁碟、網路以及CPU負載，一切正常，似乎也不是這問題導致。看起來無解了？
慢 SQL 的頭兩步排查手段：
這兩種辦法都不奏效之後，第三步：用MySQL profilling工具去細致的分析SQL語句的執行過程和耗時。
這個工具可以對SQL語句的執行耗時進行非常深入和細致的分析
打開profiling，使用
接著MySQL就會自動記錄查詢語句的profiling信息。此時若執行show profiles，就會給你列出各種查詢語句的profiling信息，會記錄下來每個查詢語句的query id，所以你要針對你需要分析的query找到對他的query id，我們當時就是針對慢查詢的那個SQL語句找到了query id。
然後針對單個查詢語句，看其profiling信息，使用show profile cpu, block io for query xx，這里的xx是數字，此時就可以看到具體的profile信息。
除了cpu以及block io以外，還能指定去看這個SQL語句執行時候的其他各項負載和耗時。
會給你展示出來SQL語句執行時候的各種耗時，比如磁碟IO的耗時，CPU等待耗時，發送數據耗時，拷貝數據到臨時表的耗時等，SQL執行過程中的各種耗時都會展示。
檢查該SQL語句的profiling信息後，發現問題，其Sending Data耗時最高，幾乎使用1s，占據SQL執行耗時的99%！其他環節耗時低可以理解，畢竟這種簡單SQL執行速度真的很快，基本就是10ms級別，結果跑成1s，那肯定Sending Data就是問題根源！
這Sending Data在幹啥呢？
MySQL官方釋義：為一個SELECT語句讀取和處理數據行，同時發送數據給客戶端的過程，簡單來說就是為你的SELECT語句把數據讀出來，同時發送給客戶端。
但這過程為啥這么慢？profiling確實是提供給我們更多的線索了，但似乎還是沒法解決問題。但已經捕獲到異常關鍵點，就是Sending Data的耗時很高！
接著：
看innodb存儲引擎的一些狀態，此時發現一個奇怪的指標：history list length，值特別高，達到上萬。
MVCC就是多個事務在對同一個數據， 有人寫，有人讀，此時可以有多種隔離級別，對一個數據有個多版本快照鏈條，才能實現MVCC和各種隔離級別。
所以當你有大量事務執行時，就會構建這種undo多版本快照鏈條，此時history list length就會很高。然後在事務提交後，會有一個多版本快照鏈條的自動purge清理機制，清理了，該值就會降低。一般該值不應過高，所以注意到第二個線索：history list length過高，即大量的undo多版本鏈條數據沒有清理。推測可能有的事務長時間運行，所以其多版本快照不能被purge清理，進而導致history list length過高。
經過這倆線索推測，在大量簡單SQL變成慢查詢時，SQL因為Sending Data環節異常，耗時過高；同時此時出現一些長事務長時間運行，大量的頻繁更新數據，導致有大量undo多版本快照鏈條，還無法purge清理。
因為發現有大量的更新語句在活躍，而且有那種長期活躍的長事務一直在跑而沒有結束，問了下系統負責人，在後台跑了個定時任務：他居然開了一個事務，然後在一個事務里刪除上千萬數據，導致該事務一直在運行。
這種長事務的運行會導致你刪除時，僅只是對數據加了一個刪除標記，事實上並沒有徹底刪除。此時你若和長事務同時運行的其它事務里再查詢，他在查詢時可能會把那上千萬被標記為刪除的數據都掃描一遍。因為每次掃描到一批數據，都發現標記為刪除了，接著就會再繼續往下掃描，所以才導致一些查詢語句很慢。
那為何你啟動一個事務，在事務里查詢，憑什麼就要去掃描之前那個長事務標記為刪除狀態的上千萬的垃圾數據？講道理，那些數據都被刪了，跟你沒關系了呀，你可以不去掃描他們 嘛！
而問題症結在於，那個 刪除千萬級數據的事務是個長事務 ！即當你啟動新事務查詢時，那個刪除千萬級數據的長事務一直在運行，它是活躍的！結合MVCC的Read View機制，當你啟動一個新事務查詢時，會生成一個Read View。你的新事務查詢時，會根據ReadView去判斷哪些數據可見及可見的數據版本號，因為每個數據都有個版本鏈條，有時你能可見的僅是這個數據的一個 歷史 版本。
所以正是因為該長事務一直在運行，還在刪除大量數據，而且這些數據僅是邏輯刪除，所以此時你新開事務的查詢還是會讀到所有邏輯刪除數據，也就會出現千萬級的數據掃描，導致了慢查詢！
所以禁止在業務高峰期運行那種刪除大量數據的語句，因為這可能導致一些正常的SQL都變慢查詢，因為那些SQL也許會不斷掃描你標記為刪除的大量數據，好不容易掃描到一批數據，結果發現是標記為刪除的，於是繼續掃描下去，導致慢查詢！
直接kill那個正在刪除千萬級數據的長事務，所有SQL很快恢復正常。此後，大量數據清理全部放在凌晨執行，那個時候就沒什麼人使用系統了，所以查詢也很少。
❻ sql在數據量很大的表中刪除部分數據怎麼提高效率
要做一個code+cp的非聚合索引，還有你把語句放在SQL managment studio，按上面按鈕 顯示估計的執行計劃 就可以看到哪裡需要時間最多，然後建立索引。
❼ 請問SQL2000,清空一個三千萬行的表,需要多少時間
這個比較難說，分如下兩個點來看：
一、數據伺服器是遠程的，如果速度比較橡舉快的話速度每秒可操作數據上萬條
如果資料庫伺服器的MS比較高那就難說了，要根據具本的情況來定了
二棚如祥、如果是本地伺服器，那麼只需要半個小時左右就可以搞定
這些數據沒有做過具體的測試，只是根據自己個人在做資料庫的時候的鏈搏一些經驗。你自己參考一下吧。
❽ sql server insert 與 delete 三百萬級數據量時速度極慢，有10分鍾左右，求高手如何解決
你首先確定是否用上了索引，你可以再網上搜下sql server的一些系統調優函數，我知道sybase資料庫有個sp_showplan id,null,null,null 就可以看出那些使用了索引，那麼定義了索引但是沒被使用，一般用上了正確的索引如果還是10分鍾的，那麼在怎麼優化都提高不了很多了，300萬數量的表除了必要的索引外其他索引可以幹掉，因為insert,delete每次操作都要對索引也要操作，修改索引本身要比你插值和刪除要花費的時間多多了
你insert這個表如果數據不多，不應該有10分鍾，delete因為要關聯可能會有10分鍾左右，如果你以上都操作了，可以考慮是否是索引壞了，重建下索引，最好先清下日誌，防止日誌滿
❾ 江湖救急~！！！！sql server 刪除表數據慢
建議適當減少索引的數據量，慢慢的並能成功的刪除。而且這與機器的運行快慢本身也有關！