MySQL性能优化是围绕监控、分析、迭代和规范的长期工程实践，需建立反馈闭环、性能基线、分层排查、灰度验证及开发协同机制。
持续优化 MySQL 性能不是一次性的“调参任务”，而是一套围绕监控、分析、迭代和规范的长期工程实践。核心在于建立反馈闭环：观察真实负载 → 定位瓶颈 → 小步验证 → 固化改进 → 持续跟踪。
建立可回溯的性能基线与监控体系
没有基准，就无法判断优化是否有效。上线前、版本迭代后、业务高峰期前后，都应采集关键指标作为基线。
- 必须采集的指标：QPS/TPS、慢查询数量及平均耗时、InnoDB 缓冲池命中率（red">innodb_buffer_pool_hit_rate）、锁等待时间、连接数使用率、主从延迟（如适用）
- 推荐工具组合：Percona Toolkit（pt-query-digest 分析慢日志）、Prometheus + Grafana（可视化趋势）、MySQL Performance Schema（实时诊断）、定期导出 SHOW ENGINE INNODB STATUS 和 SHOW PROCESSLIST
- 关键动作：将慢查询日志开启并保留至少7天；为每个应用服务打标（如用 init_connect 设置 application_name），便于归因分析
以查询生命周期为线索做分层优化
一条 SQL 的性能受多个层级影响，需逐层排查，避免盲目调大 buffer_pool_size 或禁用 query_cache。
- 客户端层：检查是否批量操作被拆成单条执行（如循环 insert）；确认连接是否复用（避免频繁 connect/disconnect）；评估 ORM 是否生成了 N+1 查询或冗余字段
- SQL 层：用 EXPLAIN FORMAT=JSON 看执行计划，重点关注 type（是否用到索引）、key（实际使用的索引）、rows_examined（扫描行数）、filtered（过滤率）；警惕 Using filesort 和 Using temporary
- 索引层：遵循“最左前缀 + 区间列靠右 + 覆盖索引优先”原则；删除长期未被使用的索引（可通过 sys.schema_unused_indexes 查看）；对高频更新的宽表，谨慎添加过多二级索引
- 存储引擎层：确认表格式为 InnoDB；检查 innodb_file_per_table=ON；根据读写比例调整 innodb_buffer_pool_size（通常设为物理内存的 50%–75%，但需预留系统及其他进程空间）
构建可持续的变更管理与验证机制
任何配置调整或 SQL 改写都必须经过可控验证，防止“优化变劣化”。
- 灰度发布流程：在从库或影子库中先执行新索引 / 新 SQL；用 pt-upgrade 对比新旧执行计划与耗时；通过流量回放（如 pt-log-player + tcpdump）验证效果
- 配置变更守则：禁止直接修改生产实例的全局变量；所有 my.cnf 变更需走配置中心或 IaC（如 Ansible）管理，并附带变更原因与回滚步骤；每次只改一个参数，观察至少2个业务高峰周期
- 自动化巡检项：每日检查慢查询 TOP 10 是否有新增；每周扫描是否存在 SELECT *、全表扫描、无主键表；每月 review 表碎片率（DATA_FREE / DATA_LENGTH > 20% 建议 OPTIMIZE TABLE）
推动开发与 DBA 协同的性能文化
性能问题 70% 源于设计与编码阶段。长期优化离不开流程嵌入和能力共建。
- 上线卡点：在 CI/CD 流程中加入 SQL 审核环节（如使用 Alibaba Cloud DMS、Yearning 或自建 SQLAdvisor 接口），拦截缺失 WHERE、未走索引、隐式转换等高危语句
- 开发赋能：提供《MySQL 开发规范手册》（含建表模板、索引建议、分页写法、事务边界说明）；组织季度“慢查复盘会”，用真实案例讲解执行计划误判原因
- 数据生命周期管理：对日志类、行为埋点类大表，强制分区（按时间 RANGE）+ 归档策略（如使用 pt-archiver）；冷热数据分离，避免单库承载全部历史
不复杂但容易忽略。真正的长期调优，是把性能意识变成日常习惯，把临时救火变成标准动作，把个人经验沉淀为团队资产。
