當前位置：首頁 » 編程語言 » 慢sql有哪些
擴展閱讀
提分平台的賬號密碼是什麼 2023-08-31 22:07:10
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

慢sql有哪些

發布時間: 2023-06-01 18:01:49

❶ 如何查找Mysql中查詢慢的SQL語句

1、首先，要開啟mysql的慢查詢日誌。在mysql的配置文件:my.ini中添加如下兩個配置項：
log-slow-queries = E:\Servers\MySql5.5\data\mysql_slow_query.log //mysql慢查詢日誌記錄位置
long_query_time=5 //定義慢查詢sql的時間，當前配置表示超過5秒的sql為慢查詢，進入到日誌里
2、查詢慢查詢日誌
找到配置的慢查詢日誌文件，如E:\Servers\MySql5.5\data\mysql_slow_query.log ，這里就是所有的慢查詢sql啦

❷ 記錄一次慢sql排查

mysql的慢日誌中，看到有這么一條

不算太復雜的一條sql，但是掃了200多萬行的數據，所以慢。先看執行計劃

mysql> explain SELECT
-> lu.userId,
-> lu.userName,
-> lu.photo userImage,
-> lu.sex,
-> wc.typeId AS courseType,
-> wc.name AS courseName,
-> lc.className,
-> DATE_FORMAT(wcu.CreatedTime, '%Y-%m-%d %H:%i:%s') AS time
-> FROM
-> wkt_courseclassuser wcu
-> INNER JOIN wkt_course wc on wcu.courseId = wc.id
-> INNER JOIN lxx_user lu ON wcu.userId = lu.userId
-> INNER JOIN (select t.* from (select * from lxx_classuserrecord WHERE classtypeid =1 ORDER BY CreateTime desc) t GROUP BY t.userid ) lcur ON lcur.userid = lu.userId
-> INNER JOIN lxx_class lc on lc.classId = lcur.classId
-> INNER JOIN lxx_registerschool lr ON lr.schoolKey = lu.schoolKey
-> WHERE lc.status = 1 and lc.typeId = 1
-> and lr.schoolId = 60800000000000001
-> and wc.typeId in (1,2,3,23)
-> ORDER BY wc.CreateTime DESC
-> LIMIT 100;
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+----------------------------------+---------+-------------------------+-------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+----------------------------------+---------+-------------------------+-------+----------------------------------------------+
| 1 | PRIMARY | lr | ref | lxx_registerSchool_schoolId | lxx_registerSchool_schoolId | 9 | const | 1 | Using where; Using temporary; Using filesort |
| 1 | PRIMARY | lu | ref | PRIMARY,index_lxx_user_schoolKey | index_lxx_user_schoolKey | 603 | wkt_school.lr.schoolKey | 79 | Using where |
| 1 | PRIMARY | <derived2> | ref | <auto_key1> | <auto_key1> | 8 | wkt_school.lu.userId | 15 | Using where |
| 1 | PRIMARY | lc | eq_ref | PRIMARY | PRIMARY | 8 | lcur.classid | 1 | Using where |
| 1 | PRIMARY | wcu | ref | index_wkt_courseclassuser_courseId,index_wkt_courseclassuser_userId,index_wkt_courseclassuser_courseId_classId | index_wkt_courseclassuser_userId | 9 | wkt_school.lu.userId | 47 | Using where |
| 1 | PRIMARY | wc | eq_ref | PRIMARY | PRIMARY | 8 | wkt_school.wcu.courseId | 1 | Using where |
| 2 | DERIVED | <derived3> | ALL | NULL | NULL | NULL | NULL | 47204 | Using temporary; Using filesort |
| 3 | DERIVED | lxx_classuserrecord | ALL | NULL | NULL | NULL | NULL | 47204 | Using where; Using filesort |
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+----------------------------------+---------+-------------------------+-------+----------------------------------------------+

乍一看好像最大的rows才47204，為什麼實際執行掃描行數要大這么多呢？

網上找到一篇解釋
https://dba.stackexchange.com/questions/73520/mysql-explain-has-different-row-count-than-slow-query-log

大概意思是，explain只是根據數據的特徵，大概估算要掃描的行數，實際執行時，特別是需要做join操作時，結果集都是n*m的，因此實際執行結果可能要大很多。

看到執行計劃最後兩行，都是需要Using filesort的。很明顯是產生於

INNER JOIN (select t.* from (select * from lxx_classuserrecord WHERE classtypeid =1 ORDER BY CreateTime desc) t GROUP BY t.userid ) lcur ON lcur.userid = lu.userId

一行。因為INNER JOIN的是一個子查詢的結果， 上面不會有索引 ，而且這個子查詢的結果集也有幾萬條，開始的直觀感覺是慢在這里。結果優化了很久，也沒什麼效果。最後把這個關聯條件也去掉了，發現查詢時間還是跟原來差不多，因此問題不是在此。

PS：第一次沒有看懂explain的結果。explain中的第三行從derived2的結果中，也就是id為2的那條派生表查詢中，自動建立了一個auto_key1的索引，因此inner join上面那行子查詢並不會很慢

東找西找，發現去掉ORDER BY wc.CreateTime DESC以後，就變得很快了。查看了一下wkt_course的索引，果然CreateTime沒有索引。趕緊補一下
CREATE INDEX index_wkt_course_CreateTime ON wkt_course(CreateTime)

然後再explain一下，

| 1 | PRIMARY | lr | ref | lxx_registerSchool_schoolId | lxx_registerSchool_schoolId | 9 | const | 1 | Using where; Using temporary; Using filesort |

第一行這里沒有任何改觀。實際執行起來也絲毫沒有變快。

再靜下來，仔細分析一下問題在哪裡。mysql估計是先執行了連表查詢，然後對這個結果集創建臨時表，然後進行排序，最後在取出前100。用select count(*) 在去掉limit限制後數了一下，這個結果集有80多萬條數據，怪不得排序很慢。這里總結出來一個經驗，就是看explain首先要關注Using temporary，其次是Using filesort的問題。

要使ORDER BY的欄位走索引，則需要讓欄位所在的表成為驅動表
https://blog.csdn.net/zerou8400/article/details/95389044

最終的解決方案，在order by的欄位建立索引，並且使用straight_join，強制指定wkt_course為驅動表
SELECT
lu.userId,
lu.userName,
lu.photo userImage,
lu.sex,
wc.typeId AS courseType,
wc.name AS courseName,
lc.className,
DATE_FORMAT(wcu.CreatedTime, '%Y-%m-%d %H:%i:%s') AS time
FROM
wkt_course wc
straight_join wkt_courseclassuser wcu ON wcu.courseId = wc.id
INNER JOIN lxx_user lu ON wcu.userId = lu.userId
INNER JOIN lxx_registerschool lr on lr.schoolKey = lu.schoolKey
INNER JOIN (select t.* from (select * from lxx_classuserrecord WHERE classtypeid =1 ORDER BY CreateTime desc) t GROUP BY t.userid ) lcur ON lcur.userid = lu.userId
INNER JOIN lxx_class lc on lc.classId = lcur.classId
WHERE lr.schoolId = 60800000000000001
and wc.typeId in (1,2,3,23)
and lc.status = 1 and lc.typeId = 1
ORDER BY wc.CreateTime DESC
LIMIT 100;

圍觀一下優化後的執行計劃
mysql> explain SELECT
-> lu.userId,
-> lu.userName,
-> lu.photo userImage,
-> lu.sex,
-> wc.typeId AS courseType,
-> wc.name AS courseName,
-> lc.className,
-> DATE_FORMAT(wcu.CreatedTime, '%Y-%m-%d %H:%i:%s') AS time
-> FROM
-> wkt_course wc
-> straight_join wkt_courseclassuser wcu ON wcu.courseId = wc.id
-> INNER JOIN lxx_user lu ON wcu.userId = lu.userId
-> INNER JOIN lxx_registerschool lr on lr.schoolKey = lu.schoolKey
-> INNER JOIN (select t.* from (select * from lxx_classuserrecord WHERE classtypeid =1 ORDER BY CreateTime desc) t GROUP BY t.userid ) lcur ON lcur.userid = lu.userId
-> INNER JOIN lxx_class lc on lc.classId = lcur.classId
-> WHERE lr.schoolId = 60800000000000001
-> and wc.typeId in (1,2,3,23)
-> and lc.status = 1 and lc.typeId = 1
-> ORDER BY wc.CreateTime DESC
-> LIMIT 100;
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+------------------------------------+---------+-----------------------+-------+---------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+------------------------------------+---------+-----------------------+-------+---------------------------------+
| 1 | PRIMARY | wc | index | PRIMARY | index_wkt_course_CreateTime | 6 | NULL | 1 | Using where |
| 1 | PRIMARY | lr | ref | lxx_registerSchool_schoolId | lxx_registerSchool_schoolId | 9 | const | 1 | NULL |
| 1 | PRIMARY | wcu | ref | index_wkt_courseclassuser_courseId,index_wkt_courseclassuser_userId,index_wkt_courseclassuser_courseId_classId | index_wkt_courseclassuser_courseId | 9 | wkt_school.wc.id | 31 | Using where |
| 1 | PRIMARY | lu | eq_ref | PRIMARY,index_lxx_user_schoolKey | PRIMARY | 8 | wkt_school.wcu.userId | 1 | Using where |
| 1 | PRIMARY | <derived2> | ref | <auto_key1> | <auto_key1> | 8 | wkt_school.wcu.userId | 15 | Using where |
| 1 | PRIMARY | lc | eq_ref | PRIMARY | PRIMARY | 8 | lcur.classid | 1 | Using where |
| 2 | DERIVED | <derived3> | ALL | NULL | NULL | NULL | NULL | 36487 | Using temporary; Using filesort |
| 3 | DERIVED | lxx_classuserrecord | ALL | NULL | NULL | NULL | NULL | 36487 | Using where; Using filesort |
+----+-------------+---------------------+--------+----------------------------------------------------------------------------------------------------------------+------------------------------------+---------+-----------------------+-------+---------------------------------+

https://blog.csdn.net/m0_37894254/article/details/80675733

❸ ms sql server查詢優化方法 查詢速度慢的原因很多，常見如下幾種 1，沒有索引或者沒

1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是程序設計的缺陷)
2、I/O吞吐量小，形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網路速度慢
6、查詢出的數據量過大（可以採用多次查詢，其他的方法降低數據量）
7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設計的缺陷)
8、sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優化

❹ SQL資料庫優化的方法有哪些

在進行軟體開發過程中，資料庫的使用是非常重要的，但是資料庫有很多種，不同資料庫的使用方法是不同殲運的。進行軟體開發過程中，至少需要掌握一種資料庫的使用方氏雀梁法。SQL資料庫語法簡單、操作方便和高效，是很多人最優的選擇，但是SQL語句會受到不同資料庫功能的影響，在計算時間和語言的效率上面需要進行優化，根據實際情況進行調整。下面電腦培訓為大家介紹SQL資料庫的優化方法。


一、適當的索引

索引基本上是一種數據結構，有助於加速整個數據檢索過程。歲頌唯一索引是創建不重疊的數據列的索引。正確的索引可以更快地訪問資料庫，但是索引太多或沒有索引會導致錯誤的結果。IT培訓認為如果沒有索引，處理速度會變得非常慢。

二、僅索引相關數據

指定需要檢索數據的精度。使用命令*和LIMIT代替SELECT*。調整資料庫時，必須使用所需的數據集而不是整個數據集，尤其是當數據源非常大時，指定所需的數據集，能夠節省大部分時間。

三、根據需求使用或避免臨時表

如果代碼可以用簡單的方式編寫，那麼永遠不要使臨時表變得復雜。當然，如果數據具有需要多個查詢的特定程序，北大青鳥建議在這種情況下，使用臨時表。臨時表通常由子查詢交替。

四、避免編碼循環

避免編碼循環是非常重要的，因為它會減慢整個序列的速度。通過使用具有單行的唯一UPDATE或INSERT命令來避免編碼循環，並且北京北大青鳥發現WHERE命令能夠確保存儲的數據不被更新，這樣能夠方便在找到匹配和預先存在的數據時被找到。


❺ 如何查找MySQL中查詢慢的SQL語句

這是一個慢查詢日誌的展示工具，能夠幫助 DBA 或者開發人員分析資料庫的性能問題，給出全面的數據擺脫直接查看 slow-log。QAN（Query Analytics）

PMM 目前有 2 個版本，但是對於 QAN 來說其大致由三部分組成：

QAN-Agent（client）：負責採集 slow-log 的數據並上報到服務端

QAN-API（server）：負責存儲採集的數據，並對外提供查詢介面

QAN-APP：專門用來展示慢查詢數據的 grafana 第三方插件


1. 數據流轉

slow-log --> QAN-Agent --> QAN-API <--> QAN-APP（grafana）

2. pmm1 架構圖

❻ 如何查看哪些sql執行效率慢的

在點擊某個按鈕,執行完後,再執行下面語句,就可以知道系統運行什麼Sql和多物早少次了,其主要慢語句是那些了;

--先清除sql server的緩存dbcc freeProcCache SELECT creation_time N'語句編譯時間' ,last_execution_time N'上次執行時間' ,total_physical_reads N'物理讀取總次數' ,total_logical_reads/execution_count N'每次邏輯讀次數' ,total_logical_reads N'邏輯讀取總次數' ,total_logical_writes N'邏輯寫入總次數' ,execution_count N'執行次數' ,total_worker_time/1000 N'所用的CPU總時間ms' ,total_elapsed_time/1000 N'總花臘螞旦費時間ms' ,(total_elapsed_time / execution_count)/1000 N'平均時間ms' ,SUBSTRING(st.text, (qs.statement_start_offset/2) + 1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) N'執行語句'FROM sys.dm_exec_query_stats AS qsCROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) stwhere SUBSTRING(st.text, (qs.statement_start_offset/輪擾2) + 1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) not like '%fetch%'ORDER BY total_elapsed_time / execution_count DESC;

❼ 如何在mysql查找效率慢的SQL語句

  • 查看慢SQL是否啟用，查看命令：show variables like 'log_slow_queries';

    如果結果為ON則是開啟了，如果為OFF則表示禁用了。

  • 開啟慢查詢命令：set global log_slow_queries = on;

  • 查看是否開啟：show variables like 'log_slow_queries';

  • 查看慢查詢參數，即設置超過多少秒的查詢歸為了慢查詢。參數為：long_query_time，查詢命令：showglobal variables like 'long_query_time';

    mysql默認時間為10秒，即10秒及以上的查詢被歸為了慢查詢。我們的實際項目中根本就不可能這么包容你，所以得提供查詢效率優化sql，讓程序更快的執行。

  • 這里設置時間為1秒，即超過1秒就會被認為慢查詢。設置命令：set global long_query_time =1;用命令設置的，會立即生效，不用重啟mysql服務。但重啟mysql服務後就會失效。

  • 查看設置的時間，show global variables like 'long_query_time';即可看到現在已經變為1秒了

  • 查看慢查詢存放日誌，命令：show variables like 'slow_query_log_file';

    去相應目錄下查看即可。

❽ SQL Server中，存儲過程執行速度比較慢，有優化的方案嗎

主要有兩種方法
1、優化SQL的邏輯，使得邏輯越簡單越好。
2、使用到的表結構要建索引

閱讀全文

與慢sql有哪些相關的內容

本站內容整理源於互聯網，如有問題請聯系解決。
Copyright design: www.gotrillian.com since 2022