This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Safe Harbor StatementThe following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
• Best out of the box performance• Easy to use, minimum tuning needed• When you need to understand: explain and trace• Flexibility through optimizer switches, hints and plugins• Fast evolving
• 10 000 rows in the emp table• 100 rows in the office table• 100 rows with first_name=”John” AND hire_date BETWEEN “2012-01-
01″ AND “2012-06-01″
MySQL 5.7 Improved Record Estimates for JOIN
CREATE TABLE emp ( id INTEGER NOT NULL PRIMARY KEY, office_id INTEGER NOT NULL, first_name VARCHAR(20), hire_date DATE NOT NULL, KEY office (office_id) ) ENGINE=InnoDB;
CREATE TABLE office ( id INTEGER NOT NULL PRIMARY KEY, officename VARCHAR(20) ) ENGINE=InnoDB;
Table Type Possible keys Key Ref Rows Filtered Extraoffice ALL PRIMARY NULL NULL 100 100.00 NULL
employee ref office office office.id 99 100.00 Using where
MySQK 5.7 Improved Record Estimates for JOIN
Explain for 5.6: Total Cost = cost(scan office) + 100 * cost(ref_access emp)
Explain for 5.7: Total Cost = cost(scan emp) + 9991*1.23% * cost(eq_ref_access office)
SELECT office_nameFROM office JOIN employee ON office.id = employee.officeWHERE employee.name LIKE “John” AND hire_date BETWEEN “2014-01-01” AND “2014-06-01”;
Table Type Possible keys Key Ref Rows Filtered Extraemployee ALL NULL NULL NULL 9991 1.23 NULL
office eq_ref PRIMARY PRIMARY employee.office 1 100.00 Using where JOIN ORDERHAS CHANGED!
Total query cost of a query block Cost per table Cost of sorting operation Cost of reading data Cost of evaluating conditions Cost of prefix join Rows examined/produced per join Used columns Data read per join – (# of rows)*(record width) in byte
MySQL 5.7: Query Rewrite Plugin• New pre and post parse query rewrite APIs
– Users can write their own plug-ins
• Provides a post-parse query plugin– Rewrite problematic queries without the need to make application changes– Add hints– Modify join order– Many more …
• Improve problematic queries from ORMs, third party apps, etc• ~Zero performance overhead for queries not to be rewritten
MySQL 5.7 Query Rewrite Plug-in: Server’s POV• Query comes in
– Plugin(s) is asked if it wants digests (It does) • Query is parsed• Plugin is invoked• The plug-in may (in case of refresh of rules):
– Scan the rules table using the Rules Table Service. For each row:• Pattern + replacement parsed via the parser service• Pattern is traversed using the parser service• Parser service asked for string offsets of '?' in replacement• Parser service asked for normalized query text of pattern• performance_schema asked for digest
• The query is rewritten. Server raises SQL note.
1. Hash lookup using digest. High false positive rate2. Internal tree structure comparison. Misses literal constants3. Compare literal constants. In practice done during rewrite.
MySQL 5.7 Query Rewrite Plugin: Performance Impact
What is the Cost of Rewriting queries?• Designed for rewriting problematic queries only!• ~ Zero cost for queries not to be rewritten
– Statement digest computed for performance schema anyway
• Cost of queries to be rewritten is insignificant compared to performance gain– Cost of generating query + reparsing max ~5% performance overhead– Performance gain potentially x times
• Shows query plan on connection <id>• Useful for diagnostic on long running queries• Plan isn’t available when query plan is under creation• Applicable to SELECT/INSERT/DELETE/UPDATE
• Column generated from the expression• VIRTUAL: computed when read, not stored, not indexable• STORED: computed when inserted/updated, stored in SE, indexable• Useful for:
– Functional index: create a stored column, add a secondary index– Materialized cache for complex conditions – Simplify query expression
SELECT COUNT(*) FROM innodb_table WHERE MATCH(text) AGAINST ('for the this that‘ in natural language mode) > 0.5;
• Recognize more situations where ‘index only’ access method can be use. No need to access base table, only FT index – when the MATCH expression was part of a '>' expression