㈠ sql 因為某一個查詢條件，速度變得很慢，怎麼解決
LodingType設置成char（1）
sql 查詢 把能排除大量條數的放在最後面 執行是從最後面執行的
and (selldelete is null or selldelete = 0) and AuditState!= 99 sql 排除之後是不是都是LodingType= 5了 如果是可能你的速度回變慢 參考2
㈡ SQL Server 2005 某個表中，其中一列存儲的值比較多， 第一次查詢很慢，怎麼解決
查詢語句可以優化一下
SELECT Tem_Detail
FROM Core_Flow_Approve_InstanceFlow
WHERE Tem_Detail != '' AND Instance_ID = ''
SQL語句過濾條件是從右到左的，
有兩個條件如果有一千條數據，第一條件要比較1000次（索引除外）。
第一條件濾過了900，第二條件比較就只比較100：總比較次數就是1100.
如果第一條件過濾100，第二條件比較900次，總次數就是1900了！
㈢ 如何能縮短sql語句的執行時間
1. SQL優化的原則是：將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。
調整不良SQL通常可以從以下幾點切入：
? 檢查不良的SQL，考慮其寫法是否還有可優化內容
? 檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫
? 檢查優化索引的使用
? 考慮資料庫的優化器
2. 避免出現SELECT * FROM table 語句，要明確查出的欄位。
3. 在一個SQL語句中，如果一個where條件過濾的資料庫記錄越多，定位越准確，則該where條件越應該前移。
4. 查詢時盡可能使用索引覆蓋。即對SELECT的欄位建立復合索引，這樣查詢時只進行索引掃描，不讀取數據塊。
5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT （*）和select top 1 語句。
6. 使用內層限定原則，在拼寫SQL語句時，將查詢條件分解、分類，並盡量在SQL語句的最里層進行限定，以減少數據的處理量。
7. 應絕對避免在order by子句中使用表達式。
8. 如果需要從關聯表讀數據，關聯的表一般不要超過7個。
9. 小心使用 IN 和 OR，需要注意In集合中的數據量。建議集合中的數據不超過200個。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，這樣可以有效的利用索引。
11. 在查詢時盡量減少對多餘數據的讀取包括多餘的列與多餘的行。
12. 對於復合索引要注意，例如在建立復合索引時列的順序是F1，F2，F3，則在where或order by子句中這些欄位出現的順序要與建立索引時的欄位順序一致，且必須包含第一列。只能是F1或F1，F2或F1，F2，F3。否則不會用到該索引。
13. 多表關聯查詢時，寫法必須遵循以下原則，這樣做有利於建立索引，提高查詢效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值條件（=）) and (table1的非等值條件) and (table2與table1的關聯條件) and (table2的等值條件) and (table2的非等值條件) and (table3與table2的關聯條件) and (table3的等值條件) and (table3的非等值條件)。
注:關於多表查詢時from 後面表的出現順序對效率的影響還有待研究。
14. 子查詢問題。對於能用連接方式或者視圖方式實現的功能，不要用子查詢。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。應該用如下語句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免對列的四則運算，特別是where 條件的左邊，嚴禁使用運算與函數對列進行處理。比如有些地方 substring 可以用like代替。
16. 如果在語句中有not in（in）操作，應考慮用not exists（exists）來重寫,最好的辦法是使用外連接實現。
17. 對一個業務過程的處理，應該使事物的開始與結束之間的時間間隔越短越好，原則上做到資料庫的讀操作在前面完成，資料庫寫操作在後面完成，避免交叉。
18. 請小心不要對過多的列使用列函數和order by,group by等，謹慎使用disti軟體開發t。
19. 用union all 代替 union，資料庫執行union操作，首先先分別執行union兩端的查詢，將其放在臨時表中，然後在對其進行排序，過濾重復的記錄。
當已知的業務邏輯決定query A和query B中不會有重復記錄時，應該用union all代替union，以提高查詢效率。
數據更新的效率
1. 在一個事物中，對同一個表的多個insert語句應該集中在一起執行。
2. 在一個業務過程中，盡量的使insert,update,delete語句在業務結束前執行，以減少死鎖的可能性。
資料庫物理規劃的效率
為了避免I/O的沖突，我們在設計資料庫物理規劃時應該遵循幾條基本的原則(以ORACLE舉例)：
?? table和index分離：table和index應該分別放在不同的tablespace中。
?? Rollback Segment的分離：Rollback Segment應該放在獨立的Tablespace中。
?? System Tablespace的分離：System Tablespace中不允許放置任何用戶的object。（mssql中primary filegroup中不允許放置任何用戶的object）
?? Temp Tablesace的分離：建立單獨的Temp Tablespace，並為每個user指定default Temp Tablespace
??避免碎片：但segment中出現大量的碎片時，會導致讀數據時需要訪問的block數量的增加。對經常發生DML操作的segemeng來說，碎片是不能完全避免的。所以，我們應該將經常做DML操作的表和很少發生變化的表分離在不同的Tablespace中。
當我們遵循了以上原則後，仍然發現有I/O沖突存在，我們可以用數據分離的方法來解決。
?? 連接Table的分離：在實際應用中經常做連接查詢的Table，可以將其分離在不同的Taclespace中，以減少I/O沖突。
?? 使用分區：對數據量很大的Table和Index使用分區，放在不同的Tablespace中。
在實際的物理存儲中，建議使用RAID。日誌文件應放在單獨的磁碟中。
㈣ 一條sql執行過長的時間，你如何優化，從哪些方面
1、查看sql是否涉及多表的聯表或者子查詢，如果有，看是否能進行業務拆分，相關欄位冗餘或者合並成臨時表（業務和演算法的優化）
2、涉及鏈表的查詢，是否能進行分表查詢，單表查詢之後的結果進行欄位整合
3、如果以上兩種都不能操作，非要鏈表查詢，那麼考慮對相對應的查詢條件做索引。加快查詢速度
4、針對數量大的表進行歷史表分離（如交易流水表）
5、資料庫主從分離，讀寫分離，降低讀寫針對同一表同時的壓力，至於主從同步，mysql有自帶的binlog實現 主從同步
6、explain分析sql語句，查看執行計劃，分析索引是否用上，分析掃描行數等等
7、查看mysql執行日誌，看看是否有其他方面的問題
個人理解：從根本上來說，查詢慢是佔用mysql內存比較多，那麼可以從這方面去酌手考慮
㈤ 在資料庫中查看一個SQL執行一次耗時多少
下面這種是SQL Server中比較簡單的查詢SQL語句執行時間方法源碼天空
，通過查詢前的時間和查詢後的時間差來計算的：
declare @begin_date datetime
declare @end_date datetime
select @begin_date = getdate()
select @end_date = getdate()
select datediff(ms,@begin_date,@end_date) as '用時/毫秒'
2：下面這種方法比較全面，將執行每個語句時採取的步驟作為行集返回，通過層次結構樹的形式展示出來
set statistics profile on
set statistics io on
set statistics time ongo
<這里寫上你的語句...go
set statistics profile off
㈥ 求sql 查詢語句加where 和 ORDER BY 後耗時優化
目測題主寫出的這幾條語句未發現特別消耗系統資源的運算，都是一些規范的寫法，可以說沒有什麼可以優化的，如果需要讓它們運行的更快一些應該從設置索引這個方向去解決。
最前兩條語句無篩選、用欄位`houseid`排序運算，毫秒級耗時都非常快，該欄位應該建立了索引並被利用。
語句1. 用欄位infocat=1進行篩選，盡管還是用欄位`houseid`排序運算，但是耗時立即增加到數百毫秒級，顯然欄位`infocat`沒有可被利用的索引。建議為欄位infocat添加索引，這樣相信此語句的運行速度會大幅提高。
語句2. 用欄位`edittime`排序，無篩選，耗時較用欄位`houseid`排序的耗時從毫秒級大幅增加到3百多毫秒，顯然欄位`edittime`也無可利用的索引。如為此欄位添加索引，此語句的運行速度可提高一個數量級。
語句3跟語句1.情況一樣，如果欄位`infocat`有索引，其運行速度可大幅提高。如果篩選後返回的行特別多，那麼再為欄位`edittime`加索引可為提高運行速度加分（篩選後如返回的行數目有限，則欄位`edittime`有無索引對提高速度幫助作用不大）。
㈦ sql 中按照時間段查詢速度很慢 怎麼解決
1. 增加索引對於時間（非聚族）
2.少用BETWEEN AND 寧可>= <=
3，時間存2011-02-02 這類格式，別存小時啊，分鍾啊秒鍾之類的就快了