寻找准则设置正确的ResultSet类型PreparedStatement API

我们最近发现在prepareStatement(String sql, int resultSetType, int resultSetConcurrency)中使用resultSetType=TYPE_SCROLL_INSENSITIVE而不是默认的prepareStatement(String sql)会导致db2生成/使用不同的访问计划，这可能会导致显着不同的查询时间，大小/过滤范围/等。寻找准则设置正确的ResultSet类型PreparedStatement API

我们使用DB2 LUW V10.5 FP8。

想知道是否有任何关于如何选择此resultSetType属性的指导原则，在性能优化方面，对于DB2或其他一般的RDBMS？顺便说一句，我们不改变我们的ResultSet，所以我们允许使用*INSENSITIVE。

来源

2017-11-17 fall14123

不敏感并不需要'改变我们的ResultSet'（这就是'CONCUR_UPDATABLE'的意思），这意味着结果集不会被并发更改（对事务可见）更新。无论如何，如果你不需要滚动，那么'TYPE_FORWARD_ONLY'应该是你在JDBC中的默认值。这个评论纯粹来自JDBC角度，而不是DB2特定的。 –

谢谢马克。听起来就像从jdbc的角度来看，'TYPE_FORWARD_ONLY'与'TYPE_SCROLL_INSENSITIVE'只能指定功能，并且不会或至少不打算具有任何性能影响？它对我来说很重要，因为实现是供应商特定的，这带来了所有细微的细节，例如Charles提到的...... – fall14123

性能取决于实现，例如某些驱动程序通过缓存while结果集来实现（模拟）可滚动性在记忆中。 –

TYPE_SCROLL_INSENSITIVE

应小心使用，默认为ASENSITIVE。它允许Db2创建一个INSENSITIVE或SENSITIVE游标，具体取决于它认为最好的游标。

对于我至少有Db2，INSENSITIVE导致DB创建数据的副本。

来源

2017-11-17 22:21:26 Charles

谢谢查尔斯，这是一个很好的观点，我没有想到。对于我们的特定查询（从单个表中简单选择....），使用'TYPE_SCROLL_INSENSITIVE'的查询时间可以更短，'timeron'为200（使用'TYPE_SCROLL_INSENSITIVE'）与20,000（使用'TYPE_FORWARD_ONLY' ）..... 将尝试更多类似的查询，看看会发生什么。完全有可能我们只是遇到一个特例（又名bug？）...... – fall14123

在JDBC中没有'ASENSITIVE'这样的东西。 –

寻找准则设置正确的ResultSet类型PreparedStatement API

回答

相关问题