Skip to main content

Controlling the Query Optimizer

The task of the query optimizer is to find an optimal plan for executing an SQL query. Because the difference in performance between “good” and “bad” plans can be orders of magnitude (that is, seconds versus hours or even days), most query optimizers, including that of MySQL, perform a more or less exhaustive search for an optimal plan among all possible query evaluation plans. For join queries, the number of possible plans investigated by the MySQL optimizer grows exponentially with the number of tables referenced in a query. For small numbers of tables (typically less than 7 to 10) this is not a problem. However, when larger queries are submitted, the time spent in query optimization may easily become the major bottleneck in the server's performance.



The behavior of the optimizer with respect to the number of plans it evaluates can be controlled using two system variables:
  • The optimizer_prune_level variable tells the optimizer to skip certain plans based on estimates of the number of rows accessed for each table. Our experience shows that this kind of “educated guess” rarely misses optimal plans, and may dramatically reduce query compilation times. That is why this option is on (optimizer_prune_level=1) by default. However, if you believe that the optimizer missed a better query plan, this option can be switched off (optimizer_prune_level=0) with the risk that query compilation may take much longer. Note that, even with the use of this heuristic, the optimizer still explores a roughly exponential number of plans.
  • The optimizer_search_depth variable tells how far into the “future” of each incomplete plan the optimizer should look to evaluate whether it should be expanded further. Smaller values of optimizer_search_depth may result in orders of magnitude smaller query compilation times. For example, queries with 12, 13, or more tables may easily require hours and even days to compile if optimizer_search_depth is close to the number of tables in the query. At the same time, if compiled with optimizer_search_depth equal to 3 or 4, the optimizer may compile in less than a minute for the same query. If you are unsure of what a reasonable value is foroptimizer_search_depth, this variable can be set to 0 to tell the optimizer to determine the value automatically.

Comments

Popular posts from this blog

About MySQL - Database history Support and Versioning

About MySQL: MySQL was created by a Swedish company. David Axmark (left) and Michael "Monty" Widenius,  MySQL AB, founded by David Axmark, Allan Larsson and Michael "Monty" Widenius. Original development of MySQL by Widenius and Axmark began in 1994. The first version of MySQL appeared on 23 May 1995. It was initially created for personal usage from mSQL based on the low-level language ISAM, which the creators considered too slow and inflexible. They created a new SQL interface, while keeping the same API as mSQL. By keeping the API consistent with the mSQL system, many developers were able to use MySQL instead of the (proprietarily licensed) mSQL antecedent. Support: The MySQL server software itself and the client libraries use dual-licensing distribution. They are offered under GPL version 2, or a proprietary license. MySQL AB owns the copyright to the MySQL source code. This means that MySQL AB can distribute MySQL under several different l...

MySQL thread error code of 1032- Translate binlog completely to avoid error

Could not execute Update_rows event on table db.table; Can't find record in 'table', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's   master log mysql-bin.262297, end_log_pos 1983208 As of my knowledge the causing stop of slave SQL thread error code of 1032, due to lack of sync between Master - Slave. In our case, slave got an Update event form master, but that particular record was not available in the slave. (Of course, that was deleted on Master n Slave separately) You would get this error only if the binlog_format is set to ROW_BASED or MIXED mode. So, now check that particular binlog at that position where replication stopped with this error. When you convert the binlog with mysqlbinlog command, you may see some junk characters   where you were expecting some DMLs which caused the error(In our case its an Update statement). So you can use below command to translate binlog completely: mysqlbinlog --base64-output=DECO...

MySQL Architecture -Client Server Architecture

Client/Server Overview The MySQL database system operates using a client/server architecture. The server is a central program that manages database contents, and client programs connect to the server to retrieve or modify the data. MySQL also includes non-client utility programs and scripts. MySQL Server:   This is the mysqld program that manages database and tables. Most users choose binary MySQL distribution that includes a server ready to run with the capabilities they need, but it's also possible to compile MySQL from source. Client Programs:  These are programs that communicate with the server by sending requests to it over a network connection. The server acts on each request and returns a response to the client. For example you can use the mysql client to send queries to the server, and the server returns the query results. A client program can connect locally to a server running on the same machine or remotely to a server running on a different mac...