mysql迁移到新版本后的系统监控与性能分析

迁移后必须立刻检查的5个mysql状态变量是threads_connected、innodb_buffer_pool_pages_dirty、key_reads和key_read_requests、handler_read_rnd_next、aborted_connects，因8.0+版本统计逻辑变更易致误告警。

迁移后必须立刻检查的 5 个 MySQL 状态变量

新版本 MySQL（如 8.0.33+）对内部统计逻辑有调整，SHOW GLOBAL STATUS 中部分指标含义或采集方式已变，直接沿用旧监控脚本会导致误告警。重点盯住以下变量：

• Threads_connected：8.0 默认启用 thread_pool 插件时该值可能被池化机制干扰，需结合 performance_schema.threads 表校验真实连接数
• Innodb_buffer_pool_pages_dirty：新版本默认启用 innodb_dedicated_server 后，脏页刷盘策略更激进，若该值长期 > 1000 且 Innodb_buffer_pool_wait_free 非零，说明 I/O 压力已溢出
• Key_reads 和 Key_read_requests：8.0 移除了 MyISAM 引擎默认支持，若这两项突增，大概率是应用未适配、仍在发 SELECT SQL_CACHE 这类废弃语法，触发降级路径
• Handler_read_rnd_next：该值飙升往往意味着缺失索引导致全表扫描，但 8.0 的 optimizer_switch 默认开启 condition_fanout_filter=on，会掩盖部分执行计划劣化，需用 EXPLAIN FORMAT=TREE 复查
• Aborted_connects：8.0 强制校验密码复杂度且关闭了 old_passwords 兼容，若该值持续增长，先查 mysql.error_log 中是否含 Access denied for user ... using password: NO

慢查询日志解析要绕开 8.0 的 log_output 陷阱

MySQL 8.0 默认将慢查询日志写入 slow_log 表（log_output='TABLE'），而非文件。直接用 mysqldumpslow 或旧版 pt-query-digest 读取会失败或漏数据。

• 确认当前输出方式：

  SELECT @@global.log_output;

• 若为 'TABLE'，优先用 SQL 查询分析：

  SELECT query_time, lock_time, rows_sent, rows_examined, sql_text FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;

• 若需用 pt-query-digest，必须加 --filter '$event->{db} && $event->{db} =~ /your_db_name/' 过滤库名，否则 8.0 的 slow_log 表中 db 字段为空字符串，导致解析失败
• 注意 long_query_time 单位仍是秒（非毫秒），但 8.0 新增了 min_examined_row_limit 参数，若设为 1000，即使执行快也会因扫描行数超限记为慢查

Performance Schema 配置必须重调，否则监控失真

MySQL 8.0 默认启用更多 instruments 和 consumers，但未按生产负载调优会导致性能反损或数据缺失。

citySHOP多用户商城系统

citySHOP是一款集CMS、网店、商品、分类信息、论坛等为一体的城市多用户商城系统，已完美整合目前流行的Discuz! 6.0论坛，采用最新的5.0版PHP+MYSQL技术。面向对象的数据库连接机制，缓存及80%静态化处理，使它能最大程度减轻服务器负担，为您节约建设成本。多级店铺区分及联盟商户地图标注，实体店与虚拟完美结合。个性化的店铺系统，会员后台一体化管理。后台登陆初始网站密匙：LOVES

下载

• 关键开关检查：

  SELECT NAME, ENABLED, TIMED FROM performance_schema.setup_instruments WHERE NAME LIKE 'statement/sql/%' AND ENABLED = 'NO';

  若大量为 NO，说明 performance_schema 被过度裁剪，需在启动时加 --performance-schema-instrument='statement/sql/%=ON'
• events_statements_history_long 表默认仅存 10000 行，高并发下很快被覆盖；应根据 QPS 设置：performance_schema_events_statements_history_long_size=20000
• 避免开启 wait/lock/table/sql/handler 类别（锁等待粒度太细），它会使 performance_schema 内存占用暴涨 30%+，且多数场景只需看 events_waits_summary_by_host_by_event_name
• 8.0.27+ 版本新增 replication_applier_status_by_worker 表，主从延迟分析应优先从此表取 LAST_SEEN_TRANSACTION 和 WORKER_ID，而非依赖 Seconds_Behind_Master

sys schema 视图在 8.0 下的兼容性断点

MySQL 自带的 sys schema 在 8.0 中重构过多次，部分视图字段名、过滤逻辑或 NULL 处理方式已变，直接复用 5.7 的巡检 SQL 可能返回空结果或错误聚合。

• sys.schema_table_statistics：8.0 中 total_latency 字段单位变为皮秒（picoseconds），旧脚本若用 ROUND(total_latency/1000000000) 换算秒会少三位，应改用 sys.format_time(total_latency)
• sys.x$host_summary_by_statement_type：8.0 移除了 current_connections 字段，需改查 performance_schema.hosts 表的 HOST 和 CURRENT_CONNECTIONS
• sys.statement_analysis：默认排除 SELECT 语句（因数量过大），若需包含，必须显式设置 @sys.statement_truncate_len = 0 并调用 sys.ps_setup_show_disabled() 确认相关 instruments 已启用
• 最稳妥做法：迁移后执行 mysql_upgrade --force 并重建 sys schema，避免混用跨版本视图定义

新版本的统计口径变化比功能升级更难察觉——一个没重设的 performance_schema_events_statements_history_long_size，可能让关键慢查在你查看监控前就被覆盖掉。