事务 on Leanku 的博客

MySQL 高并发场景下的性能优化

Fri, 19 Jul 2024 00:00:00 +0000

MySQL 高并发场景下的性能优化

MySQL 的性能优化并不是简单地给表增加几个索引。

在真实的高并发系统中，数据库性能通常受到多个因素共同影响：

应用请求
 ↓
数据库连接
 ↓
SQL 执行
 ↓
索引
 ↓
Buffer Pool
 ↓
锁 / 事务
 ↓
磁盘 I/O

当并发量继续增加以后，还会遇到：

连接数过高
SQL 执行时间增加
锁竞争
事务堆积
Buffer Pool 压力
磁盘 I/O
CPU 使用率
Redo Log 压力

因此，高并发 MySQL 优化应该从整个访问链路出发，而不是只盯着 SQL。

1. 高并发下 MySQL 为什么容易成为瓶颈

假设一个系统每秒有：

5000 QPS

其中：

80% 查询
20% 写入

那么数据库每秒需要处理：

4000 次查询
1000 次写入

如果单条 SQL 平均执行：

10 ms

看起来并不算慢。

MySQL Redo Log、Undo Log 与 Binlog

Sun, 23 Jun 2024 00:00:00 +0000

MySQL Redo Log、Undo Log 与 Binlog

在学习 MySQL InnoDB 时，经常会遇到三个日志：

Redo Log
Undo Log
Binlog

它们名字相似，但解决的问题完全不同。

简单来说：

Redo Log
→ 数据库崩溃后，恢复已经发生的修改

Undo Log
→ 事务回滚、MVCC

Binlog
→ 记录数据库逻辑变更，用于复制、恢复等

其中最容易混淆的是：

为什么 InnoDB 已经有 Redo Log 了，MySQL 还需要 Binlog？

原因在于 Redo Log 和 Binlog 所处的层次、记录内容和设计目标并不相同。

理解三者的关系，也是理解 MySQL 事务提交和主从复制的基础。

1. 为什么数据库需要日志

假设执行：

UPDATE users
SET balance = balance - 100
WHERE id = 1;

最简单的想法是：

修改内存
↓
直接把数据写入磁盘
↓
完成

但真实数据库不能简单这样做。

MySQL InnoDB 存储引擎详解

Fri, 21 Jun 2024 00:00:00 +0000

MySQL InnoDB 存储引擎详解

InnoDB 是 MySQL 8 默认的存储引擎，也是绝大多数业务系统使用的核心存储引擎。

前面介绍索引、事务、锁和死锁时，很多机制实际上都建立在 InnoDB 的内部结构之上。

例如：

为什么 InnoDB 的索引查询通常很快？
为什么主键设计会影响二级索引大小？
为什么更新数据不一定立即写入磁盘？
Buffer Pool 到底有什么作用？
Redo Log 为什么能够提高写入性能？
InnoDB 为什么能够支持事务和崩溃恢复？

要理解这些问题，需要从 InnoDB 的存储结构开始。

1. InnoDB 是什么

MySQL 本身并不负责所有数据存储工作。

可以简单理解为：

MySQL Server
 ↓
SQL 解析 / 优化 / 执行
 ↓
Storage Engine
 ↓
InnoDB
 ↓
数据文件 / 日志文件

存储引擎负责真正的数据存储和访问。

早期 MySQL 中存在多种存储引擎，例如：

InnoDB
MyISAM
Memory
Archive

现代 OLTP 系统中，InnoDB 是最重要的选择。

InnoDB 提供了关系型业务系统通常需要的核心能力：

MySQL 死锁：产生原因、分析与解决

Mon, 13 Nov 2023 00:00:00 +0000

MySQL 死锁：产生原因、分析与解决

在高并发系统中，数据库死锁是比较常见的问题。

很多开发者第一次遇到死锁时，会认为：

数据库是不是出问题了？

实际上，死锁本身并不意味着 MySQL 出现了故障。对于 InnoDB 来说，死锁是并发事务之间形成循环等待后，由存储引擎主动检测并处理的一种正常机制。

真正需要解决的问题不是简单地“关闭死锁”，而是：

为什么会产生死锁？
哪些 SQL 导致了循环等待？
为什么某个事务被回滚？
如何从根本上减少死锁？
应用程序收到死锁异常后应该怎么处理？

理解这些问题，才能正确处理生产环境中的死锁。

1. 什么是死锁

死锁（Deadlock）是指两个或多个事务互相持有对方需要的锁，同时等待对方释放锁，最终形成循环等待。

例如有两个账户：

账户 1
账户 2

事务 A：

锁住账户 1
 ↓
等待账户 2

事务 B：

锁住账户 2
 ↓
等待账户 1

最终形成：

事务 A → 等待事务 B 持有的锁
事务 B → 等待事务 A 持有的锁

这就是典型的死锁。

需要注意，死锁和锁等待不是一回事。

普通锁等待可能是：

事务 A 持有锁
 ↓
事务 B 等待事务 A

只要事务 A 最终提交或回滚，事务 B 就可以继续执行。

MySQL InnoDB 锁机制详解

Fri, 21 Jul 2023 00:00:00 +0000

MySQL InnoDB 锁机制详解

在并发业务中，多个事务可能同时修改或者读取相同的数据。如果没有并发控制，就可能出现脏写、数据覆盖、幻读等问题。

InnoDB 通过锁机制和 MVCC 等机制共同实现事务的并发控制。

例如两个事务同时修改同一条订单：

UPDATE orders
SET status = 2
WHERE id = 100;

如果事务 A 尚未提交，事务 B 同时执行相同的 UPDATE，那么事务 B 通常不能立即完成，而是需要等待事务 A 释放相关锁。

因此，理解 InnoDB 锁机制，对于分析以下问题非常重要：

为什么 UPDATE 会等待？
为什么 SELECT 有时候也会加锁？
为什么一个 UPDATE 影响了一行，却可能产生多个锁？
为什么会出现 Gap Lock？
为什么会发生死锁？

1. InnoDB 为什么需要锁

假设账户余额为：

balance = 1000

事务 A：

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

同时事务 B：

UPDATE accounts
SET balance = balance - 200
WHERE id = 1;

如果两个事务完全不进行并发控制，就可能发生：