哪位大神帮忙分析下

显示全部楼层 · 2021-1-27 06:27:37

selectAKB020,AKC190,AKC220,AAE072,AKC515,AKA135,AAC001,AKC516,AKC221,AAE040,AKC222,AKC223,AKA063,AKA065,AKC224,AKA113,AKC225,AKC226,AKC227,AKC228,AKC334,AKA068,AKC253,AKA069,AAE073,AKA064,AKA070,AKA097,AKC229,AKA071,AKA072,AKC202,AKA073,AKA076,AKC201,AKC325,AKC125,AAE100,AKC301,AKC127,AKC347,AKC384,AKC378,AKC379,AKC380,AKC381,AKC382,AKC383,AAE011,AAE036,OAE001,OAE300,OAE301,AKA609,AKC319,AKC163,AKA231,BKC228,AKA163fromkc22whereakb020=:"SYS_B_0"andakc190=:"SYS_B_1"andaae100=:"SYS_B_2"

在pl/sql中秒出结果，在程序中死活通不过。
分 -->

千问 · 2021-1-27 06:27:37

程序中不能使用:"SYS_B_0"这种绑定变量。
而在PL/SQL中可以使用~

千问 · 2021-1-27 06:27:37

那这种情况怎么破？以前是在一个服务上不行，切到另一个服务上可以了。运行了几天又不行了。

千问 · 2021-1-27 06:27:37

要不你将这一段转成占位符试试看：
whereakb020=:"SYS_B_0"andakc190=:"SYS_B_1"andaae100=:"SYS_B_2"
改成：whereakb020=?andakc190=?andaae100=?

千问 · 2021-1-27 06:27:37

plsqldev所谓的秒出有可能是假象，在数据库中执行的时候，他们可能走的是不一样的路径，如果楼主说的“通不过”是性能问题，或者说俗话说的“卡”，那么建议获取执行计划之后再来讨论会比较好。
另外，从SQL本身来看，随着akb020、akc190、aae100三个条件的变化，有些可能会秒出，有些可能会卡，这和数据分布有关系，有些条件组合下在数据库层，你可能也无力回天了，但如果无论这三个条件的值如何变化，符合条件的数据量都比较小的话，那么这个SQL可能还是可以被优化的，这要看执行计划再做定夺。
有绑定变量的SQL真实的执行计划会比较难搞，有个相对方便点的方法（不过会遗漏谓词信息，也就是执行计划中的条件详细信息会看不到）：
1、通过文本匹配，从v$sql从获取该SQL的sql_id；
2、使用数据库服务器端的$ORACLE_HOME/rdbms/admin/awrsqrpt.sql，根据提示输入sql_id，或者该SQL真实的执行计划

千问 · 2021-1-27 06:27:37

引用2楼yukwxiey的回复:那这种情况怎么破？以前是在一个服务上不行，切到另一个服务上可以了。运行了几天又不行了。
如果程序一开始没问题，跑了几天有问题了，那就说明很可能是数据量的变化导致了性能的下降，如果不想获取执行计划，想碰碰运气来解决这样的问题，可以考虑最大的可能就是：SQL的执行计划走了表扫描了，你没有在三个条件上创建索引，可以试着在这三个字段上创建组合索引解决这种问题。

千问 · 2021-1-27 06:27:37

暂时解决了，加了强制索引，先凑合凑合吧。否则没法报销要引出民愤的

千问 · 2021-1-27 06:27:37

引用6楼yukwxiey的回复:暂时解决了，加了强制索引，先凑合凑合吧。否则没法报销要引出民愤的
如果三个条件的值不断变化，但是符合条件的数据量一直能稳定在一个比较小的量级，那么SQL中硬编码INDEX提示也是个可行且不错的方案。
另外我想了想，楼主你这种情况很可能是11g之后Oracle新引入的“cardinalityfeedback”（直译：基数反馈）功能导致的，该功能简单地讲就是Oracle会根据SQL之前执行得到的基数情况来自动更改SQL的执行计划，这个功能本意是好的，但在实际生产中，往往会捅了马蜂窝，好在，这个功能可以通过隐藏参数_optimizer_use_feedback来关闭。

千问 · 2021-1-27 06:27:37

引用6楼yukwxiey的回复:暂时解决了，加了强制索引，先凑合凑合吧。否则没法报销要引出民愤的
如果不想加提示，其实可以通过sqlprofile来做类似的实现。