Which query should be used? Deducing from MySQL Explain - mysql

Question

Explaining MySQL Explain chapter in O'reilly Optimizing SQL Statments Book, has this question at the end.
The following is an example of a business need that retrieves orphaned parent records in a parent/child relationship. This SQL query can be written in three different ways. While the output produces the same results, the QEP shows three different paths.
mysql> EXPLAIN SELECT p.*
-> FROM parent p
-> WHERE p.id NOT IN (SELECT c.parent_id FROM child c)\G
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: p
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 160
Extra: Using where
*************************** 2. row ***************************
id: 2
select_type: DEPENDENT SUBQUERY
table: c
type: index_subquery
possible_keys: parent_id
key: parent_id
key_len: 4
ref: func
rows: 1
Extra: Using index
2 rows in set (0.00 sec)
mysql> EXPLAIN SELECT p.*
-> FROM parent p
-> LEFT JOIN child c ON p.id = c.parent_id
-> WHERE c.child_id IS NULL\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: p
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 160
Extra:
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: c
type: ref
possible_keys: parent_id
key: parent_id
key_len: 4
ref: test.p.id
rows: 1
Extra: Using where; Using index; Not exists
2 rows in set (0.00 sec)
mysql> EXPLAIN SELECT p.*
-> FROM parent p
-> WHERE NOT EXISTS
-> SELECT parent_id FROM child c WHERE c.parent_id = p.id)\G
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: p
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 160
Extra: Using where
*************************** 2. row ***************************
id: 2
select_type: DEPENDENT SUBQUERY
table: c
type: ref
possible_keys: parent_id
key: parent_id
key_len: 4
ref: test.p.id
rows: 1
Extra: Using index
2 rows in set (0.00 sec)
Which is best? Will data growth over time cause a different QEP to perform better?
There is no answer in the book or internet as far as I could research.

Answer 1

There is an old article from 2009 which I've seen linked on stackoverflow many times. The test there shows, that the NOT EXISTS query is 27% (it's actually 26%) slower than the other two queries (LEFT JOIN and NOT IN).
However, the optimizer has been improved from version to version. And the perfect optimizer would create the same execution plan for all three queries. But as long as the optimizer is not perfect, the answer on "Which query is faster?" can depend on actual setup (which includes version, settings and data).
I've run similar tests in the past, and all I remember is that the LEFT JOIN has never been significantly slower than any other method. But out of curiosity I've just created a new test on MariaDB 10.3.13 portable Windows version with default settings.
Dummy data:
set #parents = 1000;
drop table if exists parent;
create table parent(
parent_id mediumint unsigned primary key
);
insert into parent(parent_id)
select seq
from seq_1_to_1000000
where seq <= #parents
;
drop table if exists child;
create table child(
child_id mediumint unsigned primary key,
parent_id mediumint unsigned not null,
index (parent_id)
);
insert into child(child_id, parent_id)
select seq as child_id
, floor(rand(1)*#parents)+1 as parent_id
from seq_1_to_1000000
;
NOT IN:
set #start = TIME(SYSDATE(6));
select count(*) into #cnt
from parent p
where p.parent_id not in (select parent_id from child c);
select #cnt, TIMEDIFF(TIME(SYSDATE(6)), #start);
LEFT JOIN:
set #start = TIME(SYSDATE(6));
select count(*) into #cnt
from parent p
left join child c on c.parent_id = p.parent_id
where c.parent_id is null;
select #cnt, TIMEDIFF(TIME(SYSDATE(6)), #start);
NOT EXISTS:
set #start = TIME(SYSDATE(6));
select count(*) into #cnt
from parent p
where not exists (
select *
from child c
where c.parent_id = p.parent_id
);
select #cnt, TIMEDIFF(TIME(SYSDATE(6)), #start);
Execution time in milliseconds:
#parents | 1000 | 10000 | 100000 | 1000000
-----------|------|-------|--------|--------
NOT IN | 21 | 38 | 175 | 4459
LEFT JOIN | 24 | 40 | 183 | 1508
NOT EXISTS | 26 | 44 | 180 | 4463
I've executed the queries multiple times and took the least time value. And SYSDATE is probably not the best method to measure execution time - So don't take these numbers as accurate. However, we can see that up to 100K parent rows, there is not much difference, and the NOT IN method is a bit faster. But with 1M parent rows the LEFT JOIN is three times faster.
Conclusion
So what is the answer? I could just say: "LEFT JOIN" wins. But the truth is - This test proves nothing. And the answer is (as many times): "It depends". When performance matters, best you can do, is to run your own tests with real queries against real data. If you don't have real data (yet), you should create dummy data with the amount and distribution you expect to have in the future.

Answer 2

It depends on what version of MySQL you are using. In older versions, IN ( SELECT ...) performed terribly. In the latest version, it is often as good as the other variants. Also, MariaDB has some optimization differences, probably in this area.
EXISTS( SELECT 1 ... ) is perhaps the clearest in stating the intent. And it perhaps has always (once it came into existence) been fast.
NOT IN and NOT EXISTS are a different animal.
Some things in your Question that may have impact: func and index_subquery. In similar queries, you may not see these, and that difference may lead to performance differences.
Or, to repeat myself:
"There have been a number of improvements in the Optimizer since 2009.
"To the Author (Quassnoi): Please rerun your tests, and specify which version they are being run against. Note also that MySQL and MariaDB may yield different results.
"To the Reader: Test the variants yourself, do not blindly trust the conclusions in this blog."