explain命令可能會修改MySQL數據

若是有人問你，對查詢執行EXPLAIN是否能夠改變你的數據庫，你可能會說不會; 一般都是這麼認爲的。EXPLAIN應該向咱們展現查詢是如何執行的，而不是執行查詢，所以它不能更改任何數據。

不幸的是，在這種狀況下，常識並不適用於MySQL(在寫這篇文章的時候，MySQL 8.0.21和之前的版本)-有一些狀況下，explain能夠改變你的數據庫，就像這個Bug所示:

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.7.31    |
+-----------+
1 row in set (0.01 sec)

mysql> DELIMITER $$
mysql> CREATE FUNCTION `cleanup`() RETURNS char(50) CHARSET utf8mb4
    ->     DETERMINISTIC
    -> BEGIN 
    -> delete from test.t1;
    -> RETURN 'OK'; 
    -> END $$
Query OK, 0 rows affected (0.00 sec)

mysql> 

mysql> select * from t1$$
+------+------+
| id   | name |
+------+------+
|    1 | aa   |
|    2 | bb   |
+------+------+
2 rows in set (0.00 sec)

mysql> explain select * from (select cleanup()) as t1clean$$
+----+-------------+------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table      | partitions | type   | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
|  1 | PRIMARY     | <derived2> | NULL       | system | NULL          | NULL | NULL    | NULL |    1 |   100.00 | NULL           |
|  2 | DERIVED     | NULL       | NULL       | NULL   | NULL          | NULL | NULL    | NULL | NULL |     NULL | No tables used |
+----+-------------+------------+------------+--------+---------------+------+---------+------+------+----------+----------------+
2 rows in set, 1 warning (0.01 sec)

mysql> select * from t1$$
Empty set (0.00 sec)

mysql> 

這裏的問題是explain執行了存儲函數cleanup()，該函數是能夠修改數據的。

這與更理智的PostgreSQL行爲不一樣，後者在運行EXPLAIN時不會執行存儲函數(若是你運行EXPLAIN ANALYZE，則會執行)。

在MySQL中，這個決定來自於嘗試作正確的事情並提供最可靠的解釋(查詢執行計劃極可能取決於存儲函數返回什麼)，但彷佛沒有考慮這種安全權衡。

 

儘管當前MySQL EXPLAIN設計的這種後果是最嚴重的後果之一，但你還遇到一個問題，即EXPLAIN（理性的用戶但願這是檢查查詢性能的一種快速方法）可能須要花費大量時間才能完成， 例如：

mysql> explain select * from (select sleep(5000) as a) b;

　　

這會運行一個多小時。

 

雖然很不幸有這樣的行爲，但只有在擁有不受限制的權限時纔會發生。若是有一個更復雜的設置，行爲可能會有所不一樣。

若是用戶缺乏EXECUTE權限，EXPLAIN語句將失敗。

mysql> explain select * from (select cleanup()) as t1clean;
ERROR 1370 (42000): execute command denied to user 'abce'@'localhost' for routine 'test.cleanup'

　　

若是用戶有EXECUTE權限，可是執行存儲函數的用戶沒有DELETE權限，也會失敗:

mysql> explain select * from (select cleanup()) as t1clean;
ERROR 1142 (42000): DELETE command denied to user 'abce'@'localhost' for table 't1'

　　

那麼，若是想提升EXPLAIN的安全性，例如，正在開發Percona Monitoring and Management之類的工具，該工具除其餘功能以外，還容許用戶對其查詢運行EXPLAIN，該怎麼辦？

·建議用戶設置權限以進行正確的監控。這應該是這個（以及許多其餘）問題的第一道防線，可是，這很難依靠。許多用戶將選擇簡單的方式，並將使用具備徹底特權的「 root」用戶進行監控。

·將EXPLAIN語句包裝在BEGIN…ROLLBACK中，這將撤消EXPLAIN可能形成的任何損害。缺點固然是刪除數據的「工做」，而且在撤消工做時將完成工做。（注意：固然，這僅適用於事務表。若是你仍然運行MyISAM，在這種狀況下，有更嚴重的問題須要擔憂）

·使用「set transaction read-only」，表示不但願進行任何寫操做。在這種狀況下，嘗試寫數據的EXPLAIN將失敗，而且不作任何工做。

 

雖然這些變通辦法能夠使工具更安全地運行EXPLAIN，但它不能幫助用戶直接運行EXPLAIN，而且我真的但願經過從新設計EXPLAIN來解決此問題，就像PostgreSQL那樣不會嘗試運行存儲函數。對於那些想知道如何精確執行查詢的人，如今有了EXPLAIN ANALYZE。