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
Oracle CERT May Have A High False Positive Rate #855
Comments
Thanks for your interest! CERT does report a lot of issues, but it does not mean these issues are false alarms. CERT identifies performance issues by examining whether a more restrictive query has a higher estimated cardinality than a less restrictive query (e.g., Nevertheless, I cannot reproduce your results. I rerun this test case on 8.0.33, and the first query returns 3 rows, and the second query returns 2 rows. Both estimated cardinalities are consistent with the oracle, and CERT will not report it in theory. |
Executing
Executing
Executing
Executing
The order of the tables returned by using
All in all, my point is that finding real performance bugs among thousands of Thank you for your reply! |
Can you clarify why you think it is wrong? From the query plans you posted, the estimated cardinality of the first query is 5, and that of the second query is 12. The second query is more restrictive than the first query, so the numbers are unexpected indicating a potential performance issue. What we examined is the number of rows in the query plans, not the real number of rows.
As far as I know, I have not found any false alarms in these reports. These issues are true issues in |
Hello! The estimated cardinality of the first query is 5(t0), 12(t1), and the second query is 12(t1), 5(t0) too. So i think that the estimated cardinality of these two queries has no difference. As i have mentioned, the order of the tables's row returned by using explain is not fixed(maybe return t0 fisrt, maybe not), but the code above doesn't make the distinction. Thank you! |
Thanks for pointing out this issue! I see. The reason for this is both query plans have different orders of operations for scanning tables. Can you give me more details on how you configure MySQL? I did not know the ordering of operations in query plans can vary. And also, I rerun this test case, and have not observed the second query plan, in which t2 is before t1. In theory, the first operation in a query plan represents the root operation, and the ordering of operations should be fixed. Therefore, I am not very sure how can it happen and never observed it previously. |
Thank you for your reply. I compiled and installed MySQL from github source. I initialize datadir with
There is no other configuration else. As for whether the order of operations should be fixed, I have not been able to prove it yet. |
I may need some time to investigate why the query plans in MySQL are not in a fixed order. For your first suggestion, a more complicated database state, I agree. You can consider adjusting the parameter Thanks for your feedback! |
Hi. I have tested MySQL with Oracle CERT, and 1000+
.log
files could be generated in an hour. Obviously, Oracle CERT may have a high false positive rate, which makes it difficult to reproduce. Most of.log
files as follow.When the initial state of the database is too simple, Oracle CERT judging the performance issues by
rowCount1 != rowCount2
may doesn't work, which is implemented as follows.Do you think it is possible to improve from the following:
Thank you!
The text was updated successfully, but these errors were encountered: