‘壹’ oracle sql 查询我使用自已写的函数查询很快，加了函数做条件就很慢是为什么
慢是因为
对于 几十万条记录左右,
你那个 test(a) 函数, 需要执行 很多次， 每行执行一次， 然后判断 LIKE '%123%'
至于：
select a,b, test(a) c from demo; --只这样查很快
我估计你使用的是 PLSQL Developer。
查询的时候， 默认是查询第一页， 因此很快。
因为只显示少部分行。
例如一页20行的话， 那么也就执行你那个函数 20次。
‘贰’ oracle 查询语句 第一次执行很快，第二次执行就很慢 。是什么原因
oracle sql 第一次查询快， 以后查询慢
大多数情况下，用oracle， 第一次查询慢， 第二次查询肯定比第二次查询快对吧，
但对于这种情况，第一次查询快， 以后查询慢。
Cardinality Feedback基数反馈， 是版本11.2中引入的关于SQL 性能优化的新特性，该特性主要针对 统计信息陈旧、无直方图或虽然有直方图但仍基数计算不准确的情况， Cardinality基数的计算直接影响到后续的JOIN COST等重要的成本计算评估，造成CBO选择不当的执行计划。以上是Cardinality Feedback特性引入的初衷。
基数反馈多少也造成了一些麻烦，典型的情况是测试语句性能时，第一次的性能最好，之后再运行其性能变差。
如何禁用Cardinality Feedback基数反馈
对于这些”惹火”特性，为了stable，往往考虑关闭该特性。
可以通过多种方法禁用该特性
1. 使用 _optimizer_use_feedback 隐藏参数
session 级别
SQL> alter session set “_optimizer_use_feedback”=false;
会话已更改。
system级别
SQL> alter system set “_optimizer_use_feedback”=false;
系统已更改。
————————————————
原文链接：https://blog.csdn.net/demonson/article/details/80522150
‘叁’ Oracle 视图查询有的时候很慢,有的时候查询很快
这种情况有很多可能性，首先，你的服务器的负载情况会影响到你的数据读取速度的，如果数据库服务器执行的进程过多，会导致查询速度下降很多。
另外，第一次执行同一个SQL的时候，都会比较慢一些，再次执行的时候，由于数据等还在内存内，会速度快很多。
再者，在Oracle中，有共享SQL语句的机制，在第一次解析之后, ORACLE将SQL语句存放在内存中.这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享. 因此,当你执行一个SQL语句(有时被称为一个游标)时,如果它 和之前的执行过的语句完全相同, ORACLE就能很快获得已经被解析的语句以及最好的执行路径. 这样也会大大的提高效率。
‘肆’ oracle数据库约200W数据查询非常慢，查询需要10几秒，经常查询超时，这个正常吗有没有什么好的办法解决
先确认一下问题，是代码操作的查询还是连接oracle工具操作的查询，优化大数据量主要先从三两方式入手，第一，建索引，这个有讲究：主要是针于你的查询条件(即是在where后面的字段建索引，有几个条件字段就建几个，如果有组合条件查询，那建联合索引)。第二点，就是按表中的数据，进行表分区，如按时间段进行分区，按区域进行分区，按单位或部门进行分区等。减少全表扫描。三，检查一下表空间大少。
‘伍’ oracle数据库系统视图查询慢
PB连接数据库右键打开一张表的时候要刷新挺多数据的，需要读取一些系统表，获取对象数据结构信息，并且生成一个数据窗口展现数据。这个过程消耗时间。
检查一下如下几个情况：
1、使用的Oracle驱动是否版本匹配，例如：你使用Oracle8的驱动连接Oracle10的数据库，从访问的优化性来将，是有差别的，可能会影响效率；
2、把视图在PL/SQL工具中进行执行计划的查询，检查其性能是否有问题，例如：索引使用不当等情况；
3、程序编译之后执行一下看看，性能是否依旧较低？开发模式下，编译器没有针对性的优化，可能影响到效率。
从开发阶段就开始关注效率，这个是很好的习惯。希望我的回答能对你有帮助。
‘陆’ oracle 查询的sql语句特别慢，是什么原因，是or特别慢吗，用什么优化，急急急！！！
把查询计划的内容发出来，你这一大堆代码谁能看出来啥啊。看你的代码这么长，条件那么多，语句用了函数，很多低效的or,not in等操作，另外还用了group by，order by，左右连接等等，如果表数据量很大的话，你这个语句性能不好是预料中的事情。如果你这条语句无法优化，建议从调整表结构角度考虑
‘柒’ oracle数据库运行sql很卡很慢很顿，看等待事件都是cursor:pin s on x,这是啥
详解cursor: pin S wait on X等待事件 ‘cursor: pin * events’等待事件 该类等待事件一般是为了pin相关的子游标 ‘Cursor: pin S on X’ 最常见的等待事件， 进程为了共享操作例如执行pin游标而以SHRD S mode申请mutex， 但是未立即获得。原因是该游标被其他进程以EXCL X mode 持有了。 实际该 cursor: pin S wait on X等待事件往往是由于其他因素诱发的。Mutex争用仅仅是问题的症状，但根本原因需要Database Consultant 进一步挖掘。 下面我们列出一些已知的常见案例， 在这些例子中可以看到 我上面提到的 Mutex的争用仅仅是伪争用: 过多的子游标 High Version Counts 过多的子游标版本Version Count可能导致Mutex 争用，一般一个SQL的Version Count不要高于500。 检查High Version Count很简单， 在AWR里就有SQL ordered by High Version Count，也可以写SQL查V$SQL、V$SQLAREA 昂贵的X$、V$视图查询 一些对于V$、X$视图的查询，需要访问X$KGL*之类的fixed table，可能触发Mutex争用。 Mutex持有者得不到CPU Mutex持有者若得不到足够的CPU片可能一直阻塞他人，直到它拿到需要的CPU。 这种情况可能由于OS操作系统的实际情况或者使用Resource Manager而引起。需要配合AWR中的Host CPU、Instance CPu一起看。 已经被KILLED的SESSION仍持有Mutex 当session正持有Mutex，而其对应的Process被强制KILL掉， 则直到PMON彻底清理掉该Dead Process并释放Mutex，其他session才能不再等待。 诊断该类问题，最好能检查PMON的TRACE。 当然也存在部分BUG会导致PMON清理过程非常慢。 举例来说，bug 9312879描述了一种场景：PMON 需要获得某个Mutex以便清理某个dead process，但是该Mutex又被其他进程持有，则PMON甚至无法开始真正清理并释放Mutex。 如果自己搞不定可以找ASKMACLEAN专业ORACLE优化团队成员帮您搞定!