你在查詢分析器里，先打開「執行計劃」，然後執行存儲過程，跟蹤看慢在哪裡吧
㈡ SQL 語句執行感覺很慢，怎麼回事
到這個數量級的全部更新，肯定會很慢。
第一。你的記錄不一定在同一個partition，
第二。不明白為什麼那麼多人建議你建索引，你建的索引越多，你的更新速度越慢，因為你更新記錄的同時，還有更新索引。
第三。你必須知道更新速度慢的瓶頸在哪裡。是讀寫太多，還是內存不夠，還是CUP不夠快，然後對症下葯。
下面介紹兩個簡單的辦法，也許有效：
第一：
把這個100W行的表縱向劈成兩個，用外鍵關系連接，一個裝小的，經常改變的數據比如ID,外鍵，狀態值，時間等，另一個裝大的，不經常改變的數據，比如很長的字元串，xml，text 等。
這樣更新時操作小的這個表，可以大大節約內存和CPU 開銷，降低磁碟操作。
壞處就是查詢時會慢些。
第二：
把這100W行橫向切成很多個表，比如每個月的記錄裝在一個表裡，這樣每個表的記錄數可能只有幾萬，查詢，更新都會快很多。
壞處是查詢，更新都不如原來好寫。
㈢ 如何解決SQL查詢速度太慢
1. 執行計劃中明明有使用到索引，為什麼執行還是這么慢？
2. 執行計劃中顯示掃描行數為 644，為什麼 slow log 中顯示 100 多萬行？
a. 我們先看執行計劃，選擇的索引 「INDX_BIOM_ELOCK_TASK3(TASK_ID)」。結合 sql 來看，因為有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能會更差，優化器選擇這個索引避免了排序。
那為什麼不選 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很簡單，TASK_DATE 欄位區分度太低了，走這個索引需要掃描的行數很大，而且還要進行額外的排序，優化器綜合判斷代價更大，所以就不選這個索引了。不過如果我們強制選擇這個索引（用 force index 語法），會看到 SQL 執行速度更快少於 10s，那是因為優化器基於代價的原則並不等價於執行速度的快慢；
b. 再看執行計劃中的 type:index，"index" 代表 「全索引掃描」，其實和全表掃描差不多，只是掃描的時候是按照索引次序進行而不是行，主要優點就是避免了排序，但是開銷仍然非常大。
Extra:Using where 也意味著掃描完索引後還需要回表進行篩選。一般來說，得保證 type 至少達到 range 級別，最好能達到 ref。
在第 2 點中提到的「慢日誌記錄Rows_examined: 1161559，看起來是全表掃描」，這里更正為「全索引掃描」，掃描行數確實等於表的行數；
c. 關於執行計劃中：「rows：644」，其實這個只是估算值，並不準確，我們分析慢 SQL 時判斷准確的掃描行數應該以 slow log 中的 Rows_examined 為准。
4. 優化建議：添加組合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
優化過程：
TASK_DATE 欄位存在索引，但是選擇度很低，優化器不會走這個索引，建議後續可以刪除這個索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在這個 sql 中 REL_DEVID 欄位從命名上看選擇度較高，通過下面 sql 來檢驗確實如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由於有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 組合選擇度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在測試環境添加 REL_DEVID，TASK_ID 組合索引，測試 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引後執行計劃：
這里還要注意一點「隱式轉換」：REL_DEVID 欄位數據類型為 varchar，需要在 sql 中加引號：AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'
執行時間從 10s+ 降到 毫秒級別：
1 row in set (0.00 sec)
結論
一個典型的 order by 查詢的優化，添加更合適的索引可以避免性能問題：執行計劃使用索引並不意味著就能執行快。
㈣ SQL server2000數據存儲多了之後存儲速度變慢是什麼原因
數據量大的話,不妨新建一個新的資料庫...將許久不用的資料轉移到新資料庫中.保持常用和常謹賣拆查詢的資料庫的筆數和大小..維持在一個讓人滿意的程度.不配顫然慢是早晚的事.另外判斷一下,是否是查詢慢存儲一般會覺得是直接塞一筆..而平常使用,查詢可能會先於存儲執行..因為有些判斷什麼的.
如果實祥棗際上是查詢慢的話..可以按查詢的關鍵字建立索引..不過.如果數據量本身就超大..建立索引會需要比較長的時間.
㈤ sql資料庫文件過大，程序運行非常慢，怎麼辦
收縮資料庫
一般情況下，SQL資料庫的收縮並不能很大程度上減小資料庫大小，其主要作用是收縮日誌大小，應當定期進行此操作以免資料庫日誌過大
1、設置資料庫模式為簡單模式：打開SQL企業管理器，在控制台根目錄中依次點開Microsoft SQL Server-->SQL Server組-->雙擊打開你的伺服器-->雙擊打開資料庫目錄-->選擇你的資料庫名稱（如論壇資料庫Forum）-->然後點擊右鍵選擇屬性-->選擇選項-->在故障還原的模式中選擇「簡單」，然後按確定保存
2、在當前資料庫上點右鍵，看所有任務中的收縮資料庫，一般裡面的默認設置不用調整，直接點確定
3、收縮資料庫完成後，建議將您的資料庫屬性重新設置為標准模式，操作方法同第一點，因為日誌在一些異常情況下往往是恢復資料庫的重要依據
㈥ 大神們幫忙看看這個SQL語句執行有點慢，要怎麼優化才變快點
你好，根據SQL，我給予一些建議，最好根據執行計劃：
若走的全表掃描，建議建立表間關聯欄位索引，查看索引失效原因，修改SQL關聯邏輯，大部分都能解決。
如果是數據量大的問題：
a. 如果有多個查詢條件，建議建立where限制條件，減少數據統計范圍。
b. 如果實時性要求不高，可以定時跑批，把結果放在結果表裡，前台查詢結果表。
c. 關聯表太多，SQL建議拆分兩端，sum統計單獨放一個SQL。
㈦ 求解navicat for mysql 對1個G的sql文件導入超級慢怎麼處理在線等！急急急！求指點
在my.ini最底下添加個KV對：
max_allowed_packet=100000M
然後重啟Mysql，就可以按普通的方法導了，可以用mysql命令，也可以用navicat for mysql(我一般用這個)
不知道能不能寫成100G，沒試過，LZ試下吧。
如果改不了my.ini可以試試這個方法，我沒試過，因為我一直是改my.ini的，相信你有這么大的資料庫應該不是用的虛擬主機吧：
set global max_allowed_packet = 100*1024*1024*1024;
然後用：
show VARIABLES like '%max_allowed_packet%';
查看一下是否修改成功，這個應該就不用重啟mysql了，重啟反而失效了。
㈧ 如何解決SQL查詢速度太慢
解決方法如下：
1、把數據、日誌、索引放到不同的設備上，增加讀取速度；
2、縱向、橫向分割表，減少表的尺寸；
3、升級硬體；
4、困爛根據查詢條件,建立索引，優化索引、優化悶廳訪問方式，限制結果集的數據量，注意填充因子要適當，索引應該盡量小，使用位元組數小的列建索引螞尺隱好，不要對有限的幾個值的欄位建單一索引如性別欄位；
4、提高網速。
㈨ 為什麼我的mysql導入sql文件很慢，3000多條的insert語句都要5分鍾，我朋友電腦卻不超
硬碟讀寫速度會影響輸入庫的寫入速度的，另外看看你的mysql是不是加了好多索引，或者是不是遠端資料庫。。。硬碟，cpu，內存，網路和mysql配置都會對執行速度產生影響的