Bug #99815 Insist on using System.nanoTime() to measure elapsed time
Submitted: 9 Jun 2020 3:01 Modified: 9 Jun 2020 4:21
Reporter: Yanming Zhou (OCA) Email Updates:
Status: Verified Impact on me:
Category:Connector / J Severity:S3 (Non-critical)
Version:8.0.x OS:Any
Assigned to: CPU Architecture:Any

[9 Jun 2020 3:01] Yanming Zhou
System.nanoTime() is introduced since JDK 1.5, It's safe enough to call it directly not by reflection:


TimeUtil.getCurrentTimeNanosOrMillis() returns uncertain TimeUnit, It cause Query.getExecuteTime() meaningless, in nanos or ms?

How to repeat:
It's not a bug, It's an improvement.

Suggested fix:
1. Use System.nanoTime() instead of System.currentTimeMillis().
2. Remove property "useNanosForElapsedTime" since it is always true.
3. Rename method names indicate that return nanos, for example Query.getExecuteTime() to Query.getExecuteTimeInNanos()
[9 Jun 2020 3:22] Yanming Zhou
Then there is a bug here, executeTime is in nanos if JDK is 1.5 or later, slowQueryThresholdMillis is always in ms, then all queries will be treat as slow query.

[9 Jun 2020 4:21] MySQL Verification Team
Hello Yanming Zhou,

Thank you for the report and feedback.

[16 Jun 2020 23:52] Filipe Silva
Note that `useNanosForElapsedTime` is "false" by default. All seems to work fine if you don't set it to "true". You are right, though. Using nanos really breaks some of the slow query logging features.

Regarding `Query.getExecuteTime()` returning nanos or millis, I'd say this is debatable question. It makes sense to me that you get different units depending on the value you set in `useNanosForElapsedTime`.

Thanks for your interest in Connector/J and MySQL.