phpBB SELECT在新服务器上持续很长时间

Question

我正在设置一个新的服务器，并希望在那里移动现有的phpBB安装。一切顺利，除了一个SELECT在SLOW日志中并永远吃掉CPU。我不是数据库专家，所以我迷路了。

旧服务器 - Win2008 R2，MySQL 5.7.24，php 5.6.39，单i7四核CPU，24GB RAM

新服务器 - Win2016，MySQL 8.0.15，php 7.1.5，双Xeon CPU，96GB RAM

我试图打开每个表并检查错误，使用OK结果执行mysql_upgrade。有问题的SELECT是：

SELECT ug.user_id, a.forum_id, r.auth_setting, r.auth_option_id, ao.auth_option
            FROM phpbb_acl_groups a, phpbb_user_group ug, phpbb_groups g, phpbb_acl_roles_data r, phpbb_acl_options ao
            WHERE a.auth_role_id = r.role_id AND r.auth_option_id = ao.auth_option_id 
                AND a.group_id = ug.group_id
                AND g.group_id = ug.group_id
                AND ug.user_pending = 0
                AND NOT (ug.group_leader = 1 AND g.group_skip_auth = 1)


                AND ao.auth_option = 'm_';

在旧服务器上，立即完成选择。在新服务器上它持续25 - 30秒。看图片 - 看看“行检查”。但所有表格看起来都不错......

New server

Old server

旧服务器my.ini看起来像这样：

max_connections=151
table_open_cache=2000
tmp_table_size=922M
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=3G
key_buffer_size=8M
read_buffer_size=64K
read_rnd_buffer_size=256K
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=1M
innodb_buffer_pool_size=1024M
innodb_log_file_size=128M
innodb_thread_concurrency=17
innodb_autoextend_increment=64
innodb_buffer_pool_instances=8
innodb_concurrency_tickets=5000
innodb_old_blocks_time=1000
innodb_open_files=300
innodb_stats_on_metadata=0
innodb_file_per_table=1
innodb_checksum_algorithm=0
back_log=80
flush_time=0
join_buffer_size=256K
max_allowed_packet=4M
max_connect_errors=100
open_files_limit=4161
sort_buffer_size=256K
table_definition_cache=1400
binlog_row_event_max_size=8K
sync_master_info=10000
sync_relay_log=10000
sync_relay_log_info=10000

新服务器my.ini如下所示：

max_connections=151
table_open_cache=2000
tmp_table_size=5G
thread_cache_size=10
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=10G
key_buffer_size=8M
read_buffer_size=64K
read_rnd_buffer_size=256K
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=1M
innodb_buffer_pool_size=2048M
innodb_log_file_size=128M
innodb_thread_concurrency=24
innodb_autoextend_increment=64
innodb_buffer_pool_instances=8
innodb_concurrency_tickets=5000
innodb_old_blocks_time=1000
innodb_open_files=300
innodb_stats_on_metadata=0
innodb_file_per_table=1
innodb_checksum_algorithm=0
back_log=80
flush_time=0
join_buffer_size=256K
max_allowed_packet=4M
max_connect_errors=100
open_files_limit=4161
sort_buffer_size=256K
table_definition_cache=1400
binlog_row_event_max_size=8K
sync_master_info=10000
sync_relay_log=10000
sync_relay_log_info=10000

Answer 1

所以我：

• 比较旧数据库和新数据库之间的每个表数据，列，行，索引。我没有发现任何单一的差异。
• 在不同的机器上安装了mysql 8.0.15并在那里试了一下 - 以防新服务器出现问题。

没有运气。

所以最后一次尝试，我下载了当前的mysql 5.7.25版本并猜测它是什么 - 它的工作原理。

那么它是否可能是MySQL 8.x分支中的一些错误？我没有看到任何其他解释......

Answer 2

此网址https://dev.mysql.com/doc/relnotes/mysql/8.0/en/表示GA发布日期为2019-02-01 8.0.15。任何时候你跳到GA不到90天的版本，你就表明你愿意找到/报告遗漏的错误。你做出了一个明智的决定，回到5.7的东西，在成功的领域有一些实用的东西。您可能希望在一般可用性之后建立180天，以防止发现/报告或暴露于尚未纠正的错误。