从 DUAL 中选择 1:MySQL

发布于 2024-07-21 13:32:00 字数 1092 浏览 6 评论 0原文

在查看我的查询日志时,我发现了一个奇怪的模式,但我无法解释。

几乎每次查询后,我都会“从 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

糖果控 2024-07-28 13:32:03

我已经执行了 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

沧笙踏歌 2024-07-28 13:32:03

“双重”表/对象名称是 Oracle 的一种构造,MySQL 支持这种构造是为了实现兼容性,或者为没有目标但人们希望感觉温暖而模糊的查询提供目标。 例如,

select curdate()

可能

select curdate() from dual

有人会嗅探您以查看您是否正在运行 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.

select curdate()

can be

select curdate() from dual

Someone could be sniffing you to see if you're running Oracle.

心在旅行 2024-07-28 13:32:02

它可能来自您的应用程序正在使用的连接池。 我们使用一个简单的查询来测试连接。

刚刚快速浏览了 mysql-connector-j 的源代码,它不是来自那里。

最可能的原因是连接池。

公共连接池:

commons-dbcp有一个配置属性validationQuery,这与testOnBorrowtestOnReturn结合可能会导致你看到的陈述。

c3p0preferredTestQuerytestConnectionOnCheckintestConnectionOnCheckoutidleConnectionTestPeriod

对于我倾向于的价值配置连接测试和签出/借用,即使这意味着一些额外的网络干扰。

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 with testOnBorrow and testOnReturn could cause the statements you see.

c3p0 has preferredTestQuery, testConnectionOnCheckin, testConnectionOnCheckout and idleConnectionTestPeriod

For what's it's worth I tend to configure connection testing and checkout/borrow even if it means a little extra network chatter.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文