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 Server查詢速度緩慢的問題
你先看看綁定的時候代碼有問題沒。
然後注意取數據最好用存儲過程，不僅快還好維護。分頁查詢百萬級的數據我覺得不一定要用。
資料庫的索引建立，以及舊數據歸檔也就是很有效地提高性能的方法。
⑶ MySQL怎麼查詢比較耗時的sql語句
一、MySQL資料庫有幾個配置選項可以幫助我們及時捕獲低效SQL語句
1，slow_query_log
這個參數設置為ON，可以捕獲執行時間超過一定數值的SQL語句。
2，long_query_time
當SQL語句執行時間超過此數值時，就會被記錄到日誌中，建議設置為1或者更短。
3，slow_query_log_file
記錄日誌的文件名。
4，log_queries_not_using_indexes
這個參數設置為ON，可以捕獲到所
⑷ 如何查找MySQL中查詢慢的SQL語句
你是指慢查詢日誌嗎？
在my.ini中加上下面兩句話
log-slow-queries = e:\mysql5.5\mysql_slow_query.log
long_query_time=10
前面一句是設置慢查詢日誌存放路徑，第二句是指多少秒以上算慢查詢，上面的語句，就是指10秒。然後show variables like '%slow%';就行了
⑸ sql查詢 數據時，查詢緩慢，無法查出情況
這個問題我也遇見過，慢的話也正常，因為數據比較多
解決辦法啊，首先從表考慮，可以針對這個表建索引，
然後的話說優化查詢語句，可以的話添加 with (nolock);即select * from A with (nolock) 這樣
然後就是where條件了，盡量不要使用like,in這些。盡量添加where條件。
這樣應該可以了，還不行的話，上網查查怎麼優化DB。
⑹ SQL子查詢過多查詢速度太慢如何優化
先行轉列行不行呢，以第一張表為例
select proctguid,
max(case when num=1 then description end) tz1,
max(case when num=2 then description end) tz2,
max(case when num=3 then description end) tz3,
max(case when num=4 then description end) tz4,
max(case when num=5 then description end) tz5
from proct_description
group by proctguid
然後再join，用proctguid和原表關聯，這樣上面就只需要寫
select p.*,tz1,tz2,tz3,tz4,tz5 from 了
⑺ MYSQL慢查詢里有一個SQL語句超慢，請求解決思路
嚴重影響性能時，不建議用*，這個*相當於一個函數，在實際的查詢過程中是會先去根據表結構轉換成具體的欄位名的，這里是會消耗性能的。
想要查看具體腳本的性能可以去查看SQL的執行計劃，分析性能主要耗在哪裡，針對性優化。
希望能幫到你……
⑻ 求助 SQL 查詢太慢
C表臨時生成還大，然後再去查詢一定會減慢速度，而且幾乎沒有能走索引或者其他條件的通道（一堆左右鏈接decode）。
語句優化幾乎做不了什麼，試試看查詢結構優化吧，比如C建立為物化視圖或者一張表等等，語句這塊做不了什麼了。
⑼ 如何優化慢查詢的SQL語句
優化方法一般從幾個方面這幾個考慮：
1、根據業務情況，精簡代碼邏輯，
2、根據讀寫方式，降低數據表讀寫量
3、關鍵條件列增加合適的索引
4、對於碎片多的索引進行重建
多數情況下只需要考慮前兩條就能解決很大的效率問題，業務模式可能在最初開發的時候，因需求分析不徹底，或者需求理解不深入，導致邏輯不合理，或者後續多次變動業務模式，新增功能與最初的開發理念發生變化，這時就應該對代碼的邏輯進行重新優化改寫。
⑽ sql語句查詢很慢,如何解決
日期列 有索引嗎？
儲值卡明細 表 的列： 住院號
住院_安排醫生 的 列： 住院號
都有索引嗎？
沒有的話，加上