在不使用 PureQuery 的情况下对 DB2 执行静态 SQL 查询
我想在新应用程序中使用 JPA 而不是 JDBC。我严格使用 JPA 实体管理器的命名查询和基本 CRUD 方法，这允许我（在 Hibernate 或任何其他 JPA 实现的帮助下）提取将在数据库上执行的所有 SQL 本机查询。通过这个静态查询列表，我知道我可以构建一个 DB2 包，其中包含我的请求的所有执行计划。
所以我的问题是：通过 JDBC 对 DB2 执行这些查询是否会利用这些执行计划？据我所知，PureQuery产品可以捕获sql订单列表。它是否仍然通过 JDBC 而不是通过 PureQuery 特定 API 提供更多功能？这种特定的 DB2 静态绑定功能？或者它相当于 JDBC？
感谢您的任何答复。
I'd like to use JPA over JDBC for a new application. I'm strictly using Named queries and basic CRUD methods of JPA Entity manager, which allows me (with the help of Hibernate, or any other JPA implementation) to extract all SQL native queries that will be performed on the database. With this list of static queries, I understand that I can build a DB2 package that is all execution plans of my requests.
So my question is: Does performing those queries through JDBC against DB2 will take advantage of those execution plans, or not ? I understand that the PureQuery product can capture the list of sql orders. Does it, still through JDBC and not through PureQuery specific API, provide more ? such a specific DB2 static bind feature ? or it is equivalent to JDBC?
Thank you for any piece of answer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
JDBC 应用程序仅执行动态 SQL（即 DB2 不使用静态包）。
获取静态 SQL（查询存储在数据库中的包中）的方法只有两种：使用 SQLJ（消除了 JPA/Hibernate）编写应用程序或使用 pureQuery（位于 JDBC 和数据库之间）。
请记住，即使使用动态 SQL，DB2 也会缓存查询的执行计划，因此如果它们执行得足够频繁（即，它们保留在缓存中），那么您将不会看到查询编译的开销。仅当查询是逐字节精确匹配时缓存才有用，因此
select * from t1 where c1 = 1与select * from t1 where c1 = 2 不同，也不是select * from t1 where C1 = 1（它给出相同的结果，但查询不同）。使用参数标记（select * from t1 where c1 = ?）是关键。您的 DBA 可以调整目录缓存的大小，以帮助最大限度地提高该缓存的命中率。尽管缓存有助于避免重复编译查询，但它无法提供静态 SQL 所具有的计划稳定性，所以 YMMV。
JDBC applications execute dynamic SQL only (i.e. DB2 does not use static packages).
There are only 2 ways to get static SQL (where the queries are stored in a package in the database): Write your application using SQLJ (which eliminates JPA/Hibernate) or use pureQuery (which sits between JDBC and the database).
Keep in mind that even with dynamic SQL, DB2 does cache the execution plans for queries, so if they are executed frequently enough (i.e., they remain in the cache), then you won't see the overhead from query compilation. The cache is only useful if the queries are an exact byte-for-byte match, so
select * from t1 where c1 = 1is not the same asselect * from t1 where c1 = 2, nor isselect * from t1 where C1 = 1(which gives the same result, but the query differs). Using parameter markers (select * from t1 where c1 = ?) is key. Your DBA can tune the size of the catalog cache to help maximize the hit ratio on this cache.Although caching helps avoid repeatedly compiling a query, it does not offer the plan stability that static SQL does, so YMMV.