共 3 篇相关文章
这篇文章深入探讨了 InnoDB 日志体系中的核心内容——“日志本身”。作者聚焦于 redo log 与 undo log 这两类关键日志，详细拆解了它们各自记录的内容、结构以及在不同事务场景下的协作方式。 文章清晰地对比了二者的根本差异：redo log 记录的是页面物理修改的“结果”，用于保证事务的持久性；而 undo log 记录的是逻辑操作的“逆过程”，用于支持事务回滚和 MVCC 实现。这种对比不仅停留在概念层面，还结合了事务提交、崩溃恢复等具体流程，阐释了为什么必须同时需要这两类日志。 文中对日志块结构、LSN 推进、checkpoint 机制的剖析尤为细致，揭示了 InnoDB 如何通过精密的日志设计来平衡写入性能与数据安全性。对于想要理解 MySQL 底层存储引擎如何实现 ACID 特性的开发者而言，这篇分析提供了扎实的原理依据。
这篇从MySQL存储引擎的底层差异讲起，清晰地梳理了索引这一核心概念。作者没有一上来就堆砌定义，而是先带你理解不同存储引擎（如InnoDB与MyISAM）在数据存储上的根本区别——行数据与索引的组织方式截然不同，这直接决定了索引的具体实现与效率。 文章的重点放在了B+树索引的结构解析上，用形象的比喻说明了其非叶子节点仅存储键值如何提升查询效率。更关键的是，它对比了聚簇索引与二级索引的数据分布，点明了在InnoDB中主键索引即数据本身的独特设计，以及二级索引需要回表查询的开销来源。文中还提到了覆盖索引这一优化技巧，解释了当查询字段完全被索引覆盖时，如何避免回表，显著提升性能。 通过具体的查询场景（如范围查询与等值查询），作者最终给出了一些实践建议：索引并非越多越好，选择区分度高的列建立索引、注意最左前缀原则才是关键。整篇内容抽丝剥茧，将索引从理论到实践的要点讲得透彻且实用。
这篇讲的是数据库索引中一个容易被忽视但影响巨大的问题——“数据分布不均衡”。作者从一个实际场景出发，探讨了当索引列的值分布极不平衡（例如，某个值占据了99%的数据）时，常规的查询优化策略为何会失效，甚至导致性能骤降。 文章深入分析了这种“不平衡索引”带来的负面影响：基于代价的优化器可能会错误地选择全表扫描而非索引扫描，使得精心设计的索引形同虚设。作者不仅指出了问题，更给出了实用的诊断方法，比如如何通过`ANALYZE`查看统计信息，以及观察`EXPLAIN`输出中的关键指标。 针对这一困境，文章对比了几种可行的解决方案。例如，可以考虑使用函数索引对数据进行转换以实现平衡，或者在业务允许的情况下，直接使用常量索引来处理这种极端偏斜的查询。最后，作者提醒大家，在设计表结构和索引时，预先考察数据分布的特征至关重要。这篇文章为开发者理解和解决索引性能的“隐性陷阱”提供了清晰的思路。
