A: HyperQuery needs a way to know which queries are running too slow. You can mitigate any performance concerns by setting the MySQL database to only log those queries above some threshold that you are comfortable with. For example, logging slow queries that take longer than 10 seconds to run might be too aggressive for your situation so you might consider a higher value such as only when the query takes longer than two minutes to run. As such, these user-defined settings can limit any potential overhead to a value that represents a fair tradeoff of overhead vs. autonomic performance optimization.

A: HyperQuery does not rely upon or even use that feature and instead leverages the optional MySQL “query rewrite cache”. This is distinctly different from the query cache, which has not been deprecated, nor reported as unacceptable overhead.

A: It could, and that is why HyperQuery allows for complete user controlled/user configured thresholds to specify the maximum number of rewritten SQL queries to be posted in order to manage overhead to whatever level you deem acceptable.

A: Absolutely not! HyperQuery works at the SQL level for query correctness, enhancing the database’s own query optimizer and execution plan for maximum efficiency. Once we rewrite a query, it is submitted and processed in usual fashion.

A: Not really. MySQL stores queries with a “hash” value based upon the first 1,000 characters. By examining the length and this hash value, the lookups can be done very quickly and efficiently.

A: We only handle SELECT statements (reads). A deadlock is always caused by competing writes, so we do nothing for this.

A: HyperQuery’s rewrites are guaranteed to return the same rows in the same order, verified via relational algebra and relational calculus proofs.

A: Once we rewrite, we post it to the MySQL rewrite table, thus, the registered rewrite is permanent. HyperQuery can produce various reports and Excel export files for auditing what has been registered, what types of queries are most inefficient, and what rewrite rules were fired and their frequency of occurrence.

A: Absolutely! Much money is wasted upgrading database servers with additional CPUs/cores, memory, faster storage (Flash), etc. to “brute force” performance. But root cause query performance problems are a SQL correctness/execution efficiency problem than a compute or I/O problem. How well understood would a book read, even by a fast reader, if it were written grammatically/tense incorrect?

A: Working strictly at the SQL/query level, HyperQuery never sees, touches, copies, moves, migrates ANY customer data, EVER!