零零年代的风的博客

MySQL的性能优化主要分为以下四个方面设计: 存储引擎、字段类型、索引功能：缓存、分库分表、数据库连接池架构上: 读写分离、集群、均衡负载合理的SQL： 测试、优化查询语句、Explain查询执行计划、慢日志

字符集的概念：人们抽象出一个字符集的概念来描述某个字符范围的编码规则。比较规则的概念：对于某一种字符集来说，可以制定用来比较字符大小的多种规则，也就是说同一种字符集可以有多种规则。

InnoDB 内存管理用的是最近最少使用 (Least Recently Used, **LRU**) 算法，这个算法的核心就是淘汰最久未使用的数据。 InnoDB 管理 Buffer Pool 的 LRU 算法，是用链表来实现的。

我的数据库内存只有10G，现在我要对一个20G的大表做全表扫描，会不会把数据库内存（buffer pool）占满然后报OOM的错误？答案是不会的。InnoDB的数据是保存在主键索引上面的（主键索引最全），所以全表扫描扫描的是主键索引，由于没有其他的判定条件，所以查询到的每一行都放到结果集里面，然后返回给客户端。

一般来说，执行更新操作时，我们会有两种选择：先操作数据库，再操作缓存先操作缓存，再操作数据库这两个操作要么同时成功，要么同时失败。所以，这会演变成一个分布式事务的问题。如果原子性被破坏，会有两种情况：操作数据库成功，操作缓存失败操作缓存成功，操作数据库失败

主备延迟的来源：如果备库所在的机器性能比主库所在的机器性能差；因为性能不一样，备库消费 (relay log) 的速度没有主库。binlog 生成的快，造成了“消息积压”；备库压力大大事务。主备延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。

MySQL 实现主备一致肯定是 binlog。毫不夸张的说，MySQL 能够成为现在最流行的开源数据库，binlog 功不可没。MySQL主备的基本原理.........

在高可用下可以被选成主库的叫备库，其他的叫从库。备库也是从库。

QL语句执行慢有两种情况：偶尔慢：MySQL在刷新脏redolog写满了，要往前推进checkpoint内存不够用了，要从LRU链表中淘汰，触发了脏页刷新MySQL认为系统空闲的时候，即使MySQL很忙，也要见缝插针地找时间，只要有机会就刷一点“脏页”MySQL关闭的时候上述所说也是MySQL中刷新脏页的时机。一直慢：MySQL索引没有设置好，查询时候优化器选错索引，SQL语句没有写好等。

文中详细说明了explain的各个字段的意义。看完就会。

MySQL一行语句到底要加多少锁？首先说明一下，这些加锁规则都是林晓斌老师自己总结的。这篇是我自己总结的学习笔记。MySQL 后面的版本可能会改变加锁策略，所以这个规则只限于截止到现在的最新版本，即 5.x 系列

这个error是因为表被锁定了。表被锁定无法进行增删改查的操作可以使用unlock tables；命令进行解锁之后就可以进行正常操作了。

文中详细的讲解了一些案例和场景，通俗易懂，看一遍就会，非常建议校招生看一看，其中场景都是可以复现的，建议边看边做，自己动手试一试，印象会更深刻。

由于该字段上面有索引，所以放心的执行这条语句，但是却发现执行了特别久，为什么呢？因为MySQL的规定，如果对字段做了函数运算，那么就用不上索引了，因为在索引上不知道往哪个方向走了。但是优化器并不是放弃这个索引了，它会比较主键索引和当前索引的大小，选择走索引小的那个遍历，即选择最优的。解决办法： 尽量让sql语句不使用函数，sql可以长一点，把所有可能的条件都写上。

在排序字段没有索引的条件下，有两种排序方式，分别是全字段排序和rowid排序，文中详细的介绍了这两种方式。有索引的情况之下走索引就ok了，因为索引是有序的。

InnoDB 是索引组织表，主键索引树的叶子节点是数据，而普通索引树的叶子节点是主键值。所以，普通索引树比主键索引树小很多。对于 count(*) 这样的操作，遍历哪个索引树得到的结果逻辑上都是一样的。因此，MySQL 优化器会找到最小的那棵树来遍历，count( * )它是不取值的，它遍历的应该是不为null的小索引树字段。在保证逻辑正确的前提下，尽量减少扫描的数据量，是数据库系统设计的通用法则之一。

count() 是一个聚合函数，对于返回的结果集，一行行地判断，如果 count 函数的参数不是 NULL，累计值就加 1，否则不加。最后返回累计值。 count(*)、count(主键 id) 和 count(1) 都表示返回满足条件的结果集的总行数；而 count(字段），则表示返回满足条件的数据行里面，参数“字段”不为 NULL 的总个数。

当内存数据页跟磁盘数据页内容不一致的时候，我们称这个内存页为**“脏页”**。内存数据写入到磁盘后，内存和磁盘上的数据页的内容就一致了，称为“干净页”。在平时执行很快的更新操作，其实就是在写内存和日志，而 **MySQL 偶尔“抖”一下的那个瞬间，可能就是在刷脏页（flush）**。

直接创建完整索引，这样可能比较占用空间；创建前缀索引，节省空间，但会增加查询扫描次数，并且不能使用覆盖索引；倒序存储，再创建前缀索引，用于绕过字符串本身前缀的区分度不够的问题；创建 hash 字段索引，查询性能稳定，有额外的存储和计算消耗，和倒叙存储一样，都不支持范围扫描。

什么是最左匹配原则？举个例子：比如有abc组成的联合索引，能走的索引可以是a，ab，abc。不能是bc这样的，如果条件上先b后c，那么就是全表查询，不走索引了。可以使联合索引的最左边的N个字段，也可以是字符串的前m个字符。覆盖索引它是一个概念，不是索引类型。举个例子：一个二级索引（辅助索引），通过二级索引找到这个叶子结点，然后拿到主键，在进行回表去查找所需要的数据。覆盖索引是使用辅助索引的时候，不需要通过辅助索引去拿到主键在回表，通过辅助索引就直接能查到要找的数据。其实我认为这是数据库设计的一种思想。索引下

**索引选择异常和处理** - 一种方法是，采用 **force index** 强行选择一个索引。 - 第二种方法就是，我们可以考虑修改语句，**引导** MySQL 使用我们期望的索引。- 第三种方法是，在有些场景下，我们可以新建一个更合适的索引，来提供给优化器做选择，或删掉误用的索引。

1.B树只适合随机检索，B+树支持随机检索和顺序检索2.B+树空间利用率高，可以减少IO次数，磁盘读写代价更低。一般来说索引本身也很大，往往以索引文件的形式存储在磁盘上，这样索引查找过程就要产生磁盘IO消耗。B+树的内部节点只作为索引使用，其内部节点（非叶子节点）比B树更小，判断能容纳的节点中关键字更多，一次读取到的键更多。3.B+树查询效率更稳定，因为数据存放在叶子节点。4.B树在一定程度上也提高了磁盘IO性能，但没有解决遍历效率低下的问题。B+树的叶子节点都使用指针顺序连接在一起，只要遍历叶子节

- 唯一索引：唯一索引和主键索引一样不能重复。唯一索引可作为数据的一个合法检验手段。- 普通索引：在创建普通索引时，没有任何的限制条件，比如非空或者唯一，可以在任意字段上建立普通索引。

在可重复读的隔离级别下，事务在启动时就拍了个快照。快照是基于整库的。InnoDB里面每个事务都有一个唯一事务的ID，叫做transaction id。它是在事务开始的时候向InnoDB系统申请的，是按照申请的顺序递增的。而且每行数据也是有多个版本的，每次事务更新数据的时候，都会生成一个新的数据版本，同时把transaction id赋值给数据版本，记为row trx_id。同时，旧的事务id要保留，在新的数据版本中，要有信息能够拿到它。也就是说，数据表中的每行数据可能有多个版本，每个版本有自己

行锁是由各个存储引擎自己实现的，并不是所有的引擎都支持行锁。MyISAM引擎就不支持行锁，同一时刻一张表只能有一个更新在执行。现在说InnoDB的行锁，行锁，顾名思义，就是事物A更新一行，同时事物B也要更新一行，那么事物B只好等事物A更新完成再去更新。

全局锁就是对整个数据库进行加锁， MySQL提供了一个加全局锁的方法，命令是： Flush tables with read lock，简称：(FTWRL) ，当使用这个语句的时候，整个库会变的只能读，可读。其他命令：像DML（增删改查），DDL（修改表结构）和更新类事物的语句提交等这些命令都会被阻塞。表级锁有两种：一种是表锁，一种是元数据锁（meta data lock），也叫MDL。