❶ 一個sql有時執行速度很快有時很慢，請問處理思路
原因有很多的。
主鍵約束。
當數據量達到百萬以上的時候，你用主鍵去搜索某一條數據時速度是極快的。但當你不用主鍵去搜索的時候速度就降了幾十倍甚至上百倍，這個是主鍵的好處。
索引。
當你的表欄位設置有索引的時候，搜索速度比不創建索引要快幾倍至幾十倍。
sql語句不夠優化。
在查詢某數據的時候，能不用*就盡量不用，想要哪個欄位就查哪個，多餘的不要，這樣就能達到數據傳輸精簡化，讓查詢速度也能快上許多。
多表聯合查詢。
在大數據量的時候這個多表查詢盡量不用，畢竟是很耗內存的，寧願用其他語言循環執行簡單的 select 欄位 from 表名 where 條件 這樣的簡單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語句多表聯查，查詢速度太慢，超過10s，由於是菜鳥，不知道怎樣優化
確定是菜鳥，sql 寫成這樣 證明你邏輯很清楚啊，建議如果是初學者，代碼規范一定要保持
不知道代碼規范，可以去窗口format一下。。。
言歸正傳 你這個優化的話 可以把
AND p.mediatypeinfoid in (
select
id
from
fn_get_mediatype_infor(5)
)
上面這部分 換成 inner join
❹ 怎樣提升SQL語句的查詢速度
1.選擇最有效率的表名順序。ORACLE的解析器按照從右到左的順序處理FROM子句中的表名,因此FROM子句中寫在最後的表(基礎表 driving table)將被最先處理. 在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎表。如果有3個以上的表連接查詢, 那就需要選擇交叉表(intersection table)作為基礎表, 交叉表是指那個被其他表所引用的表。
2.WHERE子句中的連接順序。ORACLE採用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾。
3.SELECT子句中盡量避免使用 『* 』。
4.使用DECODE函數來減少處理時間。
5.查詢結果能不排序就不排序。盡量不用Order by,distinct,union,MINUS,INTERSECT。
6.用表連接代替子查詢in。
7.用索引提高查詢效率。但是索引不能隨便用，還要搞清楚每種索引適用的情況，比如B*索引、復合索引、函數索引、bitmap索引等。雖然使用索引能得到查詢效率的提高,但是也必須注意到它的代價. 索引需要空間來存儲,也需要定期維護, 每當有記錄在表中增減或索引列被修改時, 索引本身也會被修改. 這意味著每條記錄的INSERT , DELETE , UPDATE將為此多付出幾 次的磁碟I/O，因為索引需要額外的存儲空間和處理,那些不必要的索引反而會使查詢反應時間變慢。
8.不能再索引列上適用not、<>、is null、not is null、做四則運算，否則索引會被抑制，不起作用，變成全表掃描。
9.用>=替代>。比如SELECT * FROM S WHERE ID>=4效率SELECT * FROM S WHERE ID>3高。兩者的區別在於, 前者DBMS將直接跳到第一個ID等於4的記錄，而後者將首先定位到ID=3的記錄並且向前掃描到第一個DEPT大於3的記錄。
10.如果表的數據量很大，可以為該表建分區。經常使用的子查詢可以建成視圖。
.
.
.
.
.
.
.
.
❺ 如何解決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 語句執行感覺很慢，怎麼回事
到這個數量級的全部更新，肯定會很慢。
第一。你的記錄不一定在同一個partition，
第二。不明白為什麼那麼多人建議你建索引，你建的索引越多，你的更新速度越慢，因為你更新記錄的同時，還有更新索引。
第三。你必須知道更新速度慢的瓶頸在哪裡。是讀寫太多，還是內存不夠，還是CUP不夠快，然後對症下葯。
下面介紹兩個簡單的辦法，也許有效：
第一：
把這個100W行的表縱向劈成兩個，用外鍵關系連接，一個裝小的，經常改變的數據比如ID,外鍵，狀態值，時間等，另一個裝大的，不經常改變的數據，比如很長的字元串，xml，text 等。
這樣更新時操作小的這個表，可以大大節約內存和CPU 開銷，降低磁碟操作。
壞處就是查詢時會慢些。
第二：
把這100W行橫向切成很多個表，比如每個月的記錄裝在一個表裡，這樣每個表的記錄數可能只有幾萬，查詢，更新都會快很多。
壞處是查詢，更新都不如原來好寫。
❼ sql使用時間查詢非常緩慢，為什麼
你用什麼類型資料庫？orcl還是sqlserver？查詢緩慢也有很多原因，不僅是你的查詢語句問題，有時候和你硬體也有關系。select XXXX from dbo.tab_name where Test_Time between '2015-03-23 11:34:27' and '2015-03-26 11:34:27' 時間是字元串，是沒有問題的，不用轉類型，即使你的欄位是DateTime類型
❽ sql語句查詢速度慢
可以分時操作呀，你把一部分數據融合之後做成視圖或者把你的SQL語句寫成存儲過程。在條件裡面盡量少使用「<>」不等於，或者not in,其實這也是告訴你不僅僅從數據結構的方面考慮問題哦