max_execution_time is not compatible with MySQL

[ChenPeng2013]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

use test;
drop table if exists t;
create table t(a int);
insert into t values(1);
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;
insert into t select * from t;

set @@max_execution_time = 1;
select * from t;
alter table t add index idx(a);

2. What did you expect to see? (Required)

mysql 8.0.21

mysql> select * from t;
ERROR 3024 (HY000): Query execution was interrupted, maximum statement execution time exceeded
mysql> alter table t add index idx(a);
Query OK, 0 rows affected (0.19 sec)
Records: 0  Duplicates: 0  Warnings: 0

3. What did you see instead (Required)

mysql> select * from t;
ERROR 1317 (70100): Query execution was interrupted
mysql> alter table t add index idx(a);
ERROR 1317 (70100): Query execution was interrupted

4. What is your TiDB version? (Required)

master v4.0.0-beta.2-2274-gdb62e341f
release-5.0-rc v5.0.0-rc-21-g8304d661f
release-4.0 v4.0.11-10-g38f9bdd81

[jyz0309]

/assign

[morgo]

This is currently a documented behavior:

Unlike in MySQL, the max_execution_time system variable currently works on all kinds of statements in TiDB, not only restricted to the SELECT statement.

I think it is wrong though, it should not apply to DDL. There is no problem with it applying to INSERT/UPDATE/DELETE.

[jyz0309]

This is currently a documented behavior:

Unlike in MySQL, the max_execution_time system variable currently works on all kinds of statements in TiDB, not only restricted to the SELECT statement.

I think it is wrong though, it should not apply to DDL. There is no problem with it applying to INSERT/UPDATE/DELETE.

Yep, and although it seemed to apply to DDL, the DDL will exec successful after show the error. So I think it's a bug caused by Expensive Query