MySQL 8.0.12 关键效率在 MySQL Workbench 中为 0.0%

Question

我有一个 MySQL 服务器，从 2015 年 12 月开始安装了 MySQL。然后我在大约 2 周前 (2018-08-07) 将它升级到 MySQL 8.0.12。

• 我从旧数据库创建了一个大约 20GB 的转储文件
• 然后我通过 Windows 控制面板中的添加/删除功能卸载了 MySQL 5.7。
• 然后我通过msi安装文件安装了新的MySQL 8.0.12数据库。
• 我从转储文件中导入了所有数据 - 并将所有数据库和表等的字符集更改为 utf8mb4。

一切正常 - 新数据库现在也可以正常工作 - 但有一件事我想知道:MySQL 工作台中没有关键效率:

服务器是 Windows Server 2012 64 位，8GB 内存。而且每天人流量很大。我在配置文件中尝试了很多不同的选项——为了提高数据库的性能——但似乎没有任何帮助。 我认为奇怪的另一件事是旧文件夹\ProgramData\MySQL\MySQL 5.7 仍然包含包含当前配置的 my.ini 文件。 当我将 MySQL 服务器升级到 8.0.12 时，它还创建了另一个名为\ProgramData\MySQL\MySQL 8.0\的文件夹 - 其中包含所有数据。如果 MySQL..，新版本的 MySQL 自动使用旧版本的旧配置文件是否正常？

我在这里附上了 my.ini 配置文件。关于为什么在关键效率方面没有任何反应的任何好主意 - 以及我应该在配置文件中进行哪些更改的任何好主意？ (所有路径都替换为“？？？？”)

[mysqld]

skip_name_resolve=on

innodb_buffer_pool_size=6G

innodb_buffer_pool_instances=8

innodb_buffer_pool_chunk_size=64M

disconnect_on_expired_password=off

port=3306

datadir=????

character-set-server=utf8mb4

collation-server=utf8mb4_0900_ai_ci

default_authentication_plugin=mysql_native_password

default-storage-engine=INNODB

sql-mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"

log-output=FILE

general-log=0

general_log_file="????"

slow-query-log=1

slow_query_log_file="????"

long_query_time=10

log-error="????"

server-id=1

lower_case_table_names=1

secure-file-priv="????"

max_connections=151

table_open_cache=2000

tmp_table_size=16M

thread_cache_size=10

myisam_max_sort_file_size = 100M

myisam_sort_buffer_size = 100M

key_buffer_size=104857600

read_buffer_size=0

read_rnd_buffer_size=0

innodb_flush_log_at_trx_commit=1

innodb_log_buffer_size=256M

innodb_log_file_size=2G

innodb_thread_concurrency=17

innodb_autoextend_increment=64

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=100M

max_allowed_packet = 16M

max_connect_errors=100

open_files_limit=4161

sort_buffer_size=100M

table_definition_cache=1400

binlog_row_event_max_size=8K

sync_master_info=10000

sync_relay_log=10000

sync_relay_log_info=10000

loose_mysqlx_port=33060

skip-character-set-client-handshake

mysql_firewall_mode = off

auto_generate_certs = off

sha256_password_auto_generate_rsa_keys = off

caching_sha2_password_auto_generate_rsa_keys = off

innodb_doublewrite = off

max_binlog_size = 1G

binlog_row_image = minimal

binlog_stmt_cache_size = 32768

binlog_expire_logs_seconds = 3600

binlog_cache_size = 32768

max_binlog_stmt_cache_size = 1G

binlog_row_metadata = MINIMAL

binlog-do-db = hmailserver

max_relay_log_size = 0

Answer 1

建议考虑您的 my.ini [mysqld] 部分(RPS=每秒速率)

# 20180826 05:30 from mysqlservertuning com
# myisam_max_sort_file_size=2G  # from 100G - you only have 8G
# read_rnd_buffer_size=256K  # from 1 character to reduce handler_read_rnd_next RPS
# read_buffer_size=128K  # from 8192 to reduce handler_read_next RPS
# tmp_table_size=32M  # from 16M to reduce created_tmp_tables RPS
# max_heap_table_size=32M  # from 16M to reduce created_tmp_disk_tables RPS
# thread_cache_size=100  # from 10 to reduce threads_created and CAP at 100 per refman
# innodb_buffer_pool_size=5G  # from 8M per SHOW GLOBAL STATUS today for data/ndx in RAM
# innodb_log_file_size=200M  # from 50M to extend minutes to next log rotation
# innodb_log_buffer_size=100M  # from 1M to support ~ 30 minutes of logging
# innodb_thread_concurrency=0  # from 17 see dba.stackexchange.com Question 5666
# innodb_flushing_avg_loops=10  # from 30 to reduce loop delay
# innodb_io_capacity=2000  # from 200 to allow higher IOPS

将您当前的 my.ini 保存在\history 中，并使用 DATED 时间文件名，例如 20180826hhmm-my.ini 允许快速返回到上次工作的 my.ini。

复制此 BLOCK(包括领先日期和我们的网站名称)到 END 您的 [mysqld] 部分并通过删除前导 # 和空格字符启用每天一次更改，在进行下一次更改之前进行监控。

禁用带有前导# 和空格键的EARLIER 相同NAMED 变量，以避免混淆。 5 年后，您仍将拥有 my.ini 更改的历史记录以及大概的日期。

通常每天只有一次更改，在进行下一次更改之前进行监控。 在您的情况下，我现在将实现前 3 项更改，然后每天一项。 如果更改似乎有害，请返回上次工作的 my.ini 并告诉我们。