慢sql
Ⅰ sql語句執行太慢，怎麼優化
Try this:
select storage.prodcode, sum(case when billsale.prod_number is null then 0 else billsale.prod_number end) as '已銷售數量'
from storage left join billsale on billsale.prodcode=storage.prodcode
group by storage.prodcode
Ⅱ 復雜慢sql語句如何優化
很簡單啊，優先索引，第二結構，第三演算法。
索引最簡單，如果是SQL server客戶端或者toad可以提示有哪些需要進行優化的地方。
結構就是針對要查詢的值，盡量集中到一個表，減少串表，函數查詢，左鏈的表欄位查詢。
演算法就是OR還是IN？串表時IN還是EXISTS ？oracle in 的限制。條件執行順序等。
然後還有其他注意的，例如只查固定欄位就不要 select * 只要注意以上步驟，千萬級數據串10個秒也能1秒內顯示出來。
有條件的話，當然是用歸檔數據進行查詢，這樣就不會佔用業務數據IO了，最後一步就是「雲計算」（解析有一百種，沒有統一概念，我的意識其實就是歸檔過程中根據分組維度計算好，並根據日期放進相關的表，減少表粒度，只進行簡單的select查詢）
Ⅲ 如何優化慢查詢的SQL語句
優化方法一般從幾個方面這幾個考慮：
1、根據業務情況，精簡代碼邏輯，
2、根據讀寫方式，降低數據表讀寫量
3、關鍵條件列增加合適的索引
4、對於碎片多的索引進行重建
多數情況下只需要考慮前兩條就能解決很大的效率問題，業務模式可能在最初開發的時候，因需求分析不徹底，或者需求理解不深入，導致邏輯不合理，或者後續多次變動業務模式，新增功能與最初的開發理念發生變化，這時就應該對代碼的邏輯進行重新優化改寫。
Ⅳ sql server速度慢影響因素
首先應該確定是誰慢的，往往是程序處理方面的問題而不是資料庫的問題。
程序方面應該盡可能的減少數據查詢返回的內容，減少IO壓力，磁碟IO和網路IO是非常非常慢的。比如可以查詢返回ID，然後再根據ID一條一條的查詢具體內容，看似慢了，在數據量大的時候快很多
對於數據可以參照下面幾點
1、優化SQL語句，SQL語句對查詢速度影響最大的
2、對於經常查詢的欄位作索引。但是這樣會增加修改時的壓力
4、優化SQLServer，比如給其分配固定的內存，預先分配查詢內存，調整CPU使用率等。SQL Server 可以佔用幾乎所有Windows的內存，但是申請內存開銷很大。因此可以設定其使用固定大小內存，比如啟動就分配1G以上內存。
5、優化硬體資源，比如使用更高的伺服器或者硬碟，獨立安排資料庫的數據文件和索引文件，將數據文件分布於不同的物理硬碟上等等
6、考慮使用分布資料庫或者對大表進行拆分
Ⅳ 如何查找MySQL中查詢慢的SQL語句
你是指慢查詢日誌嗎？
在my.ini中加上下面兩句話
log-slow-queries = e:\mysql5.5\mysql_slow_query.log
long_query_time=10
前面一句是設置慢查詢日誌存放路徑，第二句是指多少秒以上算慢查詢，上面的語句，就是指10秒。然後show variables like '%slow%';就行了
Ⅵ 如何解決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. 增加索引對於時間（非聚族）
2.少用BETWEEN AND 寧可>= <=
3，時間存2011-02-02 這類格式，別存小時啊，分鍾啊秒鍾之類的就快了
Ⅷ 如何優化MySQL中查詢慢的SQL語句啊
MySQL查詢優化的5個好用方法
http://soft.chinabyte.com/database/254/11335754.shtml
原則上來說
在
FIND_IN_SET
typeid IN (35)
arcrank
加復合索引
在sortrank加索引
Ⅸ SQL為什麼慢
好長啊
你這些等號旁邊的欄位加索引沒
加索引能快不少