我有一个mysql服务器，从2015年12月开始安装mysql。然后我在大约两周前（2018-08-07）将其升级到mysql 8.0.12。
我从旧数据库创建了一个大约20gb的转储文件
然后我通过windows控制面板中的add/remove函数卸载了mysql 5.7。
然后我通过msi安装文件安装了新的mysql 8.0.12数据库。
我从转储文件中导入了所有数据，并将所有数据库和表等的字符集更改为utf8mb4。
一切都很好——新的数据库现在也可以了——但有一点我很好奇：mysql workbench中没有关键的效率：
服务器为64位windows server 2012，内存为8gb。而且每天都有很多车辆。为了提高数据库的性能，我在配置文件中尝试了很多不同的选项，但似乎没有任何帮助。另一件我觉得奇怪的事情是，旧文件夹\programdata\mysql\MySQL5.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
2条答案
按热度按时间ldioqlga1#
为my.ini[mysqld]部分考虑的建议（rps=每秒速率）
将当前的my.ini保存在\history中，并使用日期计时文件名，例如20180826hhmm-my.ini，以便快速返回到上次使用的my.ini。
将此块（包括前导日期和我们的网站名称）复制到[mysqld]部分的末尾，并通过删除前导#和空格字符启用每天一次更改，然后继续进行下一次更改。
使用前导#和空格键禁用前面的同名变量，以避免混淆。在5年内，您仍将拥有my.ini更改的历史记录和大致日期。
通常每天只有一次更换，在进行下一次更换前进行监控。在您的情况下，我将现在实施前3个更改，然后每天实施一个。如果一个变化似乎有害，回到上一个工作我的.ini，让我们知道，请。
xytpbqjk2#
观察：
版本：8.0.12
8 gb内存
正常运行时间=1d 00:25:21
您正在windows上运行。
运行64位版本
您似乎正在运行全部（或大部分）innodb。
更重要的问题是：
innodb_buffer_pool_size 8388608真的很糟糕！更改为5G.8M是一个非常古老的违约；你在升级的时候有没有把这个价值带过来？这个低数字来自SHOW VARIABLES; 我不知道那孩子怎么了6G在配置文件中。检查正在使用的配置文件。也有迹象表明索引不好或编写不好的查询。改变
long_query_time=2打开slowlog。这有助于你识别恶棍。然后我们可以讨论改进其中的几个（在另一个问题中）。可能还有更多的调优项目需要讨论，但它们可能只是上述项目的产物。
细节和其他观察：
( Innodb_buffer_pool_reads ) = 45,168,170 / 87921 = 513 /sec--innodb缓冲池i/o读取速率—检查innodb缓冲池大小( Key_blocks_used * 1024 / key_buffer_size ) = 0 * 1024 / 8M = 0--使用的密钥缓冲区百分比。高水位线。-降低键缓冲区大小以避免不必要的内存使用。( innodb_buffer_pool_size / _ram ) = 8M / 8192M = 0.10%--innodb缓冲池使用的ram百分比( innodb_buffer_pool_size ) = 8M--innodb数据+索引缓存——128m（旧的默认值）非常小。( Innodb_pages_read / Innodb_buffer_pool_read_requests ) = 340,244,003 / 2770300306 = 12.3%--必须命中磁盘的读取请求—如果您有足够的ram，请增加innodb\u buffer\u pool\u大小。( (Innodb_buffer_pool_reads + Innodb_buffer_pool_pages_flushed) ) = ((45168170 + 3155389) ) / 87921 = 549 /sec--innodb i/o—增加innodb\缓冲区\池\大小？( Innodb_buffer_pool_read_ahead_evicted ) = 8,281,795 / 87921 = 94 /sec
( innodb_log_buffer_size ) = 1M--建议2mb-64mb，至少和事务中最大的blob集一样大。-调整innodb\u log\u buffer\u大小。( 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--从5.6.8开始的innodb日志循环间隔分钟，可以动态更改；一定要同时更改我的.cnf。-(旋转间隔60分钟的建议有些随意。）调整innodb\u log\u file\u大小(无法在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 d U容量。-如果驱动器可以处理，则增加innodb\u io\u容量。( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF--是否记录所有死锁。-如果你被死锁困扰，打开这个。注意：如果你有很多死锁，这可能会写很多到磁盘。( query_prealloc_size / _ram ) = 8,192 / 8192M = 0.00%--用于解析。ram百分比( query_alloc_block_size / _ram ) = 8,192 / 8192M = 0.00%--用于解析。ram百分比( Created_tmp_disk_tables ) = 234,424 / 87921 = 2.7 /sec--作为复杂选择的一部分，创建磁盘“temp”表的频率—增加tmp\u table\u size和max\u heap\u table\u size。当使用内存而不是myisam时，检查temp表的规则。也许，对模式或查询的微小更改可以避免myisam。更好的索引和查询的重新格式化更有可能有所帮助。( Created_tmp_disk_tables / Created_tmp_tables ) = 234,424 / 242216 = 96.8%--溢出到磁盘的临时表的百分比--可能会增加tmp\u table\u size和max\u heap\u table\u 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--对于并行从属线程--从属\u挂起\u作业\u大小\u最大值不能小于允许的最大\u数据包( 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语句，等等。