张晓风的博客

脏页：内存数据页跟磁盘数据页内容不一致。 干净页：内存数据写入到磁盘后，内存和磁盘上的数据页的内容一致。 一、什么情况会引发数据库的 flush 过程 InnoDB 的 redo log 写满了。 系统内存不足。 MySQL 认为系统“空闲”的时候。 MySQL 正常关闭的情况。 InnoDB 的策略是尽量使用内存，因此对于一个长时间运行的库来说，未被使用的页面很少。 影响性能的两种情况： 一个查询要淘汰的脏页个数太多，会导致查询的响应时间明显变长； 日志写满，更新全部堵住，写性能跌为 0，这种情况对敏感业务来说，是不能接受的。 二、InnoDB 刷脏页的控制策略合理地设置 innodb_io_capacity 的值，并且平时要多关注脏页比例，不要让它经常接近 75%。 三、小结利用 WAL 技术，数据库将随机写转换成了顺序写，大大提升了数据库的性能。 脏页会被后台线程自动 flush，也会由于数据页淘汰而触发 flush，而刷脏页的过程由于会占用资源，可能会让你的更新和查询语句的响应时间长一些。

使用前缀索引，定义好长度，就可以做到既节省空间，又不用额外增加太多的查询成本。 一、前缀索引对覆盖索引的影响使用前缀索引可能会增加扫描行数，这会影响到性能。 使用前缀索引就用不上覆盖索引对查询性能的优化了，这也是你在选择是否使用前缀索引时需要考虑的一个因素。 二、其他方式索引选取的越长，占用的磁盘空间就越大，相同的数据页能放下的索引值就越少，搜索的效率也就会越低。 使用倒序存储 使用 hash 字段 使用倒序存储和使用 hash 字段这两种方法的异同点。相同点：都不支持范围查询。区别： 1.从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而 hash 字段方法需要增加一个字段。 2.在 CPU 消耗方面，倒序方式每次写和读的时候，都需要额外调用一次 reverse 函数，而 hash 字段的方式需要额外调用一次 crc32() 函数。 3.从查询效率上看，使用 hash...

一、二分查找的变形问题 变体一：查找第一个值等于给定值的元素对于我们做工程开发的人来说，代码易读懂、没 Bug，其实更重要。 变体二：查找最后一个值等于给定值的元素变体三：查找第一个大于等于给定值的元素变体四：查找最后一个小于等于给定值的元素二、小结变体的二分查找算法写起来非常烧脑，很容易因为细节处理不好而产生 Bug，这些容易出错的细节有：终止条件、区间上下界更新方法、返回值选择。

一、优化器的逻辑选择索引是优化器的工作。 优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。在数据库里面，扫描行数是影响执行代价的因素之一。扫描的行数越少，意味着访问磁盘数据的次数越少，消耗的 CPU 资源越少。 扫描行数并不是唯一的判断标准，优化器还会结合是否使用临时表、是否排序等因素进行综合判断。 二、索引选择异常和处理大多数时候优化器都能找到正确的索引，但偶尔还是会碰到这两种情况：原本可以执行得很快的 SQL 语句，执行速度却比你预期的慢很多，你应该怎么办呢？ 2.1 采用 force index 强行选择一个索引。2.2 可以考虑修改语句，引导 MySQL 使用我们期望的索引。2.3 可以新建一个更合适的索引，来提供给优化器做选择，或删掉误用的索引。三、小结对于由于索引统计信息不准确导致的问题，可以用 analyze table 来解决。 而对于其他优化器误判的情况，可以在应用端用 force index 来强行指定索引，也可以通过修改语句来引导优化器，还可以通过增加或者删除索引来绕过这个问题。

一、查询过程 对于普通索引来说，查找到满足条件的第一个记录后，需要查找下一个记录，直到碰到第一个不满足条件的记录。 对于唯一索引来说，由于索引定义了唯一性，查找到第一个满足条件的记录后，就会停止继续检索。 二、更新过程当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InnoDB 会将这些更新操作缓存在 change buffer 中，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。 三、change buffer 的使用场景change buffer 只限于用在普通索引的场景下，而不适用于唯一索引。 对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时 change buffer...

一、二分思想二分查找针对的是一个有序的数据集合，查找思想有点类似分治思想。每次都通过跟区间的中间元素对比，将待查找的区间缩小为之前的一半，直到找到要查找的元素，或者区间被缩小为...

一、视图在 MySQL 里，有两个“视图”的概念： 一个是 view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是 create view … ，而它的查询方法与表一样。 另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view，用于支持 RC（Read Committed，读提交）和 RR（Repeatable Read，可重复读）隔离级别的实现。 一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况： 版本未提交，不可见； 版本已提交，但是是在视图创建后提交的，不可见； 版本已提交，而且是在视图创建前提交的，可见。 二、更新逻辑更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。 事务的可重复读的能力是怎么实现的？可重复读的核心就是一致性读（consistent read）；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。 三、小结InnoDB...

一、如何选择合适的排序算法 如果对小规模数据进行排序，可以选择时间复杂度是 O(n2) 的算法；如果对大规模数据进行排序，时间复杂度是 O(nlogn) 的算法更加高效。所以，为了兼顾任意规模数据的排序，一般都会首选时间复杂度是 O(nlogn) 的排序算法来实现排序函数。 O(n2) 时间复杂度出现的主要原因还是因为我们分区点选得不够合理。 最理想的分区点是：被分区点分开的两个分区中，数据的数量差不多。 1.1 三数取中法我们从区间的首、尾、中间，分别取出一个数，然后对比大小，取这 3 个数的中间值作为分区点。这样每间隔某个固定的长度，取数据出来比较，将中间值作为分区点的分区算法，肯定要比单纯取某一个数据更好。 1.2 随机法随机法就是每次从要排序的区间中，随机选择一个元素作为分区点。这种方法并不能保证每次分区点都选的比较好，但是从概率的角度来看，也不大可能会出现每次分区点都选得很差的情况，所以平均情况下，这样选的分区点是比较好的。 二、小结我们大部分排序函数都是采用 O(nlogn)...

行锁就是针对数据表中行记录的锁。 一、两阶段锁在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。 如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。 二、死锁和死锁检测当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。 当出现死锁以后，有两种策略： 一种策略是，直接进入等待，直到超时。 另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。 三、小结如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁的申请时机尽量往后放。

数据库锁设计的初衷是处理并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。 一、全局锁全局锁就是对整个数据库实例加锁。 全局锁的典型使用场景是，做全库逻辑备份。 业务的更新不只是增删改数据（DML)，还有可能是加字段等修改表结构的操作（DDL）。 二、表级锁MySQL 里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL)。 表锁的语法是 lock tables … read/write。 在还没有出现更细粒度的锁的时候，表锁是最常用的处理并发的方式。而对于 InnoDB 这种支持行锁的引擎，一般不使用 lock tables 命令来控制并发，毕竟锁住整个表的影响面还是太大。 三、小结全局锁主要用在逻辑备份过程中。对于全部是 InnoDB 引擎的库，建议选择使用–single-transaction 参数，对应用会更友好。 表锁一般是在数据库引擎不支持行锁的时候才会被用到的。如果你发现你的应用程序里有 lock tables...