Available in versions: Dev (3.20) | Latest (3.19) | 3.18 | 3.17 | 3.16 | 3.15 | 3.14 | 3.13 | 3.12 | 3.11
This documentation is for the unreleased development version of jOOQ. Click on the above version links to get this documentation for a supported version of jOOQ.
Duplicate Statements
Applies to ✅ Open Source Edition ✅ Express Edition ✅ Professional Edition ✅ Enterprise Edition
The SPI method handling this event is duplicateStatements()
.If the feature is available, then pattern based SQL transformations will be used to further normalise possibly duplicate SQL.
A common source of overhead in databases that have an execution plan cache (or "cursor cache", etc.) are static statements, or prepared statements that differ only by "irrelevant" things:
- They may differ by white space
- They may differ by irrelevant syntactic elements (e.g. excess parentheses, or object name qualification, table aliasing, etc.)
- They may differ by input values, which are inlined into the statement rather than parameterised as bind values
- They may differ by the length of their IN predicate's IN-list sizes
Why is it bad?
There are two main problems:
- If the duplicate SQL appears in dynamic SQL (i.e. in generated SQL), then there is an indication that the database's parser and optimiser may have to do too much work parsing the various similar (but not identical) SQL queries and finding an execution plan for them, each time. In fact, it will find the same execution plan most of the time, but with some significant overhead. Depending on the query complexity, this overhead can easily go from milliseconds into several seconds, blocking important resources in the database. If duplicate SQL happens at peak load times, this problem can have a significant impact in production. It never affects your (single user) development environments, where the overhead of parsing duplicate SQL is manageable.
- If the duplicate SQL appears in static SQL, this can simply indicate that the query was copy pasted, and you might be able to refactor it. There's probably not any performance issue arising from duplicate static SQL
An example is given here:
// A custom DiagnosticsListener SPI implementation class DuplicateStatements implements DiagnosticsListener { @Override public void duplicateStatements(DiagnosticsContext ctx) { // The statement that is being executed and which has duplicates System.out.println("Actual statement: " + ctx.actualStatement()); // A normalised version of the actual statement, which is shared by all duplicates // This statement has "normal" whitespace, bind variables, IN-lists, etc. System.out.println("Normalised statement: " + ctx.normalisedStatement()); // All the duplicate actual statements that have produced the same normalised // statement in the recent past. System.out.println("Duplicate statements: " + ctx.duplicateStatements()); } }
And then:
// Utility to run SQL on a new JDBC Statement void run(String sql) { // Configuration is configured with the target DataSource, SQLDialect, etc. for instance Oracle. try (Connection c = DSL.using(configuration.derive(new DuplicateStatements())) .diagnosticsConnection(); Statement s = c.createStatement(); ResultSet rs = s.executeQuery(sql)) { while (rs.next()) { // Consume result set } } } // Everything is fine with the first execution run("SELECT title FROM book WHERE id = 1"); // This query is identical to the previous one, differing only in irrelevant white space run("SELECT title FROM book WHERE id = 1"); // This query is identical to the previous one, differing only in irrelevant additional parentheses run("SELECT title FROM book WHERE (id = 1)"); // This query is identical to the previous one, differing only in what should be a bind variable run("SELECT title FROM book WHERE id = 2"); // Everything is fine with the first execution of a new query that has never been seen run("SELECT title FROM book WHERE id IN (1, 2, 3, 4, 5)"); // This query is identical to the previous one, differing only in what should be bind variables run("SELECT title FROM book WHERE id IN (1, 2, 3, 4, 5, 6)"); }
Unlike when detecting repeated statements, duplicate statement statistics are performed globally over all JDBC connections and data sources.
References to this page
Feedback
Do you have any feedback about this page? We'd love to hear it!