EXPLAIN SELECT 20 AS C UNION SELECT 10 AS C ORDER BY C

id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL No tables used
2 UNION NULL NULL NULL NULL NULL NULL NULL No tables used
NULL UNION RESULT ALL NULL NULL NULL NULL NULL Using filesort

Obviously there’s no merge-sorting here, and no hard drive files are in use.

I would very much like the chance to interview to become a freelance consultant for Percona. Although my regular business keeps me very busy, I’m always willing to help other people when I can, and I have a son in college – so I could use the extra income!

I see you insert two records in the table ‘fs’ then EXPLAIN table ‘t1′ which has three records.
In my opinion your example is not very clear. Moreover I get the behaviour as explained by Baron.
Am I missing something?

>>>
(root@localhost) [test] CREATE TABLE t1 (id int unsigned NOT NULL);
Query OK, 0 rows affected (0.13 sec)

(root@localhost) [test] INSERT INTO t1 (id) VALUES (1),(2);
Query OK, 2 rows affected (0.14 sec)
Records: 2 Duplicates: 0 Warnings: 0

(root@localhost) [test] EXPLAIN SELECT * FROM t1 ORDER BY id\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t1
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2
Extra: Using filesort
1 row in set (0.00 sec)

(root@localhost) [test] ALTER TABLE t1 ADD INDEX (id);
Query OK, 2 rows affected (0.33 sec)
Records: 2 Duplicates: 0 Warnings: 0

(root@localhost) [test] EXPLAIN SELECT * FROM t1 ORDER BY id\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t1
type: index
possible_keys: NULL
key: id
key_len: 4
ref: NULL
rows: 2
Extra: Using index
1 row in set (0.00 sec)

(root@localhost) [test]
<<<

Reading through this thread what scares me is it appears you also have some misconceptions about MySQL and yet you “show people to the door” who in this case seem to have a good grasp of the answer. Hope I don’t have to cross paths I wouldn’t want to waste my time.

I think I always had the general idea, but reading these posts gave an extra layer.

T

You will be amazed how many MySQL “experts” don’t read the manual. They either “know” or assume.

At the other had digging out such information is difficult. MySQL manual is not easy to navigate and it changes all the time. What’s in there now could be added just couple of hours ago.

So don’t blame people who didn’t know how to find such information.

As for such questions being bad for interviews it depends on what do you want to understand about the candidate and even more what job you are interviewing for.

If it’s about on-site consulting you definitely prefer one being able to answer everything on top of his head.

=========================
Using filesort

MySQL must do an extra pass to find out how to retrieve the rows in sorted order. The sort is done by going through all rows according to the join type and storing the sort key and pointer to the row for all rows that match the WHERE clause. The keys then are sorted and the rows are retrieved in sorted order.
=========================

http://dev.mysql.com/doc/refman/5.0/en/using-explain.html

In fact, such quaestions are VERY bad on the interview. It is ok to test skills during the interview but it is bad to ask for very low details. Much better to test if the person can ~find~ the answer to the question. Someone who knows is not necessarily the best. Someone who does not know but can find the answer is typically better.

Thanks for posting!