标签: MySQL

并发场景下，事务与锁共同保证了数据的一致性。InnoDB 通过 MVCC 与锁的协同，在性能与隔离性之间取得平衡。 ACID 与隔离级别 事务的 ACID 由不同机制保障：原子性靠 undo log，持久性靠 redo log，隔离性靠 MVCC 与锁，一致性是最终目标。 SQL 标准定义四种隔离级别，InnoDB 默认 REPEATABLE READ： READ UNCOMMITTED：可能脏读 READ COMMITTED：避免脏读，可能不可重复读 REPEATABLE READ：避免不可重 …

索引是 MySQL 查询性能的决定性因素。理解 InnoDB 的 B+Tree 索引结构，才能写出真正命中索引的 SQL。 B+Tree 与聚簇索引 InnoDB 使用 B+Tree 组织索引，其特点是非叶子节点只存索引键用于导航，所有数据都落在叶子节点，且叶子节点通过双向链表串联，非常适合范围扫描。 InnoDB 的主键索引是聚簇索引，叶子节点直接存放整行数据；二级索引的叶子节点存放「索引键 + 主键值」。因此通过二级索引查询非索引列时，需要再用主键回表查聚簇索引。 回表与覆盖索引 当查询的列 …

分库分表在很多团队是一种默认操作：数据量一大就分。但它换来的收益很窄，付出的代价很宽，而且代价大多在上线半年后才开始显现。 先问要不要分 分库分表真正解决的问题只有两个：单表数据量导致的索引效率下降，以及单库写入的 IOPS 瓶颈。除此之外的问题它都解决不了，甚至会恶化。 在决定分之前，这几件事的性价比更高： 加索引或改查询。慢查询里相当大一部分是索引缺失或者写法导致索引失效，跟数据量无关。 冷热分离。交易流水表里九成查询集中在最近三个月。把历史数据归档到历史库，主表立刻瘦身，成本远低于分表。 …