原理#

回答#

注意没有用过skywalking可以不说 而开启mysql的慢查询日志通常在调试阶段，因为会损耗mysql性能

原理#

如果出现useing index condition代表索引使用有优化空间

回答#

什么是索引#

这里是以二叉搜索树示例

索引的底层数据结构#

磁盘读写代价低时因为非叶子节点只是存储指针，在便利的时候不需要每个节点都加载数据 查询效率稳定，数据都寸在叶子节点上 便于扫库和区间检查，因为叶子节点也是一个双向链表，不需要再从根节点遍历

回答#

原理#

简单来说，先通过二级索引拿到对应的主键，再通过主键获取真正的数据。相当于读了两次表，就叫做回表查询

回答#

面试官可能会问，什么是回表查询，此时就可以先解释什么是聚簇索引和非聚簇索引，然后解释回表查询

原理#

第一个是直接通过主键，是聚簇索引，叶子节点存储全部的数据，不需要回表查询，即覆盖索引 第二个通过name字段，二级索引叶子节点刚好也存储了主键，刚好要找的是name 和 id，所以也是聚簇索引 第三个，索引并没有gender，因此触发回表查询，通过id又要查一次表，所以为非聚簇索引 回表查询性能相对来说较低

回答#

原理#

1
-- 常见八股写法（容易掩盖问题本质）
2
SELECT * FROM tb_sku t, (
3
    SELECT id FROM tb_sku ORDER BY id LIMIT 9000000, 10
4
) a WHERE t.id = a.id;

1
-- 原始慢 SQL：耗时可能达到数十秒甚至直接查询超时
2
SELECT * FROM tb_sku ORDER BY create_time LIMIT 9000000, 10;

1
-- 优化后 SQL：耗时从数十秒大幅降低至数百毫秒
2
SELECT * FROM tb_sku t JOIN (
3
    SELECT id FROM tb_sku ORDER BY create_time LIMIT 9000000, 10
4
) a ON t.id = a.id;

1
-- 游标分页（记录上一页最后一条的主键 ID）
2
SELECT * FROM tb_sku WHERE id > 9000000 ORDER BY id LIMIT 10;

回答#

面试满分回答话术梳理：

1. 切中痛点：深分页（如 LIMIT 9000000, 10）变慢的本质是海量无效回表。以按业务列（如 create_time）排序为例，为了获取全列数据，MySQL 在二级索引扫描时每遇到一条记录都要回表一次，导致前 900 万条产生了 900 万次无效的随机 I/O，最终数据却被全部丢弃。
2. 给出解法（覆盖索引 + 延迟关联）：使用子查询先查 SELECT id FROM tb_sku ORDER BY create_time LIMIT 9000000, 10。因为二级索引叶子节点本身包含排序列与主键 id，命中覆盖索引，前 900 万行实现 0 次回表；然后再通过主键 JOIN 原表，仅对最终的 10 条数据进行 10 次精准回表，大幅降低 I/O 消耗。
3. 高阶进阶（游标分页）：指出子查询依然需要线性遍历 900 万次索引记录。若业务允许（如瀑布流、滚动加载），或排序字段本身就是主键 id，最优方案是采用游标分页（WHERE id > last_id LIMIT 10），利用 B+ 树 $O(\log N)$ 步直接定位目标行，彻底消除分页性能瓶颈。

联合索引与最左前缀原则#

1
CREATE TABLE employees (
2
    id INT PRIMARY KEY AUTO_INCREMENT,
3
    name VARCHAR(50),
4
    age INT,
5
    department VARCHAR(50),
6
    salary DECIMAL(10,2)
7
);
8

9
-- 创建联合索引：(department, age, salary)
10
CREATE INDEX idx_dept_age_salary ON employees(department, age, salary);

1
-- 覆盖索引：department, age, salary 均在索引叶子节点中，Extra 显示 Using index
2
EXPLAIN SELECT department, age, salary
3
FROM employees
4
WHERE department = '技术部' AND age > 25;

回答#

1. 违背最左前缀法则#

在联合索引中，如果跳过了最左侧前导列，整棵 B+ 树将无法进行二分寻道，导致索引彻底失效；如果跳过了中间某一列，则只有断层左侧的列能够用于索引查找。

解析：对于联合索引 (name, status, address)，全值匹配查询时，三个字段按序连续命中，key_len 达到最大值，索引利用率最高。

解析：查询条件跳过了中间的 status（如 WHERE name = 'X' AND address = 'Y'），只有最左侧的 name 能够用于索引查找，key_len 仅对应 name 列的长度。

2. 范围查询导致右侧列失效#

在联合索引中，一旦某一列使用了范围查询（>、<、BETWEEN 等），该列右侧的所有索引列将无法继续用于树定位查找。

• 底层原因：当 status > '1' 筛选出一个多节点范围后，在这一范围内不同记录的 address 是离散无序的，因此 B+ 树无法继续利用 address 进行精确区间收窄。
• 💡 规避技巧：在业务逻辑允许的情况下，尽量使用 >=、<= 替代纯粹的 >、<；或在建立联合索引时，将范围查询列放置在联合索引的最右侧。

3. 在索引列上进行运算或函数操作#

如果在查询条件的索引列上进行了数学运算、字符串截断或系统函数调用，索引将完全失效，退化为全表扫描。

• 典型错误：

  1
  -- 错误：在索引列上调用函数导致失效
  2
  SELECT * FROM tb_seller WHERE SUBSTRING(phone, 10, 2) = '15';
  3
  
  4
  -- 错误：在索引列上进行数学运算导致失效
  5
  SELECT * FROM tb_sku WHERE id + 1 = 100;

• 底层原因：B+ 树索引中存储的是字段的原始原始值，而不是计算或转换后的衍生值。MySQL 无法反向逆推函数结果在树上的位置，只能逐行扫描全表。

4. 隐式类型转换（字符串不加单引号）#

数据类型不匹配会触发 MySQL 底层的隐式类型转换，本质等同于在索引列上隐式包裹了 CAST() 函数。

• 典型场景：phone 字段定义为字符串类型 VARCHAR：

  1
  -- 走索引：正常传递带单引号的字符串
  2
  SELECT * FROM tb_seller WHERE phone = '13800000000';
  3
  
  4
  -- 索引失效：未加单引号，传入整型数字
  5
  SELECT * FROM tb_seller WHERE phone = 13800000000;

• 底层原因：MySQL 规则规定，当字符串与数值进行比较时，会将字符串转为浮点数/数值进行比较。相当于执行了 WHERE CAST(phone AS DOUBLE) = 13800000000，触发了函数计算导致索引失效。

5. 头部模糊查询（LIKE 以 % 开头）#

使用 LIKE 进行通配符匹配时，通配符的位置决定了是否能够利用索引：

• 失效场景（以 % 开头）：LIKE '%北京' 或 LIKE '%北京%'。因为字符串的前缀完全未知，B+ 树无法确定字典序的起点，必须全表扫描。
• 生效场景（以 % 结尾）：LIKE '北京%'。前缀字符明确，MySQL 可以利用 B+ 树快速定位到以“北京”开头的最小边界和最大边界，走高效的索引范围扫描（Index Range Scan）。
• 💡 优化方案：若业务必须使用 %word% 全模糊查询，尽量使用覆盖索引（只查询索引包含的字段，走索引全扫描 Index Scan 比走表全扫描 Table Scan 快得多），或引入专门的全文检索引擎（如 Elasticsearch）。

6. OR 连接条件存在无索引列 / 优化器成本预估（CBO）#

1. OR 条件未全部建立索引：若 WHERE a = 1 OR b = 2，即使 a 有索引，但只要 b 没建索引，因为 b 无论如何都要全表扫描，优化器便会放弃使用 a 的索引，直接执行全表扫描。
2. 优化器成本预估放弃走索引：MySQL 优化器（CBO）会预估走索引与全表扫描的成本代价。当查询条件筛选出的记录占全表比例较大时（例如查询结果超过全表的 20%~30%），优化器评估“在二级索引中频繁离散寻道并进行海量随机回表”的开销远高于“直接顺序扫描全表”，从而主动放弃使用索引。

总结与面试回答#

💡 面试高分记忆口诀：

“模型数空运，最左前缀别断层；范围之后列失效，函数运算全表行；字符加引号免转换，Like 百分莫打头；OR 两侧皆需索，成本过高优化放。”

大白话理解：为什么要「小表驱动大表」？#

你可以把表连接（JOIN）直接理解为代码里的 双层 for 循环（这里的“次数”指的就是 MySQL 内部双层嵌套循环的匹配次数）：

1
// 小表驱动大表：比如小表 10 行，大表 1000 万行（大表关联字段建了索引）
2
for (小表的每一行 : 小表) {  // 外层循环：只跑 10 次！
3
    // 拿小表的关联值，去大表里利用索引查一次（走索引树极快，瞬间查出）
4
}

• 小表放外层（小表驱动大表）：
  • 外层循环只跑 10 次，去大表里查 10 次就完事了，极其省力！
• 大表放外层（大表驱动小表）：
  • 外层循环要跑 1000 万次！哪怕内层查得再快，光是外层空转 1000 万次，CPU 和内存也会直接吃不消。

所以记住大白话原则：哪张表的数据少，谁就放到外层当驱动表；外层循环次数越少，整体效率越高！

大白话总结：最管用的几条 SQL 优化经验#

1. 避免 SELECT *：需要哪些字段就查哪些字段，尽量凑成覆盖索引，少回表或者不回表；
2. 小表驱动大表：多表关联查询时，过滤后数据量小的表作为外层驱动表；
3. 批量操作代替单条循环：多条插入用 INSERT INTO 表 VALUES (...), (...) 一次搞定，减少网络往返开销；
4. 优先用 UNION ALL：如果业务不需要去重，直接用 UNION ALL，避免数据库额外做耗时费力的排序去重；
5. 深分页用延迟关联或游标：大分页别硬查，用子查询只查 ID 走覆盖索引，或者用 WHERE id > last_id 精准跳转。

回答#

💡 补充说明：分库分表一般发生在单表数据量千万级以上、单机硬件达到瓶颈的大并发场景中。

回答#

问题#

解决了不可重复读的问题后，读数据不存在，插入数据又失败，再读还是不存在，就出现了幻读问题

事务隔离性#

回答#

回答#

原理#

这个不用记忆

回答#

原理#

回答#

原理#

垂直分表不一定会把一个表分到两个数据库中

回答#