❶ oracle sql 用什麼代替or 這樣查詢特別慢
性能和這個關系不大吧，你看看是不是需要建索引。
❷ 使用sql server 2000 select 查詢中，使用的 OR 非常多時（500多人)，在100萬條以上數據時，很慢.
無法避免的
可以考慮把OR命中率高的放在OR的前面
也可以考慮建立視圖
create veiw axxx
as select * from tab where xxx = ? or xxx =?
然後通過view select
❸ oracle sql 用什麼可以替代or，這樣查詢特別慢
分別寫幾個查詢語句，然後用union all把幾個查詢聯起來。
❹ 如何解決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，or in 速度太慢了，就查出來一條數據10秒 ，急求。。
--你的SQL有問題吧？C.ResourceNTAccount='user1'or'user1'in應該改成C.ResourceNTAccount='user1'orC.ResourceNTAccountin
建議：子查詢SELECT
distinctB.ResourceNTAccount
FROM[ZhongJian].[dbo].[View_User_Group]A
leftjoinProjectServer_Reporting.dbo.MSP_EpmResource_UserViewBon
A.UserAccount=B.ResourceNTAccount
whereGroupName=N'項目副經理工作組'ANDB.資源所屬項目like'%'+C.項目所屬機構+'%'
中可不可以把最大化模糊匹配改成最右匹配或者直接改造成=，
方案一：
我觀察你的SQL，首先selectdistinctC.[項目所屬機構]AsProjectName,MIN(C.TaskBaseline0StartDate)asProjectStartDat中的distinct沒有必要寫，這樣會消耗一部分時間
selectC.[項目所屬機構]AsProjectName,MIN(C.TaskBaseline0StartDate)asProjectStartDate
fromView_TaskAllInfoCwhere(C.ResourceNTAccount='user1'orC.ResourceNTAccountin(
SELECT
distinctB.ResourceNTAccount
FROM[ZhongJian].[dbo].[View_User_Group]A
leftjoinProjectServer_Reporting.dbo.MSP_EpmResource_UserViewBon
A.UserAccount=B.ResourceNTAccount
whereGroupName=N'項目副經理工作組'ANDB.資源所屬項目like'%'+C.項目所屬機構+'%'
))
groupbyC.[項目所屬機構]
--方案一：
--若效果不佳，可以把整個SQL拆分兩個部分
selectselectdistinctC.[項目所屬機構]AsProjectName,MIN(C.TaskBaseline0StartDate)asProjectStartDate
from
(
selectdistinctC.[項目所屬機構]AsProjectName,MIN(C.TaskBaseline0StartDate)asProjectStartDate
fromView_TaskAllInfoCwhereC.ResourceNTAccount='user1'
unionall
selectdistinctC.[項目所屬機構]AsProjectName,MIN(C.TaskBaseline0StartDate)asProjectStartDate
fromView_TaskAllInfoCwhereC.ResourceNTAccountin
SELECT
distinctB.ResourceNTAccount
FROM[ZhongJian].[dbo].[View_User_Group]A
leftjoinProjectServer_Reporting.dbo.MSP_EpmResource_UserViewBon
A.UserAccount=B.ResourceNTAccount
whereGroupName=N'項目副經理工作組'ANDB.資源所屬項目like'%'+C.項目所屬機構+'%'
)ast
❻ sql or 效率超慢，那位大仙幫忙分析分析
看看有沒有走索引，語句沒有什麼優化了，如果數據多，這么多的sum, max全表掃描就慢了。
SELECT BB.AAZ010 AS RYBH,
MAX(BB.AAC003) AS RYMC,
MAX(BB.AAC004) AS AAC004,
MAX(BB.AAC006) AS AAC006,
MAX(BB.AAC084) AS AAC084,
MAX(BB.AAC002) AS AAC002,
MAX(BB.APE031) AS APE031,
COUNT(BB.AAZ010) AS WGS,
SUM(NVL(BB.APE735, 0)) AS QZZ,
MAX(BB.APA151) AS APA151
FROM (SELECT A.AAZ010 AS AAZ010,
MAX(A.APE031) AS APE031,
A.AAZ319 AS AAZ319,
MAX(C.AAC003) AS AAC003,
MAX(C.AAC004) AS AAC004,
MAX(C.AAC006) AS AAC006,
MAX(C.AAC084) AS AAC084,
MAX(C.AAC002) AS AAC002,
MAX(A.APE735) AS APE735,
MAX(C.APA151) AS APA151
FROM KA59 A, AC01 C
WHERE 1 = 1
AND A.AAZ010 = C.AAC001
AND A.APA709 = '1'
AND A.APE031 = '1'
AND (A.ABB057 BETWEEN TO_DATE('2012-05-01' || ' 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
TO_DATE('2012-07-11' || ' 23:59:59', 'yyyy-mm-dd hh24:mi:ss'))
AND (A.AAZ319 = '1000000000000010' AND A.AAA155 IN ('1'))
OR (A.AAZ319 = '1000000000000011' AND A.AAA155 IN ('1', '2'))
OR (A.AAZ319 = '1000000000000017' AND A.AAA155 IN ('1', '2', '3'))
GROUP BY A.AAZ010, A.AAZ319) BB
GROUP BY BB.AAZ010
ORDER BY QZZ DESC
❼ oracle sql 請問用什麼可以替代or，這樣查的效率特別慢
含有"IN"、"OR"的Where子句常會使用工作表，使索引失效；如果不產生大量重復值，可以考慮把子句拆開；拆開的子句中應該包含索引。
select count(*) from stuff where id_no in('0','1')（23秒）
可以考慮將or子句分開：
select count(*) from stuff where id_no='0'
select count(*) from stuff where id_no='1'
然後再做一個簡單的加法，與原來的SQL語句相比，查詢速度更快。
❽ oracle 查詢的sql語句特別慢，是什麼原因，是or特別慢嗎，用什麼優化，急急急！！！
把查詢計劃的內容發出來，你這一大堆代碼誰能看出來啥啊。看你的代碼這么長，條件那麼多，語句用了函數，很多低效的or,not in等操作，另外還用了group by，order by，左右連接等等，如果表數據量很大的話，你這個語句性能不好是預料中的事情。如果你這條語句無法優化，建議從調整表結構角度考慮
❾ sql 因為某一個查詢條件，速度變得很慢，怎麼解決
LodingType設置成char（1）
sql 查詢 把能排除大量條數的放在最後面 執行是從最後面執行的
and (selldelete is null or selldelete = 0) and AuditState!= 99 sql 排除之後是不是都是LodingType= 5了 如果是可能你的速度回變慢 參考2
❿ 優化sql 速度太慢 主要優化 or 求高手解決 急急急
最簡單的改法就是把那些子查詢提出來。
變成 select 。。。
from x inner join y on ...
inner join z on...
inner join w on ...
where ...
格式。