❶ 開發中，sql語句優化有哪些方法
看你資料庫類型和框架是否支持。
一般開發中遇到慢SQL存在3個問題（索引健全的情況下）。
數據量多導致總行數慢，因為數據在不歸檔、遷移、轉總賬的情況下會不斷積壓。許可權越高看見的數據量就越大，數據量越大總行數就越高。一般框架是以分頁的SQL為基礎計算總行數的。這樣就會導致掃描行數高物理讀高查詢速度慢。優化方案就是總行數進行狀態歸檔，以歸檔+實時的方式展現出來
連表超過多，部分數據表是單獨的，但是不同部門的數據又有關聯性，領導要看全生命周期或者流程數據的情況下必須多表相連。這樣由於N個明細表導致笛卡兒積先不說，邏輯復雜連表多會消耗CPU，哪怕你查詢能500毫秒內顯示但是如果多人同時查就讓CPU超100%甚至做成鎖等待等堵塞。這個情況就是要用類似「雲計算」的分布式計算。通過觸發器、存儲過程等規定時間內吧業務表數據計算好並寫到展示表中，直接通過展示表進行關聯，這樣鎖表也於業務表無關，關聯表也能變少達到減少CPU消耗的目的。
iops與cpu佔比高導致資料庫癱瘓。第2點看出如果CPU高資料庫全SQL都會慢，IOPS也一樣。SQL慢會導致事務中的查詢慢，解放事務變慢了其他查詢就會鎖等待狀態變成堵塞。所以遇到大規模的查詢是否先查主鍵然後通過游標一個一個計算再進臨時表。這個是消耗時間和內存換CPU和IOPS的一個例子。反正伺服器資源最高怎樣開發應該是了解的，如何管制資源之間的平衡這個很重要。
舉個例子，部分MYSQL框架喜歡一次性把資料庫都導出來，然後減少子查詢，這個演算法針對有效的基礎數據這樣是可行的。針對業務數據應該沒人會用，但是基礎數據中也可能會存在海量的情況，比如坐標軌跡、省市區、電話號碼歸屬等。如果無腦應用這個框架會導致查詢起來很慢。
❷ SQL資料庫優化的方法有哪些
在進行軟體開發過程中，資料庫的使用是非常重要的，但是資料庫有很多種，不同資料庫的使用方法是不同的。進行軟體開發過程中，至少需要掌握一種資料庫的使用方法。SQL資料庫語法簡單、操作方便和高效，是很多人最優的選擇，但是SQL語句會受到不同資料庫功能的影響，在計算時間和語言的效率上面需要進行優化，根據實際情況進行調整。下面電腦培訓為大家介紹SQL資料庫的優化方法。
一、適當的索引
索引基本上是一種數據結構，有助於加速整個數據檢索過程。唯一索引是創建不重疊的數據列的索引。正確的索引可以更快地訪問資料庫，但是索引太多或沒有索引會導致錯誤的結果。IT培訓認為如果沒有索引，處理速度會變得非常慢。
二、僅索引相關數據
指定需要檢索數據的精度。使用命令*和LIMIT代替SELECT*。調整資料庫時，必須使用所需的數據集而不是整個數據集，尤其是當數據源非常大時，指定所需的數據集，能夠節省大部分時間。
三、根據需求使用或避免臨時表
如果代碼可以用簡單的方式編寫，那麼永遠不要使臨時表變得復雜。當然，如果數據具有需要多個查詢的特定程序，北大青鳥建議在這種情況下，使用臨時表。臨時表通常由子查詢交替。
四、避免編碼循環
避免編碼循環是非常重要的，因為它會減慢整個序列的速度。通過使用具有單行的唯一UPDATE或INSERT命令來避免編碼循環，並且昆明北大青鳥發現WHERE命令能夠確保存儲的數據不被更新，這樣能夠方便在找到匹配和預先存在的數據時被找到。
❸ 如何優化慢查詢的SQL語句
優化方法一般從幾個方面這幾個考慮：
1、根據業務情況，精簡代碼邏輯，
2、根據讀寫方式，降低數據表讀寫量
3、關鍵條件列增加合適的索引
4、對於碎片多的索引進行重建
多數情況下只需要考慮前兩條就能解決很大的效率問題，業務模式可能在最初開發的時候，因需求分析不徹底，或者需求理解不深入，導致邏輯不合理，或者後續多次變動業務模式，新增功能與最初的開發理念發生變化，這時就應該對代碼的邏輯進行重新優化改寫。
❹ 如何進行SQL性能優化
這里分享下mysql優化的幾種方法。
1、首先在打開的軟體中，需要分別為每一個表創建 InnoDB FILE的文件。
❺ 復雜慢sql語句如何優化
很簡單啊，優先索引，第二結構，第三演算法。
索引最簡單，如果是SQL server客戶端或者toad可以提示有哪些需要進行優化的地方。
結構就是針對要查詢的值，盡量集中到一個表，減少串表，函數查詢，左鏈的表欄位查詢。
演算法就是OR還是IN？串表時IN還是EXISTS ？oracle in 的限制。條件執行順序等。
然後還有其他注意的，例如只查固定欄位就不要 select * 只要注意以上步驟，千萬級數據串10個秒也能1秒內顯示出來。
有條件的話，當然是用歸檔數據進行查詢，這樣就不會佔用業務數據IO了，最後一步就是「雲計算」（解析有一百種，沒有統一概念，我的意識其實就是歸檔過程中根據分組維度計算好，並根據日期放進相關的表，減少表粒度，只進行簡單的select查詢）
❻ 列舉sql優化有哪些方式
sql優化的方式有：
1、選擇最有效率的表名順序(只在基於規則的優化器中有效)：
ORACLE 的解析器按照從右到左的順序處理FROM子句中的表名，FROM子句中寫在最後的表(基礎表 driving table)將被最先處理，在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎表。如果有3個以上的表連接查詢, 那就需要選擇交叉表(intersection table)作為基礎表, 交叉表是指那個被其他表所引用的表。
2、WHERE子句中的連接順序：
ORACLE採用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾。
3、SELECT子句中避免使用 『 * 『：
ORACLE在解析的過程中, 會將'*' 依次轉換成所有的列名, 這個工作是通過查詢數據字典完成的, 這意味著將耗費更多的時間 。
4、 減少訪問資料庫的次數：
ORACLE在內部執行了許多工作: 解析SQL語句, 估算索引的利用率, 綁定變數 , 讀數據塊等。
5、 在SQL*Plus , SQL*Forms和Pro*C中重新設置ARRAYSIZE參數, 可以增加每次資料庫訪問的檢索數據量 ,建議值為200 。
6、 使用DECODE函數來減少處理時間：
使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表。
7、整合簡單,無關聯的資料庫訪問：
如果你有幾個簡單的資料庫查詢語句,你可以把它們整合到一個查詢中(即使它們之間沒有關系)。
❼ 查詢特別慢 如何優化SQL
思路：
首先，要確定使用的是什麼數據，
若是MSSQL，那麼需要看一下查詢計劃，然後逐一解決慢的問題；
若是Access，那麼就要看錶的索引創建是否合適，另外Access還有一個弊病，就是資料庫大於10MB後，速度和性能將極大的下降
❽ 慢sql治理經典案例分享
作者 | 如期
來源 | 阿里技術公眾號
菜鳥供應鏈金融慢sql治理已經有一段時間，自己負責的應用持續很長時間沒有慢sql告警，現階段在推進組內其他成員治理應用慢sql。這里把治理過程中的一些實踐拿出來分享下。
在分頁查詢治理的文章里已經介紹過我們系統舊的分頁查詢邏輯，上面的查詢sql明顯就是分頁查詢獲取總記錄數，通過XXX_rules表的分頁查詢介面溯源，找到發起調用的頁面是我們小二後台的一個操作商家准入的頁面，頁面打開後直接調用分頁查詢介面，除了分頁參數，不傳入其他任何查詢參數，導致掃描全表。
靈魂拷問：為什麼要掃描全表？全表數據展示到頁面，花里胡哨的數據有用嗎？
調研：和經常使用這個頁面的運營聊後了解到，打開頁面查詢出的全表數據對運營是沒有用的，他們根本不看這些數據。運營的操作習慣是拿到商家id，在頁面查詢框中輸入商家id，查到商家數據後進行操作。
由此優化方案就很明朗了：打開頁面時不直接查詢全量數據，等運營輸入商家id後，將商家id作為參數進行查詢。XXX_rules表中，商家id這一常用查詢條件設置為索引，再結合分頁查詢優化，全表掃描慢sql得以解決。
優化後的小二後台頁面如下：
打開頁面時未查詢任何數據，查詢條件商家賬戶為必填項。
優化後的sql為:
執行EXPLAIN得到結果如下：
可以看到命中了索引，掃描行數為3，查詢速度明顯提高。
掃描全表治理簡單來說就是加入查詢條件，命中索引，去除全表掃描查詢，雖然有些粗暴，但並不是沒有道理。實際業務場景中，很少有要掃描全表獲取全部數據的情況，限制調用上游必須傳入查詢條件，且該查詢條件能命中索引，能很大程度上避免慢sql。
另外，再引申下，XXX_rules初始的用意是准入表，記錄金融貨主維度的准入情況，最多也就幾千條數據，但是很多同事將這張表理解為規則表，寫入很多業務相關規則，導致這個表膨脹到一百多萬條數據，表不clean了。這就涉及到數據表的設計使用，明確表的使用規范，不亂寫入數據，能給後期維護帶來很大的便利。
除了時間、操作人欄位，XXX_rules表就rule_name、rule_value、status、proct_code四個欄位，表的索引對這四個欄位做各種排列組合。存在如下問題：
1、rule_name離散度不高，放在索引首位不合適；
2、前三個索引重合度很高；
顯然是對索引的命中規則不夠了解。XXX_rules表很多業務有定時任務對其寫入刪除，索引多、混亂，對性能有很大的影響。
高性能的索引有哪些，再來回顧下：
1、獨立的列：索引列不能是表達式的一部分；
2、選擇區分度高的列作為索引；
3、選擇合適的索引列順序：將選擇性高的索引列放在最前列；
4、覆蓋索引：查詢的列均在索引中，不需要回查聚簇索引；
5、使用索引掃描來做排序;
6、在遵守最左前綴的原則下，盡量擴展索引，而不是創建索引。
但凡記得第3和6規則，也不至於把索引建成這樣。
對索引進行整合如下：
系統中有很多任務拉取整個產品下的准入記錄，然後進行處理，所以將區分度較高的proct_code放在索引首位，然後添加rule_name、status欄位到索引里，進一步過濾數據，減少掃描行數，避免慢sql。針對常用的rule_value查詢條件，可以命中UK，因此不用單獨建立索引。
很多業務邏輯中，需要拉取滿足某個條件的記錄列表，查詢的sql語句帶有order by，記錄比較多的情況，排序代價往往很大，但是查詢出來的記錄是否有序對業務邏輯沒有影響，比如分頁治理里討論的count語句，只需要統計條數，order by對條數沒有影響，再比如查出記錄列表後，不依賴記錄的順序遍歷列表處理數據，這時候order by多此一舉。
查詢sql無limit語句，且業務處理邏輯不依賴於order by後列表記錄的順序，則去除查詢sql中的order by語句。
業務中有很多定時任務，掃描某個表中某個產品下所有數據，對數據進行處理，比如：
三個查詢條件都是區分度不高的列，查出的數據有27W條，加索引意義也不大。
實際業務量沒那麼大，頂多幾千條數據，表裡的數據是從上游同步過來的，最好的辦法是讓上游精簡數據，但是由於業務太久遠，找上游的人維護難度太大，因此只能想其他的辦法。
這個定時任務目的是拉出XXX_rules表的某些產品下的數據，和另一張表數據對比，更新有差異的數據。每天凌晨處理，對時效性沒有很高的要求，因此，能不能轉移任務處理的地方，不在本應用機器上實時處理那麼多條數據？
數據是離線任務odps同步過來的，首先想到的就是dataWork數據處理平台。
建立數據對比任務，將定時任務做的數據對比邏輯放到dataWork上用sql實現，每天差異數據最多幾百條，且結果集含有區分度很高的列，將差異數據寫入odps表，再將數據迴流到idb。
新建定時任務，通過迴流回來的差異數據中區分度高的列作為查詢條件查詢XXX_rules，更新XXX_rules，解決了慢sql問題。
這個方法的前提是對數據實效性要求不高，且離線產出的結果集很小。
explain上述查詢語句，得到結果如下：
XXX_white_list表有將biz_id作為索引，這里查詢XXX_white_list表有傳入biz_id作為查詢條件，為啥explain結果里type為ALL，即掃描全表？索引失效了？索引失效有哪些情況？
索引失效場景
1、OR查詢左右有未命中索引的；
2、復合索引不滿足最左匹配原則；
3、Like以%開頭；
4、需要類型轉換；
5、where中索引列有運算；
6、where中索引列使用了函數；
7、如果mysql覺得全表掃描更快時（數據少時）
上述查詢語句第8行，customer_id為XXX_level_report表欄位，未命中XXX_white_list表索引，導致索引失效。
這個語句用condition、枚舉、join花里胡哨的代碼拼接起來的，改起來好麻煩，而且看起來「OR customer_id LIKE CONCAT(t.biz_id, '@%')」這句不能直接刪掉。最後重構了該部分的查詢語句，去除or查詢，解決了慢sql。
❾ 如何進行SQL性能優化
SQL Server資料庫查詢速度慢的原因有很多，常見的有以下幾種：
1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是資料庫設計的缺陷)
2、I/O吞吐量小，形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網路速度慢
6、查詢出的數據量過大（可以採用多次查詢，其他的方法降低數據量）
7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設計的缺陷)
8、sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優化
●可以通過以下方法來優化查詢 :
1、把數據、日誌、索引放到不同的I/O設備上，增加讀取速度，以前可以將Tempdb應放在RAID0上，SQL2000不在支持。數據量（尺寸）越大，提高I/O越重要。
2、縱向、橫向分割表，減少表的尺寸(sp_spaceuse)
3、升級硬體
4、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當（最好是使用默認值0）。索引應該盡量小，使用位元組數小的列建索引好（參照索引的創建）,不要對有限的幾個值的欄位建單一索引如性別欄位。
5、提高網速。
6、擴大伺服器的內存,Windows 2000和SQL server 2000能支持4-8G的內存。
配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置。運行 Microsoft SQL Server? 2000時，可考慮將虛擬內存大小設置為計算機中安裝的物理內存的1.5倍。如果另外安裝了全文檢索功能，並打算運行Microsoft搜索服務以便執行全文索引和查詢，可考慮：將虛擬內存大小配置為至少是計算機中安裝的物理內存的3倍。將SQL Server max server memory伺服器配置選項配置為物理內存的1.5倍（虛擬內存大小設置的一半）。
7、增加伺服器CPU個數;但是必須 明白並行處理串列處理更需要資源例如內存。使用並行還是串列程是MSSQL自動評估選擇的。單個任務分解成多個任務，就可以在處理器上運行。例如耽擱查詢 的排序、連接、掃描和GROUP BY字句同時執行，SQL SERVER根據系統的負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢最適合並行處理。但是更新操作UPDATE,INSERT， DELETE還不能並行處理。
8、如果是使用like進行查詢的話，簡單的使用index是不行的，但是全文索引，耗空間。 like ''a%'' 使用索引 like ''%a'' 不使用索引用 like ''%a%'' 查詢時，查詢耗時和欄位值總長度成正比,所以不能用CHAR類型，而是VARCHAR。對於欄位的值很長的建全文索引。
9、DB Server 和APPLication Server 分離；OLTP和OLAP分離
10、分布式分區視圖可用於實現資料庫伺服器聯合體。
聯合體是一組分開管理的伺服器，但它們相互協作分擔系統的處理負荷。這種通過分區數據形成資料庫伺服器聯合體的機制能夠擴大一組伺服器，以支持大型的多層 Web 站點的處理需要。有關更多信息，參見設計聯合資料庫伺服器。（參照SQL幫助文件''分區視圖''）
a、在實現分區視圖之前，必須先水平分區表
b、 在創建成員表後，在每個成員伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣，引用分布式分區視圖名的查詢可以在任何一個成員伺服器上 運行。系統操作如同每個成員伺服器上都有一個原始表的復本一樣，但其實每個伺服器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數據和日誌 DBCC SHRINKDB,DBCC SHRINKFILE. 設置自動收縮日誌.對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。
在T-sql的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計劃的過程是這樣的：
1、 查詢語句的詞法、語法檢查
2、 將語句提交給DBMS的查詢優化器
3、 優化器做代數優化和存取路徑的優化
4、 由預編譯模塊生成查詢規劃
5、 然後在合適的時間提交給系統處理執行
6、 最後將執行結果返回給用戶。
其次，看一下SQL SERVER的數據存放的結構：一個頁面的大小為8K(8060)位元組，8個頁面為一個盤區，按照B樹存放。