Ⅰ 如何解決sql查詢速度太慢
呵呵，這個問題很有趣不是嗎？
上面的同志們只是給出一些建議，以我的經驗來看（oracle），
如果數據量較大，索引的重復量盡量避免，最好的方式是建立非業務id（最好使用自增或是序列），把這個id建立索引。
你的最大的問題就是，建立了索引後，索引列必須出現在where中，否則索引就白白建立了，比如你的id是從1一直到383000，那麼你的語句可以寫成
select
*
from
hr_worktime
where
id>-1
還有就是，where條件中避免出現!=,or,between,等東西，否則索引實效。
Ⅱ 如何解決SQL Server查詢速度緩慢的問題
你先看看綁定的時候代碼有問題沒。
然後注意取數據最好用存儲過程，不僅快還好維護。分頁查詢百萬級的數據我覺得不一定要用。
資料庫的索引建立，以及舊數據歸檔也就是很有效地提高性能的方法。
Ⅲ sql 因為某一個查詢條件，速度變得很慢，怎麼解決
LodingType設置成char（1）
sql 查詢 把能排除大量條數的放在最後面 執行是從最後面執行的
and (selldelete is null or selldelete = 0) and AuditState!= 99 sql 排除之後是不是都是LodingType= 5了 如果是可能你的速度回變慢 參考2
Ⅳ 如何解決SQL Server查詢速度緩慢的問題
1.查詢的模糊匹配
盡量避免在一個復雜查詢裡面使用 LIKE '%parm1%'——紅色標識位置的百分號會導致相關列的索引無法使用，最好不要用.
解決辦法:
其實只需要對該腳本略做改進，查詢速度便會提高近百倍。改進方法如下：
a、修改前台程序——把查詢條件的供應商名稱一欄由原來的文本輸入改為下拉列表，用戶模糊輸入供應商名稱時，直接在前台就幫忙定位到具體的供應商，這樣在調用後台程序時，這列就可以直接用等於來關聯了。
b、直接修改後台——根據輸入條件，先查出符合條件的供應商，並把相關記錄保存在一個臨時表裡頭，然後再用臨時表去做復雜關聯
2.索引問題
在做性能跟蹤分析過程中，經常發現有不少後台程序的性能問題是因為缺少合適索引造成的，有些表甚至一個索引都沒有。這種情況往往都是因為在設計表時，沒去定義索引，而開發初期，由於表記錄很少，索引創建與否，可能對性能沒啥影響，開發人員因此也未多加重視。然一旦程序發布到生產環境，隨著時間的推移，表記錄越來越多
這時缺少索引，對性能的影響便會越來越大了。
這個問題需要資料庫設計人員和開發人員共同關注
法則：不要在建立的索引的數據列上進行下列操作:
◆避免對索引欄位進行計算、函數、類型轉換
◆避免在索引欄位上使用not，<>，!=
◆避免在索引列上使用空值、IS NULL和IS NOT NULL
3.復雜操作
部分UPDATE、SELECT 語句寫得很復雜（經常嵌套多級子查詢）——可以考慮適當拆成幾步，先生成一些臨時數據表，再進行關聯操作
4.update
同一個表的修改在一個過程里出現好幾十次，如：
update table1
set col1=...
where col2=...;
update table1
set col1=...
where col2=...
......
象這類腳本其實可以很簡單就整合在一個UPDATE語句來完成（前些時候在協助xxx項目做性能問題分析時就發現存在這種情況）
5.在可以使用UNION ALL的語句里，使用了UNION
UNION 因為會將各查詢子集的記錄做比較，故比起UNIONALL ，通常速度都會慢上許多。一般來說，如果使用UNION ALL能滿足要求的話，務必使用UNION ALL。還有一種情況大家可能會忽略掉，就是雖然要求幾個子集的並集需要過濾掉重復記錄，但由於腳本的特殊性，不可能存在重復記錄，這時便應該使用UNION ALL，如xx模塊的某個查詢程序就曾經存在這種情況，見，由於語句的特殊性，在這個腳本中幾個子集的記錄絕對不可能重復，故可以改用UNION ALL）
6.在WHERE 語句中，盡量避免對索引欄位進行計算操作
這個常識相信絕大部分開發人員都應該知道，但仍有不少人這么使用，我想其中一個最主要的原因可能是為了編寫寫簡單而損害了性能，那就不可取了
9月份在對XX系統做性能分析時發現，有大量的後台程序存在類似用法，如：
......
where trunc(create_date)=trunc(:date1)
雖然已對create_date 欄位建了索引，但由於加了TRUNC，使得索引無法用上。此處正確的寫法應該是
where create_date>=trunc(:date1) andcreate_date
或者是
where create_date between trunc(:date1) andtrunc(:date1)+1-1/(24*60*60)
注意：因between 的范圍是個閉區間（greater than or equal to low value and less than or equal to highvalue.），
故嚴格意義上應該再減去一個趨於0的小數，這里暫且設置成減去1秒（1/(24*60*60)），如果不要求這么精確的話，可以略掉這步。
7.對Where 語句的法則
7.1避免在WHERE子句中使用in，not in，or 或者having。
可以使用 exist 和not exist代替 in和not in。
可以使用表鏈接代替 exist。Having可以用where代替，如果無法代替可以分兩步處理。
例子
SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN
(SELECT CUSTOMER_NAME FROM CUSTOMER)
優化
SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist
(SELECT CUSTOMER_NAME FROM CUSTOMER)
7.2 不要以字元格式聲明數字，要以數字格式聲明字元值。（日期同樣）否則會使索引無效，產生全表掃描。
例子使用：
SELECT emp.ename, emp.jobFROM emp WHERE emp.empno = 7369;
不要使用：SELECT emp.ename,emp.job FROM emp WHERE emp.empno = 『7369』
8.對Select語句的法則
在應用程序、包和過程中限制使用select * from table這種方式。看下面例子
使用SELECT empno,ename,categoryFROM emp WHERE empno = '7369『
而不要使用SELECT * FROM empWHERE empno = '7369'
9. 排序
避免使用耗費資源的操作，帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啟動SQL引擎 執行，耗費資源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序
10.臨時表
慎重使用臨時表可以極大的提高系統性能
所謂的優化就是WHERE子句利用了索引，不可優化即發生了表掃描或額外開銷。經驗顯示，SQL Server性能的最大改進得益於邏輯的資料庫設計、索引設計和查詢設計方面。反過來說，最大的性能問題常常是由其中這些相同方面中的不足引起的。其實SQL優化的實質就是在結果正確的前提下，用優化器可以識別的語句，充份利用索引，減少表掃描的I/O次數，盡量避免表搜索的發生。
其實SQL的性能優化是一個復雜的過程，上述這些只是在應用層次的一種體現，深入研究還會涉及資料庫層的資源配置、網路層的流量控制以及操作系統層的總體設計。
Ⅳ 如何解決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表查詢慢的原因
查詢慢是和表結構，語句，系統等相關的 建索引等方法都可以改善表結構， 另外如果返回數據量很大，當然會慢，所以你盡量查詢相對有用的數據 再就是查詢語句了 比如用in查詢沒有jion查詢快，還有 between 改成 > <會快 再還有，用子查詢也會慢很多， 如果是一些很復雜的查詢，可以改用存儲過程會好點，有時用臨時表會慢但，從海量數據中查詢取數進行子查詢又不如用臨時錶快，不同的問題用不同的解決方法，看你要哪種了，單看你的問題無法直接判斷。 不過，優化查詢句是關鍵的了。
Ⅶ sql查詢時，語句的查詢條件越多查詢的越慢嗎
這個不一定，需要看實際情況
比如 索引，比如 數據量。
通常來說，限定的條件越多，數據量越小，自然越快，效率越高
另：
如果2個結果的 數據量 完全一致， 那麼效率應該差不多， 在特殊情況下 條件多的會差一些
Ⅷ 一條查詢極為緩慢的sql語句，如何去優化呢
1、將查詢條件欄位簡歷index;
2、將盡可能篩選掉最大數據量的條件放到where條件最後面，因為sql執行時，where條件是由右往左執行。
3、盡可能少用like、in等函數
Ⅸ sql:查詢時快時慢
如果說是sql
server
的話有這種情況，欄位越多，查詢可能越慢，並且如果你的欄位中有比如text，ntext之類的話會有這種情況;
還有，你的這種寫法可能也造成執行慢，SQL在執行時有這樣一個規則，不知道你是否了解，在執行時，SQL
後台會先執行編譯，找到一條最佳查詢路徑，也就是最快的查詢路徑，再真正執行查詢;這個編譯是需要時間的，如果條件復雜，或者由其它的變化而來的條件，會存在編譯的查找最佳路徑的時間問題;
資料庫的欄位越多，會有可能越慢，不管是否是空表，至於什麼原因，好像MICROSOFT沒有說法。
另外1=1這種恆等條件最好也不要加。