❶ 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 ...
格式。