我正在设置一个新服务器,并想将现有的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
我试图打开每个表并检查是否有错误,并执行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秒。看图片-看“检查的行”。但是所有表看起来都很好...
旧服务器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
答案 0 :(得分:1)
所以,我:
没有运气。
因此,在最后一次尝试时,我下载了当前的mysql 5.7.25版本并猜测是什么-它可以工作。
那么这可能是MySQL 8.x分支中的一些错误吗?我看不到其他任何解释...
答案 1 :(得分:0)
此网址https://dev.mysql.com/doc/relnotes/mysql/8.0/en/ 表示GA发布日期是8.0.15的2019年2月1日。每当您以不到90天的GA跳入发行版时,即表示您愿意查找/报告遗漏的错误。您做出了明智的决定,将5.7的成功经验回溯到5.7。您可能希望在“一般可用性”之后确定180天,以防止查找/报告或暴露于尚未纠正的错误。