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 查詢的優化，添加更合適的索引可以避免性能問題：執行計劃使用索引並不意味著就能執行快。

Ⅱ oracle資料庫執行sql很慢怎麼回事

一條sql突然執行變慢，耗時9秒，應用是不能改的，只能從資料庫方面下手解決
步驟思路：
1：查看sql是否走索引
2：查看索引是否失效
3：hint 強制走索引（只是用來查看hint狀態下，查詢是否更改，應用是不能改的）
4：收集該表所有信息（包括索引）
5：分析該表所有信息（包括索引）
6：再次執行並查看
注意：哪個用戶執行較慢，就用哪個用戶進行操作，這樣才准確

Ⅲ SQL查詢一塊查，和分開查的時間一樣嗎

你好，很高興回答你的問題。
這兩張查詢方式的耗時是不一樣的。
如果索引合適，數據量也不是太大的話，一個sql執行的耗時是遠小於按天查詢執行31個sql的耗時的。
如果有幫助到你，請點擊採納。

Ⅳ sql存儲過程耗時太長

多長都有可能，40是很正常的。
1．盡量優化語句，盡量少用游標。
2．修改較為常用的表要注意，最好先在臨時表中作好運算和其它處理，最後在修改這些表，以免較慢的存儲過程長時間鎖定表記錄，影響數據正常使用。
3．將連接超時和命令超時適當擴大，以免超時錯誤。

Ⅳ PL/SQL 耗時的原因有哪些

1.索引建的有問題
2.數據量過大
3.sql寫的不合理

最好的辦法是優化索引和優化sql語句,定期刪除無用數據也行

Ⅵ MySQL怎麼查詢比較耗時的sql語句

開啟慢查詢日誌即可
文件方式配置
MySQL
慢查詢的方法：
在
mysql
配置文件
my.cnf
中增加：
log-slow-queries=/opt/data/slowquery.log
long_query_time=2
log-queries-not-using-indexes
命令方式配置
MySQL
慢查詢的方法：
set
global
slow_query_log=on;
set
global
long_query_time=1;
set
global
slow_query_log_file=『/opt/data/slow_query.log』;
查詢
MySQL
慢查詢狀態的方法：
SHOW
VARIABLES
LIKE
'%query%';
解析
MySQL
慢查詢日誌的方法：
按照
sql
執行時間最長的前
20
條
sql：
mysqlmpslow
-s
t
-t
20
-g
'select'
/opt/data/slowquery.log

Ⅶ 在MySQL 中，哪些原因導致一條簡單的 SQL 插入耗時很長

Count: 6 Time=25.33s (152s) Lock=0.00s (0s) Rows=0.0 (0), xxx[xxx]@xxx
INSERT INTO tablename(f_uid,uid,create_time) VALUES (N,N,N)
分析原因如下：
1.不可能是鎖等待，因為記錄的Lock時間為0；
2.若是InnoDB引擎，則跟主鍵為啥存在一定關系，但是應該不是特別大，從你的SQL語句看；
3.資料庫主機的負載過高，導致處理不過，是最可能的原因；

Ⅷ 怎麼統計最近最耗時的SQL

--1.不用CROSSAPPLYsys.dm_exec_sql_text(qs.sql_handle)

SELECTTOP50
(selecttextfromsys.dm_exec_sql_text(sql_handle))as[SQL]
,CAST(((qs.total_elapsed_time/1000000.0)/qs.execution_count)ASDECIMAL(28,2))AS[平均消耗秒數]
,qs.last_execution_timeAS[最後執行時間]
,CAST(qs.last_elapsed_time/1000000.0ASDECIMAL(28,2))AS[最後完成消耗秒數]
,CAST(qs.min_elapsed_time/1000000.0ASDECIMAL(28,2))AS[最小消耗秒數]
,CAST(qs.max_elapsed_time/1000000.0ASDECIMAL(28,2))AS[最大消耗秒數]
,CAST(qs.total_elapsed_time/1000000.0ASDECIMAL(28,2))AS[總消耗秒數]
,(qs.execution_count)AS[總執行次數]
,creation_timeAS[編譯計劃的時間]
,qs.*
fromsys.dm_exec_query_statsqs
ORDERBYqs.last_elapsed_timeDESC

--2.用CROSSAPPLYsys.dm_exec_sql_text(qs.sql_handle)

SELECTTOP50
SUBSTRING(st.text,(qs.statement_start_offset/2)+1,
((CASEstatement_end_offset
WHEN-1THENDATALENGTH(st.text)
ELSEqs.statement_end_offsetEND
-qs.statement_start_offset)/2)+1)as[Statement_SQL]
,CAST(((qs.total_elapsed_time/1000000.0)/qs.execution_count)ASDECIMAL(28,2))AS[平均消耗秒數]
,qs.last_execution_timeAS[最後執行時間]
,CAST(qs.last_elapsed_time/1000000.0ASDECIMAL(28,2))AS[最後完成消耗秒數]
,CAST(qs.min_elapsed_time/1000000.0ASDECIMAL(28,2))AS[最小消耗秒數]
,CAST(qs.max_elapsed_time/1000000.0ASDECIMAL(28,2))AS[最大消耗秒數]
,CAST(qs.total_elapsed_time/1000000.0ASDECIMAL(28,2))AS[總消耗秒數]
,(qs.execution_count)AS[總執行次數]
,creation_timeAS[編譯計劃的時間]
,qs.*
fromsys.dm_exec_query_statsqs
CROSSAPPLYsys.dm_exec_sql_text(qs.sql_handle)ASst
ORDERBYqs.last_elapsed_timeDESC