MySQL 通过 /mysql/bin/mysqld 启动

uft8 作为 unicode 的子集，在 MySQL 的世界里就是 uft8mb3，当然 emoji 需要 uft8mb4

MySQL 会缓存查询，不过不会缓存一些系统函数以及系统表 （比如：mysql 、information_schema、 performance_schema) 的查询结果

MySQL 5.7.20 开始不再推荐使用缓存，并在 MySQL 8.0 删除

如果你发现很难权衡用什么存储引擎，或者对存储引擎没有太多了解，那么直接用默认的 InnoDB 吧

InnoDB 在 MySQL 5.6 以及以后的版本中，大多数的 DDL 语句都不会锁表了。相对的，如果用的之前的版本，都是会锁的

InnoDB 是行存储的 （默认 Compact 行格式），存下的是每一行的原始数据和额外信息，比如：VARCHAR 这种变长字段实际用的长度，null 值列表（如果没有 null 值也就没有这个列表），trx_id 事务 id

InnoDB 默认会给主键创建一个 B+ 树作为聚簇索引，其中，聚簇索引的叶子节点包含了所有的用户数据

InnoDB 对非主键创建的 B+ 树索引的叶子节点包含主键和索引列，这种索引称为二级索引。其中一个二级索引只有一个 B+ 树，即使是联合索引

InnoDB 当 where 条件只为一个二级索引列的时候，会在索引叶子节点找到主键，然后通过主键的聚簇索引找到真实记录，这个过程称为回表

InnoDB 对非主键的联合索引采取按照联合索引前边的列排序，如果命中，则按照这个顺序往后。比如：针对一个表 user_posts (id, user_id, post_id) 的联合索引 index_on_user_id_post_id。这里我们称为前缀匹配规则

更多详情见 官方文档

1
2
3
4
5
6
7
8
#有效
select * from user_posts where user_id = 343 and post_id = 121
#有效
select * from user_posts where user_id = 343
#无效
select * from user_posts where post_id = 121
#无效
select * from user_posts where user_id = 343 or post_id = 121

InnoDB 创建的联合索引时，尽量让区分度高的列在左边

在业务上有唯一保证的列或者联合列时，一定用唯一索引，杜绝脏数据的产生

一个表上索引建的越多，就会占用越多的存储空间，在增删改记录的时候性能就越差

InnoDB 对于含有索引列的模糊匹配，只会在前缀确认的情况下才会生效

InnoDB 对于 order by 含有索引列的查询是能够通过索引排序的，不过这不包含：1. 混用 ASC 与 DESC 的时候 2. 含有非索引列的时候 3. 联合索引顺序不遵循则前缀匹配规则的

InnoDB 对于一个使用到索引的搜索条件和没有使用该索引的搜索条件使用 OR 连接起来后是无法使用该索引的

InnoDB 对于含有多个引列，并且每个列都有二级索引的查询，一般的做法是不断通过二级索引找到 B+ 树的叶子节点之后进行多次回表操作。某些特殊情况下会先合并索引，只进行一次回表操提升性能。不过，既然都用到多个列了，那么直接用联合索引就好了

MySQL inner join 的 on 语句，本质上和 where 是一样的。也就是说可以把一个 inner join 换成 where 的写法

MySQL 的 join 使用的是 嵌套循环连接 算法，在这个算法中，被 join 的表 （被驱动表） 如果数目大且没有索引，性能会急剧下降。这种情况如果实在无法避免，可以试着把 join buffer 参数调大，同时避免使用 select * 使不必要的数据占用空间

尽量让所有的查询都能做到 explain 下来至少 range，最好是 ref 甚至 consts

InnoDB 对任何一条记录进行写的改动的时候，会同时把当前的 trx_id 也写入

MySQL 默认开启 REPEATABLE READ 事务隔离级别，这种方式原本是会有幻读问题的。快照读通过 undo log 解决，当前读通过 gap lock 解决。

MySQL MVCC 中读操作分为快照读和当前读

  • 快照读：读到的是已经提交了的事务。比如 select .. where
  • 当前读：读到的永远是最新的内容，比如有一个事务修改了一个记录且没有提交。比如 update .. where

RC 和 RR 最本质的区别在于生成 ReadView 的时机不同