张晓风的博客

一、count( * ) 的实现方式 MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count( * ) 的时候会直接返回这个数，效率很高； 而 InnoDB 引擎就麻烦了，它执行 count( * ) 的时候，需要把数据一行一行地从引擎里面读出来，然后累积计数。 InnoDB 的默认隔离级别是可重复度。InnoDB 是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值。 在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。 MyISAM 表虽然 count( * ) 很快，但是不支持事务； show table status 命令虽然返回很快，但是不准确； InnoDB 表直接 count( * ) 会遍历全表，虽然结果准确，但会导致性能问题。 二、不同的 count 用法 count() 的语义：count() 是一个聚合函数，对于返回的结果集，一行行地判断，如果 count 函数的参数不是 NULL，累计值就加 1，否则不加。最后返回累计值。 分析性能差别的时候要注意的几个原则：1.server 层要什么就给什...

一、数据删除流程数据页的复用跟记录的复用是不同的。记录的复用，只限于符合范围条件的数据。而当整个页从 B+ 树里面摘掉以后，可以复用到任何位置。 如果相邻的两个数据页利用率都很小，系统就会把这两个页上的数据合到其中一个页上，另外一个数据页就被标记为可复用。 delete 命令其实只是把记录的位置，或者数据页标记为了“可复用”，但磁盘文件的大小是不会变的。 不止是删除数据会造成空洞，插入数据也会。 二、重建表MySQL 5.6 版本开始引入的 Online DDL Online 和 inplaceDDL 过程如果是 Online 的，就一定是 inplace 的；反过来未必，也就是说 inplace 的 DDL，有可能不是 Online 的。 三、小结如果要收缩一个表，只是 delete 掉表里面不用的数据的话，表文件的大小是不会变的，还要通过 alter table 命令重建表，才能达到表文件变小的目的。重建表有两种实现方式，Online DDL 的方式是可以考虑在业务低峰期使用的，而 MySQL 5.5 及之前的版本，这个命令是会阻塞 DML 的，这个需要特别小心。

脏页：内存数据页跟磁盘数据页内容不一致。 干净页：内存数据写入到磁盘后，内存和磁盘上的数据页的内容一致。 一、什么情况会引发数据库的 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 字段方式的查询性能相对更稳定一些。 三、小结字符串字段创建索引的方式： 1.直接创建完整索引，这样可能比较占用空间； 2.创建前缀索引，节省空间，但会增加查询扫描次数，并且不能使...

一、二分查找的变形问题 变体一：查找第一个值等于给定值的元素对于我们做工程开发的人来说，代码易读懂、没 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 的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。 四、索引选择与实践这两类索引在查询能力上是没差别的，主要考虑的是对更新性能的影响。所以，建议尽量选择普通索引。...

一、二分思想二分查找针对的是一个有序的数据集合，查找思想有点类似分治思想。每次都通过跟区间的中间元素对比，将待查找的区间缩小为之前的一半，直到找到要查找的元素，或者区间被缩小为 0。 二、二分查找的实现容易出错的3个地方： 循环退出条件 2.中数的取值 3.低位和高位的更新 三、二分查找的局限性首先，二分查找依赖的是顺序表结构，简单点说就是数组。二分查找只能用在数据是通过顺序表来存储的数据结构上。如果你的数据是通过其他数据结构存储的，则无法应用二分查找。 其次，二分查找针对的是有序数据。二分查找只能用在插入、删除操作不频繁，一次排序多次查找的场景中。针对动态变化的数据集合，二分查找将不再适用。 再次，数据量太小不适合二分查找。如果要处理的数据量很小，完全没有必要用二分查找，顺序遍历就足够了。 最后，数据量太大也不适合二分查找。二分查找的底层需要依赖数组这种数据结构，而数组为了支持随机访问的特性，要求内存空间连续，对内存的要求比较苛刻。 四、小结二分查找的核心思想理解起来非常简单，有点类似分治思想。即每次都通过跟区间中的中间元素对比，将待查找的区间缩小为一半，直到找到要查...

一、视图在 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) 排序算法来实现，但是为了尽可能地提高性能，会做很多优化。 快速排序的一些优化策略，比如合理选...