MySQL Workbench 中的 MySQL 8.0.12 密钥效率为 0.0%

Posted 2023-03-23

【中文标题】MySQL Workbench 中的 MySQL 8.0.12 密钥效率为 0.0%

【英文标题】：MySQL 8.0.12 key efficiency at 0.0% in MySQL Workbench

【发布时间】：2019-01-30 10:17:17

【问题描述】：

我有一个 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

【问题讨论】：

另外，请发布完整的当前错误日志（在 pastebin.com 或此处）以直观地验证内容。谢谢。

这里是 txt-file 的链接，您要求的所有内容都是：1drv.ms/t/s!Ak5nrcTR_zUIxVcOHxNJFlmfG4rx 该文件的大小对于此文本区域来说太大了...

搜索 mysqltuner.pl 以下载 PERL 脚本，该脚本从正在运行的 MySQL 实例生成报告。请获取 Windows 64 位版本。请将报告复制到剪贴板，保存到 Wordpad.txt 文件并上传。谢谢

我在时区 UTC +2 小时。是的，我可以访问 Skype - 我的 Skype ID 是 dannielsen1982 (atsign) gmail.com

我认为“关键效率”指的是 MyISAM 表。

【参考方案1】：

为您的 my.ini [mysqld] 部分考虑的建议（RPS=Rate Per Second）

# 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 并告诉我们。

【讨论】：

谢谢。我会试试的。完成所有更改需要几天时间 - 完成更改后我会返回。

【参考方案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% -- 读取必须命中磁盘的请求 -- 如果你有足够的内存，增加 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 -- 多久自动清除 binlog（经过这么多天） -- 太大（或为零）= 消耗磁盘空间；太小 = 需要快速响应网络/机器崩溃。 （如果 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，使用db.tbl语法，消除虚假的USE语句等