❶ 如何解決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運行慢
這種問題很復雜的，一般是按照先軟後硬的原則 ，建議你 ：
1.排除系統上是否有病毒，關掉不使用的埠，安全補丁打全！，建立查詢的時候查看內存，CPU的使用情況.
2.經常查詢的表是否建立索引，SQL語句查詢的條件欄位是否建有索引，優化SQL查詢語句。
3.檢查網路是否正常。
4.機器硬體是否需要升級，例如：增加一根內存或使用配置更好的機器。
❸ 為什麼裝了高性能伺服器 sql還更慢
mysql,配置文件配不對的話，性能就是會反而降低。如果是sqlserver,你最好看看內存，還有網卡的配置，也許機器不慢，但是網卡慢也說不定。
SQL語言，是結構化查詢語言。SQL語言是一種資料庫查詢和程序設計語言，用於存取數據以及查詢、更新和管理關系資料庫系統，同時也是資料庫腳本文件的擴展名。
SQL語言是高級的非過程化編程語言，允許用戶在高層數據結構上工作。它不要求用戶指定對數據的存放方法，也不需要用戶了解具體的數據存放方式，所以具有完全不同底層結構的不同資料庫系統可以使用相同的結構化查詢語言作為數據輸入與管理的介面。SQL語言語句可以嵌套，這使他具有極大的靈活性和強大的功能。【感興趣的話點擊此處，了解一下】
小編建議可以到億萬克官網了解相關內容，隨著5G、AI、車聯網、工業物聯網等新興技術的持續落地，億萬克將持續走在創新第一線，不斷為客戶提供更加優質服務，為國家信息安全和新型數據中心建設保駕護航，助力國家碳中和碳達峰步入新篇章。
❹ SQL 語句執行很慢是怎麼回事
到這個數量級的全部更新，肯定會很慢。x0dx0a第一。你的記錄不一定在同一個partition，x0dx0a第二。不明白為什麼那麼多人建議你建索引，你建的索引越多，你的更新速度越慢，因為你更新記錄的同時，還有更新索引。x0dx0a第三。你必須知道更新速度慢的瓶頸在哪裡。是讀寫太多，還是內存不夠，還是CUP不夠快，然後對症下葯。x0dx0ax0dx0a下面介紹兩個簡單的辦法，也許有效：x0dx0a第一：x0dx0a把這個100W行的表縱向劈成兩個，用外鍵關系連接，一個裝小的，經常改變的數據比如ID,外鍵，狀態值，時間等，另一個裝大的，不經常改變的數據，比如很長的字元串，xml，text 等。x0dx0a這樣更新時操作小的這個表，可以大大節約內存和CPU 開銷，降低磁碟操作。x0dx0a壞處就是查詢時會慢些。 x0dx0a第二：x0dx0a把這100W行橫向切成很多個表，比如每個月的記錄裝在一個表裡，這樣每個表的記錄數可能只有幾萬，查詢，更新都會快很多。x0dx0a壞處是查詢，更新都不如原來好寫。
❺ sql運行緩慢怎麼排查
這種情況就要看數據表上是不是有好幾百萬條導致查詢慢的,如果是數據比較多的情況下,建議做分表這舊的數據遷到分表上,這樣可以提高查詢速度
❻ 復雜sql語句，查詢慢，一直顯示正在載入，求助
SQL語句如果聯合了多張表或頻繁使用多個函數進行查詢，確實會影響效率。需要優化的話，建議給查詢條件設置索引，索引能提高查詢速度；但是如果你的SQL語句需要復合查詢而且有很多運算的話，建議還是把一條SQL語句拆開成三四條來寫，雖然拆分來寫有點麻煩但是查詢響應速度明顯快好幾倍，不信你試試！