JAVA,Mybatis,Oracle變量類型與字段類型不一致、分區(qū)表全掃的優(yōu)化示例

這篇文章主要介紹JAVA,Mybatis,Oracle變量類型與字段類型不一致、分區(qū)表全掃的優(yōu)化示例，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

開發(fā)反應[增量庫存]功能慢，并反饋查詢有指定分區(qū)條件，量較小;

1）通過 Oracle DBA常用sql分享 (正在執(zhí)行的sql) 發(fā)現(xiàn)，該SQL的COST>1400000；

2）再通過select * from table(dbms_xplan.display_cursor( 'SQL_ID','0','advanced'));  分析該sql的執(zhí)行計劃和綁定變量情況發(fā)現(xiàn)

             PARTITION RANGE ALL 分區(qū)全掃；---->createtm分區(qū)字段傳參數(shù)了 為啥會全掃？

                                               |

                            綁定變量中createtm分區(qū)條件未顯示有傳值 

                                               |

 分區(qū)條件createtm 部分有【INTERNAL_FUNCTION 隱含轉換函數(shù)】；---> 猜測 傳參類型和DB字段類型不一致導致分區(qū)表全掃；

                                               |

通過DBA_HIST_SQLBIND查到createtm分區(qū)條件傳參(2017/01/17 14:20:00 -2017/01/17 14:25:00),字段類型為timestamp，而createtm字段為date類型；

總結：

   開發(fā)在java層用的mybatis框架，把date類型字段轉換成timestamp類型【and createtm $gt:=#{params.begintm} and createtm $lt:#{params.endtm}】，出現(xiàn)INTERNAL_FUNCTION 隱含轉換,導致及時分區(qū)條件createtm傳分區(qū)條件也被識別成未傳變量，導致分區(qū)表全掃；

   優(yōu)化后 and createtm>= to_date(#{params.begintm},'yyyy-mm-dd hh34:mi:ss')  and createtm< to_date(#{params.endtm},'yyyy-mm-dd hh34:mi:ss')

    
--補充注意Java中的日期變量需要使用String來存儲.

以上是“JAVA,Mybatis,Oracle變量類型與字段類型不一致、分區(qū)表全掃的優(yōu)化示例”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關知識，歡迎關注億速云行業(yè)資訊頻道！