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。