抱歉，我没有看到太多令人兴奋的地方：
全球状态和变量分析：
观察：
- 版本：10.4.13-MariaDB-log
- 32 GB 内存
- 正常运行时间 = 1d 15:19:41
- 您没有在 Windows 上运行。
- 运行 64 位版本
- 您似乎完全（或大部分）运行 InnoDB。
更重要的问题：
低于建议值：
table_open_cache = 10000
tmp_table_size = 200M
max_heap_table_size = 200M
query_cache_size = 0 -- the high value you have can cause mysterious slowdowns
max_connections = 200
thread_cache_size = 20
I/O 设置非常适合 HDD 驱动器；你有固态硬盘吗？
有很多SHOW 命令——每秒不止一个。也许某些监控工具过于激进？
为什么会有这么多 GRANT？
这是在 Galera 集群中吗？
细节和其他观察：
( Key_blocks_used * 1024 / key_buffer_size ) = 48 * 1024 / 128M = 0.04% -- 使用的 key_buffer 百分比。高水位线。
-- 降低 key_buffer_size（现在为 134217728）以避免不必要的内存使用。
( table_open_cache ) = 116,660 -- 要缓存的表描述符的数量
-- 几百通常是好的。
( Open_tables / table_open_cache ) = 4,439 / 116660 = 3.8% -- 缓存使用（打开表+tmp表）
-- 可选更低的 table_open_cache（现在是 116660）
( innodb_buffer_pool_instances ) = 24 -- 对于大型 RAM，请考虑使用 1-16 个缓冲池实例，每个实例不得少于 1GB。此外，不超过 CPU 内核数量的两倍。
-- 推荐不超过16。（10.5开始消失）
( innodb_lru_scan_depth * innodb_buffer_pool_instances ) = 1,024 * 24 = 24,576 -- CPU 使用率指标。
-- 降低任一数字。
( innodb_lru_scan_depth * innodb_page_cleaners ) = 1,024 * 4 = 4,096 -- 页面清理器每秒的工作量。
-- “InnoDB: page_cleaner: 1000ms 预期循环占用了......”可以通过降低 lru_scan_depth 来修复：考虑 1000 / innodb_page_cleaners（现在是 4）。还要检查交换。
( innodb_page_cleaners / innodb_buffer_pool_instances ) = 4 / 24 = 0.167 -- innodb_page_cleaners
-- 建议将 innodb_page_cleaners（现在 4）设置为 innodb_buffer_pool_instances（现在 24）
（从 10.5 开始消失）
( innodb_lru_scan_depth ) = 1,024
-- “InnoDB: page_cleaner: 1000ms 预期循环占用了 ...” 可以通过降低 lru_scan_depth 来修复
( innodb_io_capacity ) = 200 -- 刷新时，使用这么多的 IOP。
-- 读取可能缓慢或尖刺。
( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 1,065,507 / 1538880 = 69.2% -- buffer_pool 的百分比当前未使用
-- innodb_buffer_pool_size（现在是 25769803776）比需要的大吗？
( innodb_io_capacity_max / innodb_io_capacity ) = 2,000 / 200 = 10 -- 容量：最大/普通
-- 推荐 2. Max 应该大约等于您的 I/O 子系统可以处理的 IOP。 （如果驱动器类型未知，2000/200 可能是合理的一对。）
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 7,641,841,664 / 24576M = 29.7% -- 数据占用缓冲池的百分比
-- 小百分比可能表示 buffer_pool 过大。
( innodb_log_buffer_size ) = 96M -- 建议 2MB-64MB，至少和事务中最大的 blob 一样大。
-- 调整innodb_log_buffer_size（现在是100663296）。
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 141,581 / 60 * 6144M / 2470192128 = 6,154 -- InnoDB 日志轮换之间的分钟数从 5.6.8 开始，可以动态更改；请务必同时更改 my.cnf。
-- （轮换间隔 60 分钟的建议有些武断。）调整 innodb_log_file_size（现在为 6442450944）。 （无法在 AWS 中更改。）
( default_tmp_storage_engine ) = default_tmp_storage_engine =
( innodb_flush_neighbors ) = 1 -- 将块写入磁盘时的小优化。
-- 使用 0 表示 SSD 驱动器； 1 个硬盘。
( innodb_io_capacity ) = 200 - 磁盘上每秒的 I/O 操作数。 100 用于慢速驱动器； 200 用于旋转驱动器； SSD 1000-2000；乘以 RAID 系数。
( sync_binlog ) = 0 -- 使用 1 来增加安全性，以 I/O 为代价 =1 可能会导致大量“查询结束”； =0 可能会导致“binlog 在不可能的位置”并在崩溃中丢失事务，但速度更快。
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF -- 是否记录所有死锁。
-- 如果你被死锁困扰，打开它。注意：如果你有很多死锁，这可能会写入很多磁盘。
( min( tmp_table_size, max_heap_table_size ) ) = (min( 1024M, 1024M )) / 32768M = 3.1% -- 当需要 MEMORY 表（每个表）或 SELECT 内的临时表（每个 SELECT 的每个临时表）时分配的 RAM 百分比。太高可能会导致交换。
-- 将 tmp_table_size（现在为 1073741824）和 max_heap_table_size（现在为 1073741824）减少到 1% 的内存。
( character_set_server ) = character_set_server = latin1
-- 将 character_set_server（现在是 latin1）设置为 utf8mb4 可以帮助解决字符集问题。这是未来的默认设置。
( local_infile ) = local_infile = ON
-- local_infile (now ON) = ON 是一个潜在的安全问题
( query_cache_size ) = 512M -- QC 大小
-- 太小 = 没多大用处。太大 = 开销太大。推荐0或不超过50M。
( Qcache_hits / (Qcache_hits + Com_select) ) = 8,821 / (8821 + 5602645) = 0.16% -- 命中率 -- 使用 QC 的 SELECT
-- 考虑关闭查询缓存。
( (query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache / query_alloc_block_size ) = (512M - 48787272) / 224183 / 16384 = 0.133 -- query_alloc_block_size vs 公式
-- 调整query_alloc_block_size（现在是16384）
( tmp_table_size ) = 1024M -- 限制用于支持 SELECT 的 MEMORY 临时表的大小
-- 减少 tmp_table_size（现在为 1073741824）以避免内存不足。可能不超过 64M。
( Com_admin_commands / Queries ) = 888,691 / 6680823 = 13.3% -- “管理员”命令的查询百分比。
-- 怎么回事？
( Slow_queries / Questions ) = 438,188 / 6557866 = 6.7% -- 频率（占所有查询的百分比）
-- 查找慢查询；检查索引。
( log_queries_not_using_indexes ) = log_queries_not_using_indexes = ON -- 是否包含在慢日志中。
-- 这会使慢日志变得混乱；把它关掉，这样你就可以看到真正的慢查询。并减少 long_query_time（现在为 2）以捕获最有趣的查询。
( Uptime_since_flush_status ) = 451 = 7m 31s -- 自 FLUSH STATUS（或服务器启动）以来的时间（以秒为单位）。
-- 全球状态的收集时间还不够长，无法为许多问题提供可靠的建议。解决你能解决的问题，然后在几个小时后回来。
( Max_used_connections / max_connections ) = 25 / 500 = 5.0% -- 连接的峰值百分比
-- 由于可以根据 max_connections（现在为 500）扩展几个内存因子，因此最好不要将该设置设置得太高。
( thread_cache_size / Max_used_connections ) = 500 / 25 = 2000.0%
- 让线程缓存大于您可能的连接数没有任何优势。浪费空间是缺点。
异常小：
Innodb_dblwr_pages_written / Innodb_dblwr_writes = 2.28
aria_checkpoint_log_activity = 1.05e+6
aria_pagecache_buffer_size = 128MB
innodb_buffer_pool_chunk_size = 128MB
innodb_max_undo_log_size = 10MB
innodb_online_alter_log_max_size = 128MB
innodb_sort_buffer_size = 1.05e+6
innodb_spin_wait_delay = 4
lock_wait_timeout = 86,400
performance_schema_max_mutex_classes = 0
query_cache_limit = 524,288
异常大：
Acl_column_grants = 216
Acl_database_grants = 385
Acl_table_grants = 1,877
Innodb_buffer_pool_pages_free = 1.07e+6
Innodb_num_open_files = 9,073
Memory_used_initial = 8.16e+8
Open_table_definitions = 4,278
Open_tables = 4,439
Performance_schema_file_instances_lost = 1,732
Performance_schema_mutex_classes_lost = 190
Performance_schema_table_handles_lost = 570
Qcache_free_blocks = 9,122
Qcache_total_blocks = 457,808
Tc_log_page_size = 4,096
Uptime - Uptime_since_flush_status = 141,130
aria_sort_buffer_size = 256.0MB
auto_increment_offset = 3
gtid_domain_id = 12,000
innodb_open_files = 116,660
max_heap_table_size = 1024MB
max_relay_log_size = 1024MB
min(max_heap_table_size, tmp_table_size) = 1024MB
performance_schema_events_stages_history_size = 20
performance_schema_events_statements_history_size = 20
performance_schema_events_waits_history_size = 20
performance_schema_max_cond_classes = 90
table_definition_cache = 58,863
table_open_cache / max_connections = 233
tmp_memory_table_size = 1024MB
wsrep_cluster_size = 3
wsrep_gtid_domain_id = 12,000
wsrep_local_bf_aborts = 107
wsrep_slave_threads = 32
wsrep_thread_count = 33
异常字符串：
aria_recover_options = BACKUP,QUICK
disconnect_on_expired_password = OFF
gtid_ignore_duplicates = ON
gtid_strict_mode = ON
histogram_type = DOUBLE_PREC_HB
innodb_fast_shutdown = 1
myisam_stats_method = NULLS_UNEQUAL
old_alter_table = DEFAULT
opt_s__optimize_join_buffer_size = on
optimizer_trace = enabled=off
use_stat_tables = PREFERABLY_FOR_QUERIES
wsrep_cluster_status = Primary
wsrep_connected = ON
wsrep_debug = NONE
wsrep_gtid_mode = ON
wsrep_load_data_splitting = OFF
wsrep_provider = /usr/lib64/galera-4/libgalera_smm.so
wsrep_provider_name = Galera
wsrep_provider_options = base_dir = /var/lib/mysql/; base_host = FIRST_NODE_IP; base_port = 4567; cert.log_conflicts = no; cert.optimistic_pa = yes; debug = no; evs.auto_evict = 0; evs.causal_keepalive_period = PT1S; evs.debug_log_mask = 0x1; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.info_log_mask = 0; evs.install_timeout = PT7.5S; evs.join_retrans_period = PT1S; evs.keepalive_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.use_aggregate = true; evs.user_send_window = 2; evs.version = 1; evs.view_forget_timeout = P1D; gcache.dir = /var/lib/mysql/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = galera.cache; gcache.page_size = 128M; gcache.recover = yes; gcache.size = 1024M; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.listen_addr = tcp://0.0.0.0:4567; gmcast.mcast_addr = ; gmcast.mcast_ttl = 1; gmcast.peer_timeout = PT3S; gmcast.segment = 0; gmcast.time_wait = PT5S; gmcast.version = 0; ist.recv_addr = FIRST_NODE_IP; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; pc.linger = PT20S; pc.npvo = false; pc.recovery = true; pc.version = 0; pc.wait_prim = true; pc.wait_prim_timeout = PT30S; pc.weight = 1; protonet.backend = asio; protonet.version = 0; repl.causal_read_timeout = PT30S; repl.commit_order = 3; repl.key_format = FLAT8; repl.max_ws_size = 2147483647; repl.proto_max = 10; socket.checksum = 2; socket.recv_buf_size = auto; socket.send_buf_size = auto;
wsrep_provider_vendor = Codership Oy
wsrep_provider_version = 26.4.4(r4599)
wsrep_replicate_myisam = ON
wsrep_sst_auth = ********
wsrep_sst_method = mariabackup
wsrep_start_position = 353e0616-cb37-11ea-b614-be241cab877e:39442474