哪位大神帮忙分析下

select AKB020,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,AKA163 from kc22 where akb020 = :"SYS_B_0"and akc190 = :"SYS_B_1" and aae100 = :"SYS_B_2"
在pl/sql中秒出结果，在程序中死活通不过。

解决方案 »

  1.   

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

  2.   

    要不你将这一段转成占位符试试看：
    where akb020 = :"SYS_B_0"and akc190 = :"SYS_B_1" and aae100 = :"SYS_B_2"
    改成：where akb020 =  ? and akc190 = ? and aae100 = ?
      

  3.   

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

  4.   


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

  5.   


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

  6.   


    如果不想加提示，其实可以通过sql profile来做类似的实现。