Bug #112767 | SELECT COUNT(*) degraded performance on 8.0 compared to 5.7 | ||
---|---|---|---|
Submitted: | 19 Oct 2023 6:07 | Modified: | 16 Feb 2024 22:07 |
Reporter: | Aristotle Po | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S5 (Performance) |
Version: | 8.0.34, 8.0.35 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[19 Oct 2023 6:07]
Aristotle Po
[26 Oct 2023 7:50]
MySQL Verification Team
Hello Aristotle Po, Thank you for the report and feedback. Could you please share exact configuration files used for both 5.7/8.0 for the tests? I'm currently trying with default settings(but comparison will be not accurate since binary logging is off by default in 5.7 and is on by default in 8.0 and diff in charset as well). Thank you. Sincerely, Umesh
[26 Oct 2023 10:31]
Aristotle Po
my.cnf and global variables
Attachment: bug112767-my-cnf-5.7.txt (text/plain), 882 bytes.
[26 Oct 2023 10:35]
Aristotle Po
5.7 and 8.0 my.cnf and global variables in a zip file.
Attachment: my-cnf-and-global-variables.zip (application/zip, text), 22.71 KiB.
[26 Oct 2023 10:37]
Aristotle Po
Hi Umesh, Please refer to the attached zip file. Regards, Aristotle
[26 Oct 2023 14:05]
MySQL Verification Team
Hello Aristotle Po, Thank you for the requested details. regards, Umesh
[26 Oct 2023 14:06]
MySQL Verification Team
Related - Bug #97709
[27 Oct 2023 7:16]
MySQL Verification Team
Test results - 8.0.11+, 5.7.44
Attachment: 112767_5.7_8.0.results (application/octet-stream, text), 24.49 KiB.
[18 Jan 2024 19:52]
Lucas Migliorini
Hi team, I have the same situation described by Aristotle Po. Do you have any update or fix for this issue ? The time is bigger when the content is bigger. Mysql 8.0.34 MySQL [customer1]> SELECT COUNT(*) FROM table_name ; +----------+ | COUNT(*) | +----------+ | 55541365 | +----------+ 1 row in set (6 min 29.40 sec) MySQL [customer1]> SELECT COUNT(*) FROM table_name WHERE id > 0 ; +----------+ | COUNT(*) | +----------+ | 55549130 | +----------+ 1 row in set (21.34 sec) Regards,
[19 Jan 2024 5:11]
Rahul Sisondia
Posted by developer: @ Lucas Migliorini I am investigating this issue.
[23 Jan 2024 5:32]
Rahul Sisondia
Posted by developer: [Updates] So far I could pinpoint that problem was introduced in the 8.0.17 through WL#12978 InnoDB:Fix imbalance during parallel scan. This worklog reads ahead pages in advance to utilize the parallel_read_threads. The overall idea is novel, it reduces the query time for in-memory workload. However, my suspicion is that it reads ahead pages either more than required or not optimally. This causes excessive read IO that slows down the query execution. I shall continue to investigate the problem. I may not able to be able to provide regular updates as I am juggling with multiple things at the moment. In the interim, workarounds that we already know : - Increase the buffer pool size and tune --innodb-parallel-read-threads - If possible use the predicate
[23 Jan 2024 13:41]
Lucas Migliorini
Thank you for your reply. We will wait for more updates. At this moment, we started to use PREDICATES as you suggested to avoid this issue. We thought that increase the innodb_buffer_poll_size would be too high to handle the amount of data that we have in some situations. Regards, Lucas Migliorini
[5 Feb 2024 9:08]
Rahul Sisondia
Posted by developer: The query reported in the bug uses the seconday index and WL#12978 enabled parallel scan for index scan which was not the case before. In other words, removing the following method which was added through this worklog brings the performance on par with 5.7 for such queries. --- a/storage/innobase/handler/ha_innodb.h +++ b/storage/innobase/handler/ha_innodb.h @@ -227,10 +227,10 @@ class ha_innobase : public handler { int records(ha_rows *num_rows) override; - int records_from_index(ha_rows *num_rows, uint) override { - /* Force use of cluster index until we implement sec index parallel scan. */ - return ha_innobase::records(num_rows); - }
[5 Feb 2024 13:26]
Rahul Sisondia
Posted by developer: Note my previous comment is an observation not a fix :)
[16 Feb 2024 22:07]
Philip Olson
Posted by developer: Fixed as of the upcoming MySQL Server 8.0.37 and 8.4.0 releases, and here's the proposed changelog entry from the documentation team: A SELECT COUNT(*) query that used a secondary index for scanning would perform much slower than the same query did in MySQL 5.7. Thank you for the bug report.
[16 Apr 2024 5:24]
MySQL Verification Team
Bug #100597 is marked as duplicate of this one
[17 Apr 2024 22:38]
Philip Olson
Posted by developer: Release note updated and now reads as follows for both MySQL Bug #100597 and MySQL Bug #112767: MySQL no longer ignores the Optimizer hint to use a secondary index scan, which instead forced a clustered (parallel) index scan.