MySQL 核心机制精讲：B+树查询、Buffer Pool、COUNT 优化与 CHAR/VARCHAR 实战指南
一、请详细描述一下MySQLB+树查询数据的过程
B+树查询数据分两个阶段： 1. 先从根节点往下定位到叶子节点。 2. 在叶子节点内部定位到具体的数据行。
- 第一阶段是树的垂直查找，从根节点开始，要查询的键值和节点内存储的索引的键值作比较，通过二分查找，来确定落在哪个区间，重复这个过程，直到找到根节点。一棵三层的B+树最多经过三次磁盘IO就可以定位到叶子节点。
- 第二阶段是页内查找，叶子节点也是一个16KB大小的数据页，一个叶子节点能存很多数据，InnoDB通过目录页来加速查找。目录页把记录分成了多个组，每个槽记录组内的最大数；通过对目录页的二分查找能定位到对应的组，组内是通过单向链表连接的，通过对单项链表遍历就能找到目标记录。
整个过程：根节点->中间节点->叶子节点->二分查找目录页->遍历单向链表
二、Buffer Pool的作用
缓存热点数据页
实际查询时不是每次都从磁盘中读，Buffer Pool会缓存热点数据页，所以实际的查询过程是：
- 先在Buffer Pool中查询，有就直接用，不用走磁盘
- 没有就从磁盘里读取到数据页并写进Buffer Pool
三、MySQL 中 count(*)、count(1) 和 count(字段名) 有什么区别？
三者都是统计行数的聚合函数，核心区别是对于
null处理不同
count(*)和count(1)会统计所有的行，包括null。count(字段名)不会统计字段名内为null的行。
四、如果要统计一张 5000 万行的订单表有多少条记录，直接 count(*) 太慢，你怎么优化？
- 如果允许存在误差的话，可以直接
SHOW TABLE STATUS拿估算值，毫秒级反应。 - 如果不允许出现误差，又要求快速响应，可以在Redis里维护一个计数器。要处理好缓存一致性问题，例如事务消息或定期校验
五、count(*) 走的是主键索引还是二级索引？
- 如果有二级索引的话走的是二级索引，因为二级索引只存储索引列和主键，占用空间小，扫描的数据页少，IO开销更低。
- 具体可以用
explain去分析key命中的索引
六、MySQL中CHAR和VARCHER的区别是什么？
CHAR是定长的，VARCHAR是变长的
CHAR(10)不管存几个字符，都占10个字符的空间，不够用空格填充。VARCHAR(10)存多少占多少，最后在花1-2个字节记录长度。
七、VARCHAR(N) 的 N 会影响排序性能
- MySQL 执行 ORDER BY 时会用到 sort_buffer，如果要排序的数据放不下，就得走 双路排序：先把排序字段和主键放进 sort_buffer 排好序，再回表取完整数据。多了一次回表，性能差不少。
-- a、b、c 都是 VARCHAR(1000)，即使实际数据很短SELECTa,b,cFROMt1WHEREa='面试鸭'ORDERBYb;-- MySQL 按每行 3000 字符算空间，sort_buffer 放不下就走双路排序八、CHAR 读取时会自动去掉尾部空格
CHAR 存储时会用空格填充到定长，读取时 MySQL 会自动去掉尾部空格。这可能导致意想不到的问题：
CREATETABLEt(cCHAR(5));INSERTINTOtVALUES('abc ');-- 故意存两个空格SELECTCONCAT('[',c,']')FROMt;-- 结果是 [abc]，尾部空格被去掉了九、什么时候用 CHAR？
别看 CHAR 好像很鸡肋，在特定场景下还是有优势的：
1）存储固定长度的编码，比如 ISO 国家代码 CHAR(2)、MD5 摘要 CHAR(32)、UUID 去掉横杠后 CHAR(32)
2）存储单字符的状态标记，比如性别 CHAR(1) 存 M/F
3）频繁更新的短字段，CHAR 不会产生碎片，VARCHAR 长度变化可能导致页分裂