Explain statements that aren’t SELECTs
I’ve been editing a task description in our worklog:
WL#706 Add EXPLAIN support for other statements (UPDATE/DELETE).
Currently MySQL supports EXPLAIN SELECT but there have been requests for EXPLAIN UPDATE, EXPLAIN DELETE, and so on. In fact it’s my impression that the proposition in WL#706 (transform the statement to a SELECT and then say EXPLAIN SELECT) is not what people want. But that’s okay, while a worklog is an early stage we allow simple ’solutions’ that might disappear later.
July 30th, 2009 at 11:04 pm
The current implementation of EXPLAIN (SELECT) is not suitable for anything else. Transforming other queries into SELECTs does not necessarily result in the same execution plan, and is therefore useless.
July 31st, 2009 at 10:02 am
Hi!
I agree with Arjen on this one.
If you transform the original EXPLAIN statement to a EXPLAIN SELECT statement, and you can’t guarantee that the plan will be the same, then please don’t. It does more harm than good, leaving the users chasing red herrings.
July 31st, 2009 at 3:13 pm
Production servers that I support have been hurt when someone used EXPLAIN of a select statement to understand the plan for a delete statement. The query used an index and the delete statement used a full table scan, thus locking all rows on a busy table. Insert/update/delete use different code in the optimizer. We need a real solution.