从 DUAL 中选择 1:MySQL
在查看我的查询日志时,我发现了一个奇怪的模式,但我无法解释。
几乎每次查询后,我都会“从 DUAL 中选择 1”。
我不知道这是从哪里来的,而且我当然没有明确地进行查询。
日志基本上是这样的:
10 Query SELECT some normal query
10 Query select 1 from DUAL
10 Query SELECT some normal query
10 Query select 1 from DUAL
10 Query SELECT some normal query
10 Query select 1 from DUAL
10 Query SELECT some normal query
10 Query select 1 from DUAL
10 Query SELECT some normal query
10 Query select 1 from DUAL
...etc...
以前有人遇到过这个问题吗?
MySQL 版本:5.0.51
驱动程序:使用 JDBC 的 Java 6 应用程序。 mysql-connector-java-5.1.6-bin.jar
连接池:commons-dbcp 1.2.2validationQuery
设置为“select 1 from DUAL”(显然),并且显然连接池在验证时默认 testOnBorrow 和 testOnReturn 为 true查询非空。
这给我带来的另一个问题是我是否真的需要进行验证查询,或者我是否可以通过禁用它或至少降低它的频率来提高性能用来。 不幸的是,编写我们的“数据库管理器”的开发人员已经不在我们身边,所以我不能要求他为我证明它的合理性。 任何意见将不胜感激。 我会深入研究 API 和谷歌一段时间,如果发现任何有价值的东西,我会报告回来。
编辑:添加了一些更多信息
编辑2:添加了正确答案中要求的信息,以便稍后找到此信息的人
In looking over my Query log, I see an odd pattern that I don't have an explanation for.
After practically every query, I have "select 1 from DUAL".
I have no idea where this is coming from, and I'm certainly not making the query explicitly.
The log basically looks like this:
10 Query SELECT some normal query
10 Query select 1 from DUAL
10 Query SELECT some normal query
10 Query select 1 from DUAL
10 Query SELECT some normal query
10 Query select 1 from DUAL
10 Query SELECT some normal query
10 Query select 1 from DUAL
10 Query SELECT some normal query
10 Query select 1 from DUAL
...etc...
Has anybody encountered this problem before?
MySQL Version: 5.0.51
Driver: Java 6 app using JDBC. mysql-connector-java-5.1.6-bin.jar
Connection Pool: commons-dbcp 1.2.2
The validationQuery was set to "select 1 from DUAL" (obviously) and apparently the connection pool defaults testOnBorrow and testOnReturn to true when a validation query is non-null.
One further question that this brings up for me is whether or not I actually need to have a validation query, or if I can maybe get a performance boost by disabling it or at least reducing the frequency with which it is used. Unfortunately, the developer who wrote our "database manager" is no longer with us, so I can't ask him to justify it for me. Any input would be appreciated. I'm gonna dig through the API and google for a while and report back if I find anything worthwhile.
EDIT: added some more info
EDIT2: Added info that was asked for in the correct answer for anybody who finds this later
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我已经执行了 100 次插入/删除,并在 DBCP 和 C3PO 上进行了测试。
DBCP :: testOnBorrow=true 对响应时间的影响超过 4 倍。
C3P0 :: testConnectionOnCheckout=true 对响应时间的影响超过 3 倍。
结果如下:
DBCP – BasicDataSource
100 个事务的平均时间(插入操作)
testOnBorrow=false::219.01 毫秒
testOnBorrow=true :: 1071.56 ms
100 个事务的平均时间(删除操作)
testOnBorrow=false::223.4 毫秒
testOnBorrow=true :: 1067.51 毫秒
C3PO – ComboPooledDataSource
100个事务的平均时间(插入操作)
testConnectionOnCheckout=false::220.08 毫秒
testConnectionOnCheckout=true :: 661.44 ms
100 个事务的平均时间(删除操作)
testConnectionOnCheckout=false::216.52 毫秒
testConnectionOnCheckout=true :: 648.29 ms
结论:在 DBCP 中设置 testOnBorrow=true 或在 C3PO 中设置 testConnectionOnCheckout=true 会将性能影响 3-4 倍。 是否有任何其他设置可以提高性能。
——杜尔加·普拉萨德
I have performed 100 inserts/deltes and tested on both DBCP and C3PO.
DBCP :: testOnBorrow=true impacts the response time by more than 4 folds.
C3P0 :: testConnectionOnCheckout=true impacts the response time by more than 3 folds.
Here are the results :
DBCP – BasicDataSource
Average time for 100 transactions ( insert operation )
testOnBorrow=false :: 219.01 ms
testOnBorrow=true :: 1071.56 ms
Average time for 100 transactions ( delete opration )
testOnBorrow=false :: 223.4 ms
testOnBorrow=true :: 1067.51 ms
C3PO – ComboPooledDataSource
Average time for 100 transactions ( insert operation )
testConnectionOnCheckout=false :: 220.08 ms
testConnectionOnCheckout=true :: 661.44 ms
Average time for 100 transactions ( delete opration )
testConnectionOnCheckout=false :: 216.52 ms
testConnectionOnCheckout=true :: 648.29 ms
Conculsion : Setting testOnBorrow=true in DBCP or testConnectionOnCheckout=true in C3PO impacts the performance by 3-4 folds. Is there any other setting that will enhance the performance.
-Durga Prasad
“双重”表/对象名称是 Oracle 的一种构造,MySQL 支持这种构造是为了实现兼容性,或者为没有目标但人们希望感觉温暖而模糊的查询提供目标。 例如,
可能
有人会嗅探您以查看您是否正在运行 Oracle。
The "dual" table/object name is an Oracle construct, which MySQL supports for compatibility - or to provide a target for queries that dont have a target but people want one to feel all warm and fuzzy. E.g.
can be
Someone could be sniffing you to see if you're running Oracle.
它可能来自您的应用程序正在使用的连接池。 我们使用一个简单的查询来测试连接。
刚刚快速浏览了 mysql-connector-j 的源代码,它不是来自那里。
最可能的原因是连接池。
公共连接池:
commons-dbcp有一个配置属性
validationQuery
,这与testOnBorrow
和testOnReturn
结合可能会导致你看到的陈述。c3p0 有
preferredTestQuery
、testConnectionOnCheckin
、testConnectionOnCheckout
和idleConnectionTestPeriod
对于我倾向于的价值配置连接测试和签出/借用,即使这意味着一些额外的网络干扰。
It could be coming from the connection pool your application is using. We use a simple query to test the connection.
Just had a quick look in the source to mysql-connector-j and it isn't coming from in there.
The most likely cause is the connection pool.
Common connection pools:
commons-dbcp has a configuration property
validationQuery
, this combined withtestOnBorrow
andtestOnReturn
could cause the statements you see.c3p0 has
preferredTestQuery
,testConnectionOnCheckin
,testConnectionOnCheckout
andidleConnectionTestPeriod
For what's it's worth I tend to configure connection testing and checkout/borrow even if it means a little extra network chatter.