Chlapis的博客

也就是说，虽然每次都只返回 n 条记录，但是每次查询都要查询 m+n 行数据。所以，对于大表的查询，越到后面 m 越大，要扫描的记录也就越多。所以我们需要优化下这个多余的查询，即想办法做到不扫描前 m 行记录，只扫描后 n 行记录。

在工作中，你有没有遇到过这样的问题：明明建立了索引，也使用了索引字段作为查询条件，但是查询还是很慢。查看执行计划发现，数据库并没有使用索引扫描，而是走了全表扫描。那么为什么建立了索引，数据库还是走了全表扫描呢？今天我们就来盘点一些场景，看看索引失效的原因。在这之前，我觉得非常有必要先复习一下索引结构，因为当你对索引结构有了充分的认识以后，很多索引失效的原因就一目了然了。本文盘点了各种一些导致索引失效的场景，大部分都是有规则可以遵循的，这类场景只要我们了解了索引结构，基本上都能快速分辨出来；

在实际生产中，大部分业务都需要从多张数据表中读取数据。在实现上，我们可以使用单表查询，在代码层实现关联；当然更多的时候，我们会使用 关键字 join。 join 用于多表联合查询，直接在数据库层将多张表的数据拼接起来，不用再去代码层实现关联。

Change Buffer 只是一个统称，实际上它包含三个类型： Insert Buffer、Delete Buffer 和 Purge Buffer，分别对应 INSERT、DELETE 和 UPDATE 三种 DML 操作。Change Buffer 和数据页一样，也是物理页的一个组成部分，即它也会被写到磁盘；并且它的数据结构也是 B+ 树，存放在共享表空间中（ibdata1)。此外，Change Buffer 使用的是 buffer pool 里的内存，因此不能无限增大。从 InnoDB 1.

最近在阅读林晓斌老师的《MySQL实战45讲》，结合已经阅读的《InnoDB 存储引擎》，做了一些笔记记录。作为学习笔记，只会记录知识点，老师举的用例基本都不作记录，当然，对一些知识点也会做适当补充。

Innodb 基于磁盘存储，同时按 页 的方式来管理记录，一个页的大小默认为 16KB。如果每次查询或修改都要按页和磁盘进行 IO 交互会严重影响数据库的性能，因此引入了 内存缓存；有了内存缓存，在对数据进行查询时，先查缓存，如果数据存在直接返回，如果不存在则去磁盘读取并将读取到的页放到缓存池中，然后再返回数据；对数据的修改也是 先修改缓存池的页，而后异步的将页刷新回磁盘。但是异步刷新磁盘也带来一个新问题：在刷新磁盘前如果意外宕机，重启后内存数据已经没有了，就会导致数据丢失。

三种行锁算法InnoDB 支持行锁，包含三种行锁算法：Record Lock: 单个记录上的锁； Gap Lock: 间隙锁，它锁住的是一个范围，不包含记录本身；Next-key Lock: 等效于 Record Lock + Gap Lock。特别注意：InnoDB 行锁是通过 给索引上的索引项加锁来实现的。因此，在执行当前读的sql语句时，一定要记得带上索引条件，否则，mysql 将会执行全表扫描，将整个表锁住。假设有一张测试表 t：create table t (a i

MVCC 定义MVCC（Multi-Version Concurrency Control）多版本并发控制，它是一种并发控制的方法。MVCC 会保存某个时间点上的数据快照，这意味着同一个事务在执行过程中，始终可以看到一个一致的数据视图。这同时也意味着不同的事务在同一个时间点看到的同一个表的数据可能是不同的。不同的存储引擎，实现 MVCC 的方法也不一样。-- 百科 MVCC一致性非锁定读、锁定读一致性非锁定读一致性非锁定读（Consistent Nonlocking Read