索引 on Leanku 的博客

MySQL 深分页优化：LIMIT 为什么越来越慢

Mon, 09 Sep 2024 00:00:00 +0000

MySQL 深分页优化：LIMIT 为什么越来越慢

在后台管理、订单查询、文章列表等业务中，分页几乎是最常见的 SQL 场景之一。

最常见的写法是：

SELECT id, title, created_at
FROM articles
ORDER BY id DESC
LIMIT 20 OFFSET 1000000;

刚开始数据量比较小时，这种分页方式没有明显问题。但随着数据量增长，翻到后面的页码后，查询速度可能明显下降。

很多人会简单地认为：

LIMIT OFFSET 会越来越慢，因为数据库扫描了很多数据。

这个说法没错，但还不够准确。真正需要理解的是：数据库为了找到第 1000001 条记录，通常仍然需要定位并跳过前面的 1000000 条符合条件的记录。

因此，深分页优化的核心并不是简单地给 LIMIT 加索引，而是要改变分页数据的定位方式。

1. 什么是深分页

假设 articles 表有 1000 万条数据：

SELECT id, title, created_at
FROM articles
ORDER BY id DESC
LIMIT 20 OFFSET 0;

查询第一页：

跳过 0 条
读取 20 条

查询第 100 页：

LIMIT 20 OFFSET 1980;

需要跳过约 1980 条记录。

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 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 JOIN 原理与优化

Fri, 04 Aug 2023 00:00:00 +0000

MySQL JOIN 原理与优化

JOIN 是关系型数据库中最常见的操作之一。用户、订单、商品、文章、评论等业务数据通常分散在不同表中，查询时再通过关联关系组合起来。

例如：

SELECT
 o.id,
 o.order_no,
 u.username
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.status = 1;

这条 SQL 看起来很简单，但 MySQL 实际需要解决几个问题：

使用哪张表作为驱动表？
↓
如何找到另一张表对应的数据？
↓
是否能够使用索引？
↓
需要扫描多少行？
↓
最终执行成本是多少？

因此，JOIN 优化并不是简单地“少 JOIN 几张表”，真正重要的是理解 JOIN 的执行方式、数据访问路径以及索引设计。

1. JOIN 的基本原理

假设有两张表：

users
+----+----------+
| id | username |
+----+----------+
| 1 | Alice |
| 2 | Bob |
| 3 | Tom |
+----+----------+

orders
+----+---------+---------+
| id | user_id | amount |
+----+---------+---------+
| 1 | 1 | 100.00 |
| 2 | 1 | 200.00 |
| 3 | 2 | 300.00 |
+----+---------+---------+

执行：