1. 一條查詢極為緩慢的sql語句，如何去優化呢
1、將查詢條件欄位簡歷index;
2、將盡可能篩選掉最大數據量的條件放到where條件最後面，因為sql執行時，where條件是由右往左執行。
3、盡可能少用like、in等函數
2. 如何進行SQL性能優化
這里分享下mysql優化的幾種方法。
1、首先在打開的軟體中，需要分別為每一個表創建 InnoDB FILE的文件。
3. 慢sql治理
什麼是慢sql？慢sql的定義，目前共識是rt>1S，當存在1s以上的sql，qps比較高（150）時候，大概率會發生線上問題
風險維度：
執行時間rt：執行時間超過1s
平均掃描行數:掃描行數過高則一般說明sql有優化空間
全表掃描：一般是由於沒有配置索引
平均返回行數：返回行數過高，對系統邏輯有一定的風險
索引覆蓋：當前sql不是最佳索引
索引知識：
查看錶索引：show index from table_name
查看sql語句影響行數：explain select * from user where phone=『xxx』
索引錯用：
1.類型隱士轉換
wrong： select * from user where phone=xxx
right： select * from user where phone=『xxx』
2.索引欄位使用函數或者運算
wrong： select * from user where Date(create_at)=『2019-12-12』
right：select * from user where create_at>『2019-12-12』 AND create_at<'2019-12-13'
3.謹慎使用OR，OR中只要有一個沒有索引，就會走全表掃描
select name from user where id=10 and sex=『男』，sex沒有索引，導致走全表
4.Like 正確使用，like 『%xxx』 |like 『%xxx%』，會讓索引失效，但可以使用like『xx%』
5.不應該使用select *，而是需要什麼查什麼
select name from user，當name有索引的時候，直接掃描索引，不需要再掃表，索引覆蓋
6.謹慎使用order by導致的內存排序
7.當搜索范圍很大時，mysql估計使用全表掃描要比索引快，則不適用索引
4. SQL資料庫優化的方法有哪些
在進行軟體開發過程中，資料庫的使用是非常重要的，但是資料庫有很多種，不同資料庫的使用方法是不同的。進行軟體開發過程中，至少需要掌握一種資料庫的使用方法。SQL資料庫語法簡單、操作方便和高效，是很多人最優的選擇，但是SQL語句會受到不同資料庫功能的影響，在計算時間和語言的效率上面需要進行優化，根據實際情況進行調整。下面電腦培訓為大家介紹SQL資料庫的優化方法。
一、適當的索引
索引基本上是一種數據結構，有助於加速整個數據檢索過程。唯一索引是創建不重疊的數據列的索引。正確的索引可以更快地訪問資料庫，但是索引太多或沒有索引會導致錯誤的結果。IT培訓認為如果沒有索引，處理速度會變得非常慢。
二、僅索引相關數據
指定需要檢索數據的精度。使用命令*和LIMIT代替SELECT*。調整資料庫時，必須使用所需的數據集而不是整個數據集，尤其是當數據源非常大時，指定所需的數據集，能夠節省大部分時間。
三、根據需求使用或避免臨時表
如果代碼可以用簡單的方式編寫，那麼永遠不要使臨時表變得復雜。當然，如果數據具有需要多個查詢的特定程序，北大青鳥建議在這種情況下，使用臨時表。臨時表通常由子查詢交替。
四、避免編碼循環
避免編碼循環是非常重要的，因為它會減慢整個序列的速度。通過使用具有單行的唯一UPDATE或INSERT命令來避免編碼循環，並且昆明北大青鳥發現WHERE命令能夠確保存儲的數據不被更新，這樣能夠方便在找到匹配和預先存在的數據時被找到。
5. 如何解決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 查詢的優化，添加更合適的索引可以避免性能問題：執行計劃使用索引並不意味著就能執行快。
6. 查詢特別慢 如何優化SQL
思路：
首先，要確定使用的是什麼數據，
若是MSSQL，那麼需要看一下查詢計劃，然後逐一解決慢的問題；
若是Access，那麼就要看錶的索引創建是否合適，另外Access還有一個弊病，就是資料庫大於10MB後，速度和性能將極大的下降
7. SQL優化之慢查詢
慢查詢，顧名思義，就是查詢慢的sql語句，是指mysql記錄所有執行超過long_query_time參數設定的時間閾值的SQL語句的日誌。該日誌能為SQL語句的優化帶來很好的幫助。默認情況下，慢查詢日誌是關閉的，要使用慢查詢日誌功能，首先要開啟慢查詢日誌功能。
配置了慢查詢後，它會記錄符合條件的SQL，包括：
通過下面命令查看下上面的配置：
設置完成後，通過 show VARIABLES like 'datadir'來查看數據文件存放的位置。日誌文件中的內容格式如下：
linux系統在mysql的bin目錄下執行
參數說明：
這個工具安裝起來比較復雜，非專業sql人員感覺沒必要玩~
8. 如何優化慢查詢的SQL語句
優化方法一般從幾個方面這幾個考慮：
1、根據業務情況，精簡代碼邏輯，
2、根據讀寫方式，降低數據表讀寫量
3、關鍵條件列增加合適的索引
4、對於碎片多的索引進行重建
多數情況下只需要考慮前兩條就能解決很大的效率問題，業務模式可能在最初開發的時候，因需求分析不徹底，或者需求理解不深入，導致邏輯不合理，或者後續多次變動業務模式，新增功能與最初的開發理念發生變化，這時就應該對代碼的邏輯進行重新優化改寫。
9. SQL語句執行起來真的很慢，請大家幫忙優化一下
先建立索引，索引名隨便起：
CREATE INDEX index_name ON COPTD(TD004);
CREATE INDEX index_name ON MOCTB(TD004);
CREATE INDEX index_name ON MOCTA(TD004);
insert into ZDIDAN(DD01,DD02,DD03) SELECT distinct TD004,SUM(TD08),'O' FROM COPTD,MOCTA,MOCTB where COPTD.TD004=MOCTA.TD004 and MOCTB.TD004=MOCTA.TD004 and COPTD.TD021 = 'Y' AND COPTD.TD016 = 'N' AND COPTD.TD008+COPTD.TD024-COPTD.TD009-COPTD.TD025 > 0 and TB001+TB002=TA001+TA002 and TA013='Y' AND TA011 < 'Y' AND TB004>TB005 GROUP BY COPTD.TD004;
10. 復雜慢sql語句如何優化
很簡單啊，優先索引，第二結構，第三演算法。
索引最簡單，如果是SQL server客戶端或者toad可以提示有哪些需要進行優化的地方。
結構就是針對要查詢的值，盡量集中到一個表，減少串表，函數查詢，左鏈的表欄位查詢。
演算法就是OR還是IN？串表時IN還是EXISTS ？oracle in 的限制。條件執行順序等。
然後還有其他注意的，例如只查固定欄位就不要 select * 只要注意以上步驟，千萬級數據串10個秒也能1秒內顯示出來。
有條件的話，當然是用歸檔數據進行查詢，這樣就不會佔用業務數據IO了，最後一步就是「雲計算」（解析有一百種，沒有統一概念，我的意識其實就是歸檔過程中根據分組維度計算好，並根據日期放進相關的表，減少表粒度，只進行簡單的select查詢）