索引

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 高并发场景下的性能优化 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 看起来并不算慢。 但当大量请求同时进入数据库后，数据库真正面对的是： 大量连接 ↓ 大量 SQL ↓ 大量索引访问 ↓ 大量数据页 ↓ 大量事务 ↓ 锁竞争 ↓ 磁盘 / CPU / 内存压力 因此：...

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 提供了关系型业务系统通常需要的核心能力： 事务 行级锁 MVCC 崩溃恢复...

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....