Bug #116612 | Performance degradation of distinct operator from 5.7 to 8.0 | ||
---|---|---|---|
Submitted: | 11 Nov 2024 11:46 | Modified: | 11 Nov 2024 14:07 |
Reporter: | Jingqi Tian (OCA) | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Optimizer | Severity: | S5 (Performance) |
Version: | 8.0.40, 8.0.41, 8.4.4 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | regression |
[11 Nov 2024 11:46]
Jingqi Tian
[11 Nov 2024 14:07]
MySQL Verification Team
Hello Jingqi Tian, Thank you for the report and test case. regards, Umesh
[7 May 7:17]
MySQL Verification Team
Hello Jingqi Tian, Internally development proposed a workaround, I'm quoting here for your reference. Posted By Developer ================== Given the query: select distinct t1.* from t1 left join t2 on t1.col1 = t2.col1 left join t3 on t1.col1 = t3.col1 left join t4 on t1.col1 = t4.col1; The only table referred to in the SELECT list and WHERE clause is t1. Since t1 is also the only table on the left side of a LEFT JOIN, we know the join will return all rows in t1, regardless of whether there are any matches in the other tables. Since DISTINCT is specified, we don't need to know how many rows match. So we can remove all the different tables and reduce the query to this: For example: select distinct t1.* from t1 left join t2 on t1.col1 = t2.col1 left join t3 on t1.col1 = t3.col1 left join t4 on t1.col1 = t4.col1; The result is the same as the result of select distinct t1.* from t1; Hence rest of the joins and table access are not needed in the given test case. regards, Umesh