asfenbeat.blogg.se - Mysql optimizer script

#Mysql optimizer script plus#

In MySQL 5.0, the ferry will pick up the next passenger in line from point A, and transfer them to point B. It struck me today there is an easy way to describe MySQL’s Binary Log group commit improvements from MySQL 5.0-5.7 by using the example of a single ferry trying to ship passengers from point A to point B: It is time to start using OPTIMIZER TRACE, and particularly in 5.7 ditch EXPLAIN for EXPLAIN FORMAT=JSON. We can now say "this join is expensive", which is a much better distinction 🙂 By including the cost information in EXPLAIN we get all users to speak the same language. I have heard many users say "joins are slow", but a broad statement like this misses magnitude. These queries are not identical in cost even though they are in EXPLAIN output. With the FORMAT=JSON output also showing cost, we can see that two ranges costs 10.04, versus one big range costing 9.04 (not shown). The JSON output will now include cost information (as well as showing separate ranges as attached_condition): EXPLAIN FORMAT=JSONĮXPLAIN FORMAT=JSON was introduced in MySQL 5.6 along with OPTIMIZER TRACE, but where it really becomes useful is MySQL 5.7. It should be possible to distinguish between the two. Two distinct separate ranges may be two separate pages, and thus have different cache efficiency on the buffer pool. EXPLAIN will not show this difference, and both queries appear the same: It's pretty obvious that the second one needs to execute in two separate ranges. SELECT * FROM film WHERE (film_id BETWEEN 1 and 10) or (film_id BETWEEN 911 and 920).SELECT * FROM film WHERE film_id BETWEEN 1 and 20.

Perhaps a better example to demonstrate this, is the difference between these two ranges: It is stable to compare costs between different execution plans.

#Mysql optimizer script plus#

A single range access plus next five times costs 2.0168 instead of 6.0168:įor context, a cost unit is a logical representation of approximately one random IO. So I would say that BETWEEN 1 AND 5 is the cheapest query, because it finds one key and then says next, next, next until finished. This can also be confirmed with the handler counts from SHOW STATUS:įilm_id =1 or film_id=2 or film_id=3 or film_id=4 or film_id=5: The optimizer trace output shows that the first query executes as one range, while the second and third execute as 5 separate single-value ranges:

SELECT * FROM film WHERE film_id =1 or film_id=2 or film_id=3 or film_id=4 or film_id=5.

SELECT * FROM film WHERE film_id IN (1,2,3,4,5).

SELECT * FROM film WHERE film_id BETWEEN 1 AND 5.

Here are the outputs for the three versions of the query:

You enable the optimizer trace, then you run the actual query.

It doesn’t just show the intended execution plan, it shows the alternative choices.

It is similar to EXPLAIN, with a few notable differences: Optimizer trace is a new diagnostic tool introduced in MySQL 5.6 to show how the optimizer is working internally. There are now a couple of useful features to show the difference 🙂 Optimizer Trace Mysql> EXPLAIN SELECT * FROM film WHERE film_id =1 or film_id=2 or film_id=3 or film_id=4 or film_id=5\G Mysql> EXPLAIN SELECT * FROM film WHERE film_id IN (1,2,3,4,5)\G Mysql> EXPLAIN SELECT * FROM film WHERE film_id BETWEEN 1 AND 5\G Here is an example using the sakila schema: All of the queries resolve to the same output in EXPLAIN. It is an interesting question because there was no good way to answer it when it was asked in 2009. WHERE someFIELD = 1 OR someFIELD = 2 OR someFIELD = 3. I am wondering if there is any difference in regards to performance between the following: I accidentally stumbled upon this Stack Overflow question this morning: