MySQL Workbench中的MySQL 8.0.12密钥效率为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工作台中没有关键的效率：

服务器是具有8GB RAM的Windows Server 2012 64位。每天都有很多流量。我已经在配置文件中尝试了许多不同的选项-为了提高数据库的性能-但似乎无济于事。 我认为奇怪的是，旧文件夹\ 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中，其日期为定时文件名，例如 20180826hhmm-my.ini，以便快速恢复到上次运行my.ini的速度。

将此块（包括交货日期和我们的网站名称）复制到END 的[mysqld]部分中的内容，并通过删除前导＃和空格字符来启用每天的一项更改，请在继续进行下一项更改之前进行监视。

使用前导＃和空格键禁用EARLIER相同的NAMED变量，以免造成混淆。 在5年内，您仍将拥有my.ini更改的历史记录以及大约的日期。

通常每天仅更改一次，请先监控一次，然后再进行下一次更改。 在您的情况下，我现在要先实施3次更改，然后每天实施一次。 如果更改似乎有害，请返回上次运行的my.ini，并让我们知道。

Answer 2

观察

：

• 版本：8.0.12
• 8 GB的内存
• 正常运行时间= 1d 00:25:21
• 您正在Windows上运行。
• 运行64位版本
• 您似乎正在完全（或主要是）运行InnoDB。

更重要的问题：

innodb_buffer_pool_size 8388608是真的很糟糕！更改为5G。 8M是非常的默认值；您在升级过程中是否保留了该价值？这个低数字来自SHOW VARIABLES；我不知道配置文件中的6G发生了什么。检查正在使用哪个配置文件。

innodb_log_file_size = 200M

还有迹象表明索引编制不正确或查询质量不佳。更改long_query_time=2并打开慢速日志。这将帮助您识别恶棍。然后，我们可以讨论改进其中几个问题（在另一个问题中）。

也许有更多的调优项目需要讨论，但它们可能仅仅是上述项目的产物。

详细信息和其他观察结果：

( Innodb_buffer_pool_reads ) = 45,168,170 / 87921 = 513 /sec-InnoDB buffer_pool I / O读取速率 -检查innodb_buffer_pool_size

( Key_blocks_used * 1024 / key_buffer_size ) = 0 * 1024 / 8M = 0-使用的key_buffer的百分比。高水位标记。 -降低key_buffer_size以避免不必要的内存使用。

( innodb_buffer_pool_size / _ram ) = 8M / 8192M = 0.10%-用于InnoDB buffer_pool的RAM的百分比

( innodb_buffer_pool_size ) = 8M-InnoDB数据+索引缓存 -128M（旧的默认值）太小了。

( Innodb_pages_read / Innodb_buffer_pool_read_requests ) = 340,244,003 / 2770300306 = 12.3%-读取必须打入磁盘的请求 -如果您有足够的RAM，请增加innodb_buffer_pool_size。

( (Innodb_buffer_pool_reads + Innodb_buffer_pool_pages_flushed) ) = ((45168170 + 3155389) ) / 87921 = 549 /sec-InnoDB I / O -增加innodb_buffer_pool_size吗？

( Innodb_buffer_pool_read_ahead_evicted ) = 8,281,795 / 87921 = 94 /sec

( innodb_log_buffer_size ) = 1M-建议2MB-64MB，至少与交易中设置的最大Blob大小相同。 -调整innodb_log_buffer_size。

( Innodb_log_writes ) = 8,601,348 / 87921 = 98 /sec

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 87,921 / 60 * 48M / 4750519296 = 15.5-InnoDB日志轮换之间的分钟数，从5.6.8开始，可以动态更改。一定还要更改my.cnf。 -（建议每两次轮换60分钟有点随意。）调整innodb_log_file_size。 （无法在AWS中更改。）

( Innodb_rows_deleted / Innodb_rows_inserted ) = 1,217,329 / 1568258 = 0.776-流失 -“不要排队，就去做。” （如果将MySQL用作队列。）

( ( Innodb_pages_read + Innodb_pages_written ) / Uptime / innodb_io_capacity ) = ( 340244003 + 3164195 ) / 87921 / 200 = 1952.9%-如果> 100％，则需要更多的io_capacity。 -如果驱动器可以处理，请增加innodb_io_capacity。

( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF-是否记录所有死锁。 -如果您遇到死锁困扰，请将其打开。警告：如果您有很多死锁，则可能会在磁盘上写入很多内容。

( query_prealloc_size / _ram ) = 8,192 / 8192M = 0.00%-用于解析。内存百分比

( query_alloc_block_size / _ram ) = 8,192 / 8192M = 0.00%-用于解析。内存百分比

( Created_tmp_disk_tables ) = 234,424 / 87921 = 2.7 /sec-创建 disk “ temp”表作为复杂SELECT的一部分的频率 -增加tmp_table_size和max_heap_table_size。 在使用MEMORY代替MyISAM时检查临时表的规则。较小的架构或查询更改也许可以避免使用MyISAM。 更好的索引和重新编制查询更有可能会有所帮助。

( Created_tmp_disk_tables / Created_tmp_tables ) = 234,424 / 242216 = 96.8%-溢出到磁盘的临时表的百分比 -也许增加tmp_table_size和max_heap_table_size;改善指标；避免斑点等。

( (Com_insert + Com_update + Com_delete + Com_replace) / Com_commit ) = (1313529 + 596764 + 51863 + 0) / 0 = INF-每次提交的语句（假设所有InnoDB） -低：可能有助于在事务中将查询分组在一起；高：长时间的交易使各种各样的事情变得紧张。

( Select_scan ) = 18,208,699 / 87921 = 207 /sec-全表扫描 -添加索引/优化查询（除非它们是很小的表）

( Select_scan / Com_select ) = 18,208,699 / 20968533 = 86.8%-执行全表扫描的选择的百分比。 （可能会被存储例程欺骗。） -添加索引/优化查询

( Com_admin_commands ) = 2,588,206 / 87921 = 29 /sec -为什么有那么多DDL语句？

( expire_logs_days ) = 0-自动清除二进制日志的时间（在这几天之后） -太大（或为零）=占用磁盘空间；太小=需要快速响应网络/计算机崩溃。 （如果log_bin = OFF不相关）

( slave_pending_jobs_size_max / max_allowed_packet ) = 128M / 4M = 32-用于并行从属线程 -slave_pending_jobs_size_max不得小于max_allowed_pa​​cket

( long_query_time ) = 10-截止（秒），用于定义“慢速”查询。 -建议2

( back_log / max_connections ) = 80 / 151 = 53.0%

( Com_change_db / Connections ) = 2,588,247 / 2625 = 985-每个连接的数据库切换 -（次要）考虑使用“ db.table”语法

( Com_change_db ) = 2,588,247 / 87921 = 29 /sec-可能来自USE语句。 -考虑使用db.tbl语法与数据库连接，消除虚假的USE语句等。