MySQL on 追风笔记

MySQL 索引原理与最佳实践

Tue, 25 Aug 2026 00:00:00 +0000

索引是 MySQL 查询性能的决定性因素。理解 InnoDB 的 B+Tree 索引结构，才能写出真正命中索引的 SQL。

B+Tree 与聚簇索引

InnoDB 使用 B+Tree 组织索引，其特点是非叶子节点只存索引键用于导航，所有数据都落在叶子节点，且叶子节点通过双向链表串联，非常适合范围扫描。

InnoDB 的主键索引是聚簇索引，叶子节点直接存放整行数据；二级索引的叶子节点存放「索引键 + 主键值」。因此通过二级索引查询非索引列时，需要再用主键回表查聚簇索引。

回表与覆盖索引

当查询的列都在二级索引中时，无需回表，称为覆盖索引，性能更好：

-- idx_user_age 为 (name, age) 的联合索引
-- 仅取索引列，命中覆盖索引
SELECT name, age FROM user WHERE name = 'tom';

若 SELECT * 还需要 phone 等额外列，则会触发回表。高频查询应优先设计为覆盖索引。

最左前缀原则

联合索引 (a, b, c) 能生效的条件是查询从最左列开始连续匹配：

WHERE a = ? 可用
WHERE a = ? AND b = ? 可用
WHERE b = ? 无法使用该联合索引（断开了最左前缀）

避免索引失效

常见导致索引失效的写法：

MySQL 事务与锁机制

Tue, 25 Aug 2026 00:00:00 +0000

并发场景下，事务与锁共同保证了数据的一致性。InnoDB 通过 MVCC 与锁的协同，在性能与隔离性之间取得平衡。

ACID 与隔离级别

事务的 ACID 由不同机制保障：原子性靠 undo log，持久性靠 redo log，隔离性靠 MVCC 与锁，一致性是最终目标。

SQL 标准定义四种隔离级别，InnoDB 默认 REPEATABLE READ：

READ UNCOMMITTED：可能脏读
READ COMMITTED：避免脏读，可能不可重复读
REPEATABLE READ：避免不可重复读（InnoDB 额外避免幻读）
SERIALIZABLE：完全串行，性能最低

MVCC 与日志

MVCC（多版本并发控制）让读不加锁、读写不阻塞。每行记录隐含 trx_id 与 roll_pointer，通过 undo log 构建历史版本，配合 ReadView 判断某版本对当前事务是否可见。

undo log：记录数据修改前的镜像，用于回滚与构建旧版本。
redo log：记录物理页修改，保证崩溃后已提交事务不丢失（WAL 机制）。

行锁、间隙锁与 Next-Key Lock

InnoDB 默认使用行锁，但「锁的是索引记录」而非行本身。在 REPEATABLE READ 下，为解决幻读引入：

行锁（Record Lock）：锁住具体索引记录。
间隙锁（Gap Lock）：锁住索引记录之间的间隙，阻止插入。
Next-Key Lock：行锁 + 间隙锁，锁定左开右闭的区间。

-- 在 (10, 20] 区间加 Next-Key Lock，阻止其他事务插入 id=15
SELECT * FROM t WHERE id BETWEEN 10 AND 20 FOR UPDATE;

死锁成因与排查

死锁通常由两个事务以相反顺序获取锁引起。排查手段：

分库分表不是银弹

Mon, 15 Jun 2026 00:00:00 +0000

分库分表在很多团队是一种默认操作：数据量一大就分。但它换来的收益很窄，付出的代价很宽，而且代价大多在上线半年后才开始显现。

先问要不要分

分库分表真正解决的问题只有两个：单表数据量导致的索引效率下降，以及单库写入的 IOPS 瓶颈。除此之外的问题它都解决不了，甚至会恶化。

在决定分之前，这几件事的性价比更高：

加索引或改查询。慢查询里相当大一部分是索引缺失或者写法导致索引失效，跟数据量无关。
冷热分离。交易流水表里九成查询集中在最近三个月。把历史数据归档到历史库，主表立刻瘦身，成本远低于分表。
读写分离。读多写少的场景加从库就够了。
升配。听起来不体面，但一台高配实例能撑到的量往往超出预期，而且省下的是人力。

我的经验阈值：单表超过两千万行且增长稳定、或者写入已经打满 IO，才考虑分表。仅仅因为"数据量看着挺大"就分，是给自己找活干。

分片键决定生死

分片键选错基本没法补救——除非停机重新迁移全量数据。

选择原则是让高频查询都能带上分片键。交易流水表用账号分片，那么"查某账号最近流水"就是单分片查询，性能很好；但"查某商户当天全部流水"就变成了全分片扫描加内存聚合。

-- 单分片，走得很好
SELECT * FROM txn_flow
 WHERE account_no = '6222...1234'
 AND txn_date >= '2026-06-01'
 ORDER BY txn_date DESC LIMIT 20;

-- 跨全部分片，聚合在应用层做，分片多了就是灾难
SELECT merchant_no, SUM(amount) FROM txn_flow
 WHERE txn_date = '2026-06-14'
 GROUP BY merchant_no;

第二类需求不要靠分片库硬扛，应该走另一条路：同步一份到 OLAP 引擎或数仓。一份数据满足所有查询模式的想法本身就是问题的根源。

另外一定要一次性把逻辑分片数定足。我们定了 1024 个逻辑分片映射到 8 个物理库，扩容时只搬分片区间，不用重新哈希。如果直接按物理库取模，第一次扩容就要迁移全量数据。