SQL优化

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