惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
罗磊的独立博客
The GitHub Blog
The GitHub Blog
V
V2EX
Last Week in AI
Last Week in AI
博客园 - 聂微东
MyScale Blog
MyScale Blog
美团技术团队
L
LangChain Blog
博客园 - Franky
腾讯CDC
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园_首页
S
SegmentFault 最新的问题
爱范儿
爱范儿
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Stack Overflow Blog
Stack Overflow Blog
量子位
小众软件
小众软件
宝玉的分享
宝玉的分享
J
Java Code Geeks
Google DeepMind News
Google DeepMind News
D
Docker
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报

博客园_首页

Linux实操--组管理、权限管理和定时任务 Java + EasyExcel 实现单个接口导出多个Excel Mem0 源码解析系列(二):提示词工程的深度剖析 Openclaw TaskFlow究竟是什么?和普通Skill技能有什么区别 博文阅读密码验证 - 博客园 嘉立创开源:应该是全网MicroPython教程最多的开发板 Hermes Agent 集成实践:从协议到生产 2026年AI编程工具横评:Cursor、Codex、Claude Code、Zed、Windsurf Java程序员必看的RAG入门教程 2026 AI效率神器:Superpowers + Claude Code 保姆级教程 本地大模型部署全攻略:从 0 到 1 玩转 Ollama 【从0到1构建一个ClaudeAgent】内存管理-上下文压缩 .NET 高级开发 | 设计、实现一个事件总线框架 电子小白入门之NE555 3. WorkBuddy:隐藏玩法,一键召唤专家,让 AI 以"专家身份"给你干活 和AI一起搞事情#3:Claude Teammate 游戏开发翻车实录 【OpenClaw】通过 Nanobot 源码学习架构---(7)Memory C# .NET 周刊|2026年3月3期 我在 Debian 11 上把 K8s 单机搭起来了,过程没你想的那么顺(/opt 目录版) 深度学习进阶(七)Data-efficient Image Transformer CLI+Skill搭建浏览器AI自动化框架,告别一切重复枯燥任务 告别Token账单无底洞:OpenClaw本地部署,重塑企业数据主权的唯一解 FastAPI+Vue:文件分片上传+秒传+断点续传,这坑我帮你踩平了! SBTI 爆火后,我做了个程序员版的 CBTI。。已开源 + 附开发过程 多模态检索开始进入工程期:用 Sentence Transformers 搭建可落地的 Multimodal RAG 100多行代码实现一个最简单的Agent(用ReAct) Claude Code 通关手册(八):推荐 5 个 Hooks,代码质量提升 3 倍 老板:“有人截图了!”。安全部门:“收到,马上查暗水印!” - why技术 技术之外,皆是人间 C#/.NET/.NET Core技术前沿周刊 | 第 69 期(2026年4.01-4.12)
MySQL 性能调优完全指南:从硬件到 SQL,一篇吃透
窥视未来 · 2026-04-26 · via 博客园_首页

MySQL 性能调优是后端开发与运维的必备技能。然而,调优并非单一操作,而是涉及硬件、配置、架构、SQL 等多个维度的系统工程。本文结合实战笔记,系统梳理 MySQL 性能优化的方法论与核心技巧,助你快速定位瓶颈、提升数据库吞吐量。

一、优化从何入手?

数据库处理一个请求,会经过客户端连接、查询缓存、SQL 解析、查询优化、存储引擎、磁盘 I/O 等多个环节,每个环节都可能成为瓶颈。

image-20230827194457356

优化维度全景图

维度常见手段
硬件 使用 SSD、RAID10 阵列、增加内存
连接 调整 max_connections、减少应用端连接数
配置 优化 innodb_buffer_pool_size、日志刷新策略
缓存 引入 Redis/Memcached 做前置缓存
架构 主从复制、读写分离、分库分表
SQL & 索引 慢查询分析、执行计划优化、索引设计

二、硬件与基础配置优化

2.1 硬件建议

  • 磁盘:使用 RAID10(兼顾 RAID0 的性能 + RAID1 的可靠性)

  • 内存:越大越好,InnoDB 会将其用作缓存

  • CPU:高频优于多核(多数场景)

2.2 关键 MySQL 配置(my.cnf)

# InnoDB 缓冲池大小(专用服务器建议设置物理内存的 70%~80%)
innodb_buffer_pool_size = 4G

# 连接数
max_connections = 500
max_user_connections = 50

# 日志刷盘策略(非金融级可设为 2 提升写入性能)
innodb_flush_log_at_trx_commit = 2
sync_binlog = 1

# 独立表空间
innodb_file_per_table = 1

# 慢查询日志
slow_query_log = 1
long_query_time = 0.5
slow_query_log_file = /var/lib/mysql/mysql-slow.log

# 默认存储引擎
default-storage-engine = InnoDB

说明:innodb_flush_log_at_trx_commit = 2 表示每秒刷盘,性能好但可能丢失 1 秒数据;=1 最安全但最慢

三、架构优化

当单库无法承载负载时,需要从架构层面突破

历史演进

image

3.1 主从复制与读写分离

1354459428

  • 异步复制:主库提交后立即返回,不等待从库。延迟可能较大。

  • 半同步复制:至少一个从库接收 binlog 并写入 relay log 后才返回。可减少数据丢失风险。

启用半同步(需安装插件):

-- 主库安装
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
-- 从库安装
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
  • GTID 复制:全局事务 ID,简化主从切换和故障恢复。开启方式:

gtid_mode = ON
enforce_gtid_consistency = ON

  读写分离:借助中间件(如 ProxySQL、HAProxy)将写请求发往主库,读请求均衡分发到从库。

image

3.2 高可用方案对比

方案特点
MHA / MMM 成熟,需要多个节点,切换时间秒级
MGR(MySQL Group Replication) 官方原生,支持多主,强一致性
Galera Cluster 多主同步,无延迟,但写扩展有限
Keepalived + 主从 简单,但需要配合虚拟 IP 和脚本

3.3 分库分表

当单表数据量达到千万级甚至亿级,分库分表是必然选择。

  • 垂直分库:按业务模块拆分(如订单库、用户库),降低单库压力。

  • 垂直分表:将宽表切分成主表 + 扩展表(如把 textblob 字段独立)。

  • 水平分表:按某个键(如用户 ID、时间)将数据分散到多张结构相同的表中。

 单库

image

 垂直分库

image

 垂直分表

image

 逆规范化:适当增加冗余字段,减少 JOIN 查询,提高读性能。适合读多写少的场景。

四、SQL 优化实战

4.1 打开慢查询日志

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.5;   -- 0.5 秒

使用 mysqldumpslow 分析:

mysqldumpslow -s t -t 20 /var/lib/mysql/mysql-slow.log

4.2 使用 profiling 查询单条 SQL 耗时

SET profiling = 1;
SELECT * FROM user WHERE id = 1;
SHOW PROFILES;
SHOW PROFILE FOR QUERY 1;

4.3 EXPLAIN 执行计划分析

EXPLAIN 是 SQL 优化的核心工具。示例:

EXPLAIN SELECT t.tname, c.cname, tc.phone
FROM teacher t, course c, teacher_contact tc
WHERE t.tid = c.tid AND t.tcid = tc.tcid AND (c.cid = 2 OR tc.tcid = 3);

关键列解读:

列名含义
id 查询序号,越大越先执行;相同则顺序执行
select_type SIMPLE(简单查询)、PRIMARY(主查询)、SUBQUERY
(子查询)、DERIVED(派生表)、UNION 等
type 连接类型,性能从高到低system > const > eq_ref > ref > range > index > ALL
possible_keys 可能用到的索引
key 实际使用的索引
key_len 使用的索引长度(字节),帮助判断联合索引中使用了哪些列
rows 预估扫描的行数
Extra 额外信息,如 Using index(覆盖索引)、Using filesort(文件排序,需要优化)、Using temporary(使用临时表)

type 优化目标:至少达到 range,争取 ref 或 const

小技巧key_len 计算示例(utf8mb4 每个字符 4 字节)
若 phone varchar(11) 且 utf8mb4,索引长度 ≈ 11×4 + 2 = 46 字节。

五、索引与表结构优化

5.1 索引使用原则

  • 在 WHERE、JOIN、ORDER BY、GROUP BY 涉及的列上建立索引

  • 区分度高的列优先

  • 联合索引遵循最左前缀原则

  • 避免索引失效:LIKE '%xxx'、函数操作、隐式类型转换、OR 条件等

5.2 表结构优化实例

垂直拆分(适用于表过宽或含大字段):

- 原表
CREATE TABLE article (id INT, title VARCHAR(200), content TEXT, ...);
-- 拆分后
CREATE article_base (id INT, title VARCHAR(200));
CREATE article_content (id INT, content TEXT);

 水平拆分(按时间或 ID 范围):

-- 按年份分区,或使用应用层路由到 order_2023、order_2024 等

六、锁机制与死锁分析

6.1 InnoDB 锁类型

  • 行锁:锁定单行记录(Record Lock)

  • 间隙锁:锁定范围(Gap Lock),防止幻读

  • Next-Key Lock = 行锁 + 间隙锁,RR 隔离级别下默认使用

6.2 死锁的四个必要条件

  1. 两个或以上事务

  2. 锁资源不兼容(排他锁互斥)

  3. 每个事务持有锁并申请新锁

  4. 循环等待

示例死锁演示

事务 A事务 B
BEGIN; SELECT * FROM user WHERE id=3 FOR UPDATE;  
  BEGIN; DELETE FROM user WHERE id=4;
UPDATE user SET name='mimi' WHERE id=4;(等待 B 释放) (等待 A 释放 id=3 的锁)→ 死锁

6.3 查看与处理死锁

-- 查看当前锁等待的信息
SHOW STATUS LIKE 'innodb_row_lock%';

-- 查看正在运行的事务
SELECT * FROM information_schema.innodb_trx;

-- 查看锁详细信息(MySQL 8.0)
SELECT * FROM performance_schema.data_locks;
SELECT * FROM sys.innodb_lock_waits;

发现阻塞线程后,可使用 KILL <thread_id> 终止。

6.4 避免死锁的建议

  • 多表操作按固定顺序访问

  • 将大事务拆分为多个小事务

  • 降低隔离级别(如 RR → RC,可减少间隙锁)

  • 为表添加合理索引,避免表锁升级

七、常用监控命令速查

-- 查看当前连接
SHOW PROCESSLIST;
SELECT * FROM information_schema.PROCESSLIST;

-- 查看各 SQL 执行次数
SHOW GLOBAL STATUS LIKE 'Com_%';

-- 查看服务端变量
SHOW VARIABLES LIKE '%connect%';
SHOW VARIABLES LIKE 'slow_query_log';

-- 查看表锁情况
SHOW GLOBAL STATUS LIKE 'table_locks%';

-- 查看打开文件数
SHOW GLOBAL STATUS LIKE 'open_files';

八、总结:调优路线图

阶段核心动作
1. 硬件层 升级 SSD、增加内存、使用 RAID10
2. 配置层 调整 innodb_buffer_pool_size、连接数、日志刷盘策略
3. 架构层 读写分离、主从半同步、分库分表、引入缓存
4. SQL 层 开启慢查询日志、分析 EXPLAIN、优化索引、避免全表扫描
5. 锁层面 减少长事务、合理设计索引、降低隔离级别(若业务允许)

最后,记住一条真理:没有任何一次调优是“无脑加配置”能解决的,必须结合业务特点与监控数据,循序渐进。