Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dml: unnecessary error reporting for select statement with redundant where clause in TiDB while MySQL returns correct results #24917

Open
PragmaTwice opened this issue May 27, 2021 · 2 comments
Labels
severity/moderate sig/execution SIG execution type/bug The issue is confirmed as a bug. wontfix This issue will not be fixed.

Comments

@PragmaTwice
Copy link
Contributor

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

create table t1 (i1 integer, f1 float);
insert into t1 values (2, 41), (1, 42), (3, 43), (0, null);
create table t2 (i2 integer, ii2 integer, f2 float);
insert into t2 values (0, 43, null), (1, null, 0.1), (3, 42, 0.01), (2, 51, 0.12), (null, 41, -0.1), (null, null, null);
select count(*) from t1 as _tmp_1 join (select * from t2 where false) as _tmp_2 where _tmp_2.i2=(select i1 from t1);

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

in MySQL:

+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.02 sec)

3. What did you see instead (Required)

in TiDB:

ERROR 1242 (21000): Subquery returns more than 1 row

4. What is your TiDB version? (Required)

+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| tidb_version()
                                                                                                                                                     |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Release Version: v5.1.0-alpha-13-gd5e0ed0aa-dirty
Edition: Community
Git Commit Hash: d5e0ed0aaed72d2f2dfe24e9deec31cb6cb5fdf0
Git Branch: master
UTC Build Time: 2021-05-24 14:39:20
GoVersion: go1.13
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false |
+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
@PragmaTwice PragmaTwice added the type/bug The issue is confirmed as a bug. label May 27, 2021
@eurekaka
Copy link
Contributor

This should be a compatibility issue. The behavior difference comes from the different execution order of the SQL clauses. For MySQL, it firstly evaluates t1 as _tmp_1 join (select * from t2 where false) and finds that the result is empty, so the where _tmp_2.i2=(select i1 from t1) is not evaluated at all, while TiDB would firstly execute the uncorrelated scalar subquery where _tmp_2.i2=(select i1 from t1) in optimization phase, so TiDB would report error while MySQL would not.

If we remove the where false filter from the query, MySQL would report error as well:

MySQL [test]> select count(*) from t1 as _tmp_1 join (select * from t2 where false) as _tmp_2 where _tmp_2.i2=(select i1 from t1);
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.01 sec)

MySQL [test]> select count(*) from t1 as _tmp_1 join (select * from t2) as _tmp_2 where _tmp_2.i2=(select i1 from t1);
ERROR 1242 (21000): Subquery returns more than 1 row

@eurekaka
Copy link
Contributor

We had a discussion about the optimization strategy regarding uncorrelated subqueries before, but did not reach an agreement on a plan to change that implementation, so this compatibility problem may not be solved in a short time.

@qw4990 qw4990 added the wontfix This issue will not be fixed. label Jun 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity/moderate sig/execution SIG execution type/bug The issue is confirmed as a bug. wontfix This issue will not be fixed.
Projects
None yet
Development

No branches or pull requests

4 participants