[英]why MySql 8.0.17 Select query performance is slower than Mysql 5.7.26?
We have very basic query like我们有非常基本的查询,例如
select * from Some_Table
which used to work fine in Mysql 5.7 .它曾经在 Mysql 5.7 中工作正常。 And same data in Mysql 8. 0 is taking some time double the time( around 2 million data).
Mysql 8. 0 中的相同数据需要花费两倍的时间(大约 200 万条数据)。 We have upgraded from 5.7 to 8.x and seeing the performance degrade.
我们已经从 5.7 升级到 8.x 并且看到性能下降。 Also we tried changing the values for below system variables in my.cnf file but the issue still persists.
我们还尝试更改 my.cnf 文件中以下系统变量的值,但问题仍然存在。
sort_buffer_size
read_buffer_size
read_rnd_buffer_size
myisam_sort_buffer_size
max_allowed_packet
wait_timeout
interactive_timeout
connect_timeout
Any help will be great , how to make 8.x faster than or equal to 5.7x任何帮助都会很棒,如何使 8.x 快于或等于 5.7x
Seems to be an unsolved bug!似乎是一个未解决的错误!
I'd like to confirm that I have the same problem with MySQL 8.0.21 on my Windows developer machine (64 GB RAM, Ryzen 3900, NVE SSD) where a count of a simple table with ~ 70.000 data sets takes 22 seconds.
我想确认我的 Windows 开发人员机器(64 GB RAM、Ryzen 3900、NVE SSD)上的 MySQL 8.0.21 有同样的问题,其中一个包含约 70.000 个数据集的简单表的计数需要 22 秒。 Adding WHERE id > 0 as suggested above reduces the query time to 0.2 seconds.
按照上面的建议添加 WHERE id > 0 将查询时间减少到 0.2 秒。 So there is definitely a bug in MySQL 8. Testing the same table on a much slower windows machine (Surface Pro 3) with Maria 10 DB or any online Host with MySQL 5.7 also gives instant results.
因此 MySQL 8 中肯定存在错误。在速度慢得多的 Windows 机器(Surface Pro 3)上使用 Maria 10 DB 或任何带有 MySQL 5.7 的在线主机测试同一个表也可以立即得到结果。
https://bugs.mysql.com/bug.php?id=97709 https://bugs.mysql.com/bug.php?id=97709
Here with potential patch: https://bugs.mysql.com/bug.php?id=100966这里有潜在的补丁: https : //bugs.mysql.com/bug.php?id=100966
However, my Mysql 8.0.23 has still slow speed issues.但是,我的Mysql 8.0.23 还是有速度慢的问题。
The suggested temporary "fix" for the bug is to change your MySQL query (if applicable) to use id > 0
:该错误的建议临时“修复”是将您的 MySQL 查询(如果适用)更改为使用
id > 0
:
SELECT COUNT(*) FROM yourtable
WHERE id > 0
Last comment in the mysql bug thread is: mysql 错误线程中的最后一条评论是:
We have encountered the same issue, after some extensive test we found that setting the variable innodb_flush_method to FSYNC.
我们遇到了同样的问题,经过一些广泛的测试我们发现将变量innodb_flush_method设置为 FSYNC。 The performance improves dramatically.
性能显着提高。
I have checked my DB using SHOW VARIABLES
and found innodb_flush_method
with value fsync
, so this is definitely not the fix for the bug.我已经使用
SHOW VARIABLES
检查了我的数据库,发现innodb_flush_method
的值为fsync
,所以这绝对不是该错误的修复程序。
innodb_flush_log_at_timeout 1
innodb_flush_log_at_trx_commit 1
innodb_flush_method fsync
innodb_flush_neighbors 0
innodb_flush_sync ON
innodb_flushing_avg_loops 30
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.