oracle在视图中引用函数列变为复杂的视图，但如果视图中存在order by则会存在这种完全不同的情况。在性能优化的过程中，会遇到某些性能问题的重要原因由于错误的函数调用导致，即用户自定义函数被调用次数过多（有时会超过预期值的几个数量级）。所以在857次中有1次的调用是没必要的。oracle在SELECT和WHERE子句中，同样的函数单独起作用且不能被重复使用，这就死oracle调用的总数等于1

1、问题语句由两大部分组成，通过union all拼接，性能问题出现在第二部分。区别在于第二部分缺少第一部分的某些查询条件，第一部分偏向强选择性，第二部分偏向弱选择性。3、建议在关键表的被驱动列添加to_char()函数，避开使用索引嵌套查询，改为关键表的全表访问。执行计划改为问题表的全表扫描，问题得到改善。2、建议收集了主要表的统计信息，执行计划没有改变，问题没有改善。各分组语句单独执行的执行计

2、判断问题sql在达梦数据库中没有把with as 作为临时temp表使用，从执行计划看，主查询中做了表连接展开，with as内容存在多次查询的情况。失去了with as作为缓存查询的意义。尝试在with as ()中加入rownum>0，执行计划出现heap table缓存表。1、客户反馈，在with as内容中，Oracle和达梦两边SQL执行效率一致。1、正常达梦数据库with as 的

显示游标的方式避免了内存的滥用而不知的情况，但如果表是远程表，也会使得往返次数加倍。这意味着，适用于连接数量少且负载重条件下的数据迁移问题的完美解决方案，对有大量并发连接的情况可能并不是最优的。3、其中问题SQL与delete、insert select * from table这的类型语句有关，怀疑存在显著占用内存峰值的潜在危险。如果不做MAX_SESSION_MEMORY限制，是会存在单一会话