MySQL面试场景题：索引失效、事务并发与线上排查实战

面试场景题，说穿了就是考“你这三年到底有没有真的碰过线上问题”。MySQL的八股文背得再熟，遇到一个“生产环境突然慢查询堆积”“两张表数据对不上”“加唯一索引报错”的场景，不会排查就是不会，这玩意儿装不出来。

我这些年面试后端和DBA岗位，特别喜欢用场景题去压人，因为场景题没有标准答案，却能最快看出一个人对MySQL底层机制的理解深度。这次整理的是第二期，把最近面试中高频出现的几类场景题做了个归拢。每一道题我都按“背景现象、排查思路、解决方案、背后原理”四层来拆，尽量还原真实业务的语境。如果你正在准备面试，或者刚接手一个MySQL维护任务，这篇内容应该能帮你少走不少弯路。

1. 索引失效类场景题：SQL明明写了索引，为什么还是慢查询

面试里最经典的开场题，永远是从慢查询开始。候选人简历上写着“精通SQL优化”，那我就顺手给一条SQL：

sql复制SELECT * FROM orders 
WHERE DATE(create_time) = '2025-01-15';

order表有几十万条数据，create_time字段建了索引，但这条SQL就是走全表扫描，为什么？这个问题能刷掉一大半人。原因很简单，你在索引列上用了DATE函数，MySQL对索引列做函数运算后，B+树里存储的原始值没法直接参与比较，优化器只能放弃索引。这就好比一本书的目录是按页码排的，你非要问“第奇数页的内容有哪些”，那除了翻书没有别的办法。

正确写法是改成范围查询：

sql复制SELECT * FROM orders 
WHERE create_time >= '2025-01-15 00:00:00' 
  AND create_time < '2025-01-16 00:00:00';

这样create_time的索引就能正常走range扫描，效率完全不在一个量级。这里我建议你养个习惯，每写一条带函数条件的SQL，顺手敲一下EXPLAIN看type列，看到ALL就要警惕了。

1.1 隐式类型转换：手机号字段惹的祸

再来看一个特别容易踩的场景。用户表里phone字段定义成varchar(20)，也建了索引，但线上一条SQL：

sql复制SELECT * FROM users WHERE phone = 13800138000;

看起来没毛病，手机号嘛，可偏偏这条SQL就是慢。原因在于等号左边是varchar类型，右边是数字，MySQL的优化器会做隐式类型转换，把字段值转换成数字再比较。一旦索引列被类型转换，索引就失效了，跟上面函数运算一个道理。

这类问题在真实业务里非常常见，特别是接口层传参时，框架把参数处理成了long类型传给SQL。排查手段也简单，EXPLAIN看到type为ALL，同时查询条件里有一个数字字面量，基本就能锁定。

解决方式两条路：一是应用层保证参数类型，不让数字去匹配varchar字段；二是实在改不动代码，就改成拿字符串比较：

sql复制SELECT * FROM users WHERE phone = '13800138000';

这个场景的教训是，MySQL的隐式转换规则是字段往参数类型上转，而不是反过来，记住了这个，很多慢查询不用看执行计划都能猜个大概。

1.2 左模糊匹配和OR连接：两个高频索引杀手

like查询也是老生常谈。like '%keyword%'走不了索引，是因为B+树的索引结构按前缀有序排列，你要查的是后缀匹配，树结构帮不上忙。但如果业务确实需要模糊搜索，不要让DBA硬扛，该上全文索引或Elasticsearch就上，这不是SQL能解决的范畴。

OR连接条件则更隐蔽。比如：

sql复制SELECT * FROM orders 
WHERE user_id = 123 OR status = 1;

user_id上有索引，status上没有索引。优化器一看，这个OR条件想要返回完整结果集，必须有一个分支需要全表扫描，那干脆整个条件都不走索引了。解决办法是拆成两个查询用UNION ALL合起来：

sql复制SELECT * FROM orders WHERE user_id = 123
UNION ALL
SELECT * FROM orders WHERE status = 1;

注意这里用UNION ALL而不是UNION，因为OR本身就是取并集，不需要去重，UNION反而多一次排序去重的开销。面试时你要是能把这个细节讲出来，面试官会对你另眼相看。

1.3 联合索引的最左前缀原则

联合索引是面试必考点，场景题最常见的是这么一问：表里建了联合索引(a, b, c)，以下哪条SQL能走索引？这是很经典的题，答案是有a条件的才能走。如果你只写了b和c条件，联合索引从第一个字段就不匹配，索引直接废掉。

但有一类稍微偏一点的：WHERE a = 1 AND c = 2，a条件命中了，所以联合索引会在a=1这个范围内扫描，c条件没法继续利用索引过滤，但整体上还是走了索引，只是需要回表过滤c。这条能答上来的人不多，因为它考察的是你真正理解联合索引的存储结构，而不只是背口诀。联合索引本质上是先按a排，再按b排，再按c排，中间断层了，后面的字段就用不上精确定位。

实际开发里，联合索引的设计非常考验功力，我的经验是：等值条件放前面，范围条件放后面；频繁查询的字段放前面，区分度高的字段放前面。但这三个原则发生冲突时，以实际业务SQL为准，不要为了理论上的完美设计一套用不上的索引。

2. 事务与锁场景题：并发扣减库存，怎么保证数据是对的

库存超卖应该是面试场景题里出现频率最高的问题了。业务场景很简单：一张商品表goods，字段有id、stock，用户下单时需要执行：

sql复制UPDATE goods SET stock = stock - 1 WHERE id = 123;

两个用户同时下单，都读到了stock=1，然后都执行减一，最后库存变成了0，但订单出了两单，超卖了。这个场景问的是，怎么用MySQL层面解决。

2.1 悲观锁方案：SELECT FOR UPDATE

最直接的方案是让更新串行化。在事务里先执行：

sql复制BEGIN;
SELECT stock FROM goods WHERE id = 123 FOR UPDATE;
-- 业务判断stock > 0
UPDATE goods SET stock = stock - 1 WHERE id = 123;
COMMIT;

SELECT FOR UPDATE会给这条记录加排他锁，第二个事务再执行相同的SELECT FOR UPDATE时会被阻塞，等第一个事务提交后才继续。这样同一时刻只有一个事务能修改这条库存记录，从机制上杜绝了超卖。

但这个方案的问题也很明显，并发性能低。锁的粒度是行，但所有用户都在抢同一行库存，等于把所有下单操作都串行化了。高并发秒杀场景如果还这么写，数据库连接池会被打满，直接拖垮整个服务。所以悲观锁适合并发量不高的业务，或者对一致性要求极高、绝对不能超卖的场景。

2.2 乐观锁方案：版本号控制

乐观锁的思路是不加锁，靠条件更新来保证。给goods表加一个version字段，更新的时候带上版本号：

sql复制UPDATE goods 
SET stock = stock - 1, version = version + 1 
WHERE id = 123 AND version = 5;

如果影响行数为0，说明version已经变了，有其他事务抢先更新过了，应用层需要重试或者提示用户。这就是典型的“CAS（Compare And Set）”思想，MySQL的更新本身就是原子操作，同一行记录在同一时刻只会有一个UPDATE成功，利用这个原子性就够保证不错账了。

我特别推荐这个方案，因为它在中间件层就能实现，不需要依赖数据库锁，性能比悲观锁高很多。但要注意，如果业务请求量实在太大，乐观锁的重试次数会飙升，对应用层也不友好。这时就该引入Redis、消息队列这类中间件做流量削峰了，数据库兜底只处理最终落库的请求。

2.3 死锁和锁等待：排查思路比解决更重要

还有一个高频场景题是：生产环境突然出现大量Lock wait timeout exceeded，怎么排查？这个问题考察的是实际运维能力。

我一般会教人按这个路径排查：

sql复制-- 1. 查看当前有哪些事务在跑
SELECT * FROM information_schema.INNODB_TRX;

-- 2. 查看正在等待锁的事务
SELECT * FROM information_schema.INNODB_LOCK_WAITS;

-- 3. 如果确定是死锁，直接看InnoDB死锁日志
SHOW ENGINE INNODB STATUS;

SHOW ENGINE INNODB STATUS输出里，重点看LATEST DETECTED DEADLOCK这一段，里面会明确打印出两个事务各自的SQL语句、持有锁和等待锁的记录信息。根据日志里的SQL，基本就能还原出死锁链条。

死锁最常见的原因是事务加锁顺序不一致。比如事务A先更新goods再更新orders，事务B先更新orders再更新goods，两个事务互相等对方释放锁，就死锁了。解决办法是约定所有事务都按相同的顺序访问资源。另一个常见原因就是上面提到的间隙锁，在RR隔离级别下，范围查询会锁住范围内的间隙，两个事务插入不同记录时会互相阻塞，形成死锁。

注意：死锁在InnoDB里不会一直挂起，它会自动检测并回滚代价较小的事务。但锁等待不会，它会一直等到超时时间，然后抛异常。所以线上遇到“卡死”，大多数是锁等待而不是死锁。

排查锁问题，我的体会是不要光看表和SQL，要看事务的完整上下文。很多锁等待不是一条SQL导致的，而是一个事务里多条SQL共同作用的结果。建议定位到具体的事务ID后，去应用日志里查这个事务从开始到当前执行了哪些SQL，这样才能找到真正的根因。

3. 细节陷阱题：or去重、int加5、字段叫order，这些坑你踩过吗

场景题不一定都是大型架构设计，有些小细节反而最能看出一个人的功底。比如“MySQL里OR能去重吗”这个问题，乍一听像个伪命题，但真有人回答“能，OR就是或者的意思”之类的废话。实际上OR是逻辑运算符，MySQL里它负责连接多个条件并返回满足任一条件的结果集，它会做隐式去重吗？不会。

sql复制SELECT * FROM users WHERE id = 1 OR id = 1;

结果就一条记录，和WHERE id = 1一样，但这不代表OR去重了，而是索引本身唯一。你换个字段试试：

sql复制SELECT name FROM users WHERE age = 20 OR age = 20;

假如表里有两个age=20的用户，返回两行，OR可不管你重不重。去重要靠DISTINCT或GROUP BY：

sql复制SELECT DISTINCT name FROM users WHERE age = 20;

不过这类SQL写多了以后，要提醒自己DISTINCT是对整个结果集去重，不是对某一个字段去重。面试时我会顺带追问一句：DISTINCT和GROUP BY哪个去重效率更高？答案是在有索引的情况下两者都走索引去重，但GROUP BY因为可能还承担着聚合的功能，语义更重。单纯去重，DISTINCT更直观，优化器处理上也没啥本质差别。

3.1 int加5的隐式转换：一句SQL改错全表数据

热搜词里有个“mysql中int+5”，这个场景我印象深刻。有一次线上事故，开发写更新语句时把条件写漏了：

sql复制UPDATE users SET age = age + 5;

没有WHERE条件。结果全表用户的年龄都加了5岁。这个事本身不是int+5的语法问题，而是UPDATE没有WHERE条件的灾难性后果。但面试时我会拿这个例子问：MySQL里age+5到底做了什么？

拆开看，age是int类型，+5就是数值运算，把当前字段值取出来加5再写回去。这个操作本身没问题，问题出在如果age字段定义成了varchar，比如存了字符串'18'，那么age + 5会先把'18'转换成数字18，再加5得到23。但如果字段里存了'18岁'这种带中文的字符串呢？MySQL的转换规则是取字符串开头的数字部分，'18岁'取到18，'abc'取到0，'a18'取到0。

这种隐式转换在开发中很容易埋雷。我见过一个真实案例，一个字典表用varchar存数字编码，开发写JOIN的时候直接拿这个字段和另一张表的int字段关联，结果两边的数据匹配不上，查出来的结果集莫名其妙。问题根源就是隐式转换把“100”和100当成了不同的值，或者反过来转换时部分值变成了0。所以字段类型设计必须严谨，该int就int，该varchar就varchar，不要混。

3.2 字段名撞了关键字：反引号的正确姿势

另一个特别常见的场景是建表时字段用了关键字。比如：

sql复制CREATE TABLE t_order (
  id INT PRIMARY KEY,
  order VARCHAR(50),
  desc VARCHAR(200)
);

这条SQL直接报语法错误，因为order是排序关键字，desc是降序关键字。很多新手第一反应是换字段名，但如果是老系统里已经存在的表，改字段名代价太大，正确的做法是加反引号：

sql复制SELECT `order`, `desc` FROM t_order;

建表语句同样可以用反引号包住关键字字段。这个点虽然小，但实际工作中遇到频率很高，特别是从别的数据库迁移过来的表，字段名里经常带关键字。我的建议是，新设计表结构时避开关键字做字段名，老表就别动了，查询时统一加反引号，一劳永逸。

另外提醒一下，反引号在MySQL里是标识符引用符，字符串要用单引号，千万别搞混。我见过有人写SQL把字符串值用反引号包着，结果MySQL把它当成列名来解析，报错Unknown column，排查半天才发现是引号用错了类型。

3.3 常用函数的易错点：CONCAT、COUNT、NOW这些坑

函数是场景题里最灵活的一类，因为你不知道面试官会从哪个函数下手。我通常会挑几个开发中使用频率最高、坑也最多的函数来问。

CONCAT拼接字符串，如果任何一个参数是NULL，结果就是NULL：

sql复制SELECT CONCAT(first_name, last_name) FROM users;

万一last_name是NULL，整个查询结果变成NULL。正确做法是用CONCAT_WS或者先处理NULL：

sql复制SELECT CONCAT_WS(' ', first_name, last_name) FROM users;

CONCAT_WS会忽略NULL值，不会把整个结果吃掉。

COUNT()和COUNT(字段)的区别也是高频题。COUNT()统计行数，包括NULL行；COUNT(字段)统计该字段非NULL的行数。如果你想知道一个表到底有多少条有效记录，用COUNT(字段)可能会少算，这个差异在数据统计场景里会直接影响报表数值。

NOW()和SYSDATE()也容易混淆。NOW()是语句开始执行的时间点，SYSDATE()是函数被调用时的时间点。在一条慢SQL里连续执行两次SYSDATE()，返回的时间可能不同，而NOW()始终一致。这个细微差别在基于时间戳做数据比对时会出问题。

4. 表结构与数据初始化场景题：加唯一约束报错，重复数据怎么处理

这个场景我太熟了，几乎每次给老表加唯一索引都会遇到。业务上要对user_id和sku_id的组合做唯一约束，于是DBA执行：

sql复制ALTER TABLE user_sku ADD UNIQUE INDEX uk_user_sku (user_id, sku_id);

结果报错：Duplicate entry '1-100' for key 'uk_user_sku'。一看就是表里已经有重复数据了，唯一索引加不上。这题考的不只是SQL，还有数据治理的思路，因为处理重复数据没有唯一标准答案，需要结合业务决定保留哪条、删除哪条。

4.1 先找出重复数据，再决定保留策略

第一步永远是定位重复。经典SQL：

sql复制SELECT user_id, sku_id, COUNT(*) AS cnt
FROM user_sku
GROUP BY user_id, sku_id
HAVING COUNT(*) > 1;

这条SQL把重复的组合和数量全列出来了。接下来要结合业务决定保留哪条记录。最常见的诉求是每个user_id和sku_id只保留一条记录，那就可以按id保留最小或最大的一条。

我常用的是套一层子查询，拿到每个重复组的最大id，然后删除不在这个集合里的记录。比如保留每组最大id，其余删除：

sql复制DELETE FROM user_sku 
WHERE id NOT IN (
  SELECT max_id FROM (
    SELECT MAX(id) AS max_id
    FROM user_sku
    GROUP BY user_id, sku_id
  ) t
);

这里有个需要注意的细节，子查询必须再包一层，否则MySQL会报“You can't specify target table 'user_sku' for update in FROM clause”错误，因为MySQL不允许在同一张表的子查询里直接进行UPDATE/DELETE操作。这个坑我踩过不止一次，每次都要解释半天。

注意：在删除重复数据之前，先把要删除的记录备份一下。哪怕是临时表也行，万一删错了还能恢复。生产环境的数据操作，宁可多一步备份，也不要高估自己的手速。

处理完重复数据，再执行ALTER TABLE加唯一索引就能顺利通过了。

4.2 大批量表结构修改：为什么ALTER TABLE会锁住线上业务

老表加字段、加索引这类操作，在数据量小的时候毫无感觉，但到了千万级数据量，直接ALTER TABLE可能让整个业务卡死。原因是MySQL的DDL操作在多数情况下需要重建表，期间会对表加元数据锁，其他事务的读写会被阻塞。

早期的ALTER TABLE行为是COPY算法，需要把整张表复制一份，期间DML全部阻塞。后来InnoDB支持了在线DDL，但很多操作依然存在锁表窗口。MySQL 8.0引入了INSTANT算法，只修改元数据不重建表，可惜目前只支持部分操作，比如加列在某些条件下可以用INSTANT。

如果一张千万级的表要改索引，我的建议是不要在生产环境直接执行原生ALTER TABLE，而是用工具。pt-online-schema-change或者gh-ost都是成熟的在线表结构变更工具，原理是先建一张新表，然后通过触发器或二进制日志把增量数据同步到新表，最后切换表名。整个过程对业务的影响很小，几乎无感知。

不过工具虽好，也要注意场景。如果表上没有主键，这类工具基本用不了，因为同步逻辑依赖主键定位行。所以建表一定要有主键，这不仅是规范问题，还是后续所有运维操作的基石。

4.3 存储过程和触发器：DELIMITER分隔符到底解决什么问题

存储过程和触发器在面试场景题里出现的频率不低，但考察的点往往很具体。比如“MySQL中触发器中分隔符”这个热搜词，就引出了一个经典问题：为什么写触发器要先执行DELIMITER //这样的语句？

原因很简单，MySQL客户端默认把分号当成SQL语句的结束符。一个触发器里有BEGIN...END结构的语句块，内部必然包含多条用分号结尾的SQL。如果不告诉客户端“这段整体是一个对象”，客户端会在第一个分号处就尝试执行，结果语法报错。DELIMITER的作用就是把语句结束符临时改成其他符号，把整个触发器或存储过程作为一个整体提交给服务端。

sql复制DELIMITER //
CREATE TRIGGER trg_after_insert_order
AFTER INSERT ON orders
FOR EACH ROW
BEGIN
  UPDATE goods SET stock = stock - NEW.quantity WHERE id = NEW.goods_id;
END//
DELIMITER ;

注意最后要把分隔符改回来。这个细节在面试时很容易被忽略，但在实际脚本里漏了会导致后面的SQL全部执行错误。

存储过程的场景题还会考到一点：存储过程里如何捕获异常。MySQL里通过DECLARE CONTINUE HANDLER来声明异常处理：

sql复制DECLARE CONTINUE HANDLER FOR SQLEXCEPTION 
BEGIN
  ROLLBACK;
END;

这个语法不常用，但真用到的时候特别有用，特别是批量数据初始化的脚本，每条记录都可能因为唯一键冲突、外键约束失败而中断。没有异常处理时，一个报错整个脚本就停了，有了异常处理就能跳过脏数据继续执行。

5. 连接与部署场景题：2059、认证协议、启动报错一次说清

最后一类场景题，不涉及复杂的SQL优化，但几乎是每个用MySQL的人都会遇到的操作性问题。别小看这类题，面试官问出来往往是想考察你平时有没有真的在部署环境、维护数据库，而不是只在云数据库控制台上点点点。

5.1 连接MySQL报2059错误：认证插件不匹配

MySQL 8.0安装完，用Navicat或者老版本的JDBC驱动连接，经常报错：Authentication plugin 'caching_sha2_password' cannot be loaded，或者错误码2059。这个问题的根源是MySQL 8.0把默认的身份认证插件从mysql_native_password改成了caching_sha2_password，老客户端不认识新插件。

解决办法最常用的是给用户指定老的认证插件：

sql复制ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';

执行完再连接就正常了。但这里要提醒一句：mysql_native_password在MySQL 8.0.34版本开始被标记为弃用，官方建议要逐步迁移到caching_sha2_password。如果你用的是新版本，更推荐的做法是升级数据库驱动或换新版客户端，而不是反过来迁就老插件。尤其是Java连接MySQL，驱动版本在5.1.49之前对caching_sha2_password支持不完整，升级驱动到8.x就能解决。

还有一类类似的问题，使用Delphi的Firedac组件连接MySQL时提示“client does not support authentication protocol requested by server”，本质上也是同一个问题。解决方案同样是对应用户改成mysql_native_password认证，或者给专门的应用账号单独设置认证方式，别动全局配置。

5.2 端口、服务启动和安装过程常见报错

MySQL默认端口是3306，这个大部分人都知道。但改端口时有一个坑：改了配置文件my.ini或my.cnf里的port，启动时却还是用旧端口。原因通常是配置文件读取了错误路径，MySQL服务启动时没有加载到你改的那个配置文件。Linux下可以用：

bash复制mysql --help | grep 'Default options' -A 1

查看MySQL启动时读取配置文件的顺序，确认你改的文件在读取列表中。

Windows安装MySQL时，最常见的启动报错是“服务启动失败，请查看日志”。我排查过很多次，大部分是两类问题：一是my.ini里的datadir路径不对，或者指向了不存在的目录；二是磁盘权限不够，MySQL服务账户没有data目录的读写权限。还有一个很经典的问题，之前装过旧版本MySQL，服务名已经被占用，新版本安装时服务创建失败。这种情况把旧服务卸载干净，同时检查C盘目录残留，再重新安装。

安装完MySQL后第一步做什么？我的建议是马上执行：

sql复制SELECT VERSION();
SHOW VARIABLES LIKE 'character_set%';

先确认版本和字符集。很多业务后续出现中文乱码，都是因为在初始化阶段没统一字符集，到了上线才发现。初始化阶段就把character_set_server、character_set_database统一成utf8mb4，以后能省掉一堆乱码的烦心事。

5.3 Docker部署MySQL的几个必知参数

Docker部署MySQL也成了现在面试的基础题。最简单的启动命令很简单，但有几个参数不能省：

bash复制docker run -d \
  --name mysql8 \
  -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD=yourpassword \
  -e TZ=Asia/Shanghai \
  -v /data/mysql:/var/lib/mysql \
  mysql:8.0

这里我特别强调挂载数据目录，理由不用多说，容器一旦重建，不挂载的话数据全部丢失。时区也要设置，不设置的话默认UTC时间，和本地时间差8个小时，业务日志和数据库时间对不上，排查问题时会非常痛苦。

Docker里还有个坑是容器重启后MySQL服务自动启动与否，取决于docker restart policies。建议启动时加--restart=always，保证服务器重启后容器自动恢复。另外容器里的MySQL默认只监听3306端口，宿主机端口映射要用-p参数暴露出来。如果外部连接不上，先检查docker ps确认容器状态，再检查宿主机防火墙是否放行了3306端口。

提示：不要在Docker容器里直接执行mysql_upgrade或ALTER USER来修改认证插件后重启容器，有些镜像重启后会自动初始化用户，导致修改丢失。正确做法是进容器执行完修改后，用docker commit保存镜像，或者在启动时直接用环境变量和初始化脚本处理。

我在实操中养成的习惯是，每次装完MySQL第一件事就是写一条连接测试，确认能连上、能建库、能建表、能读写中文，然后再交给业务方。这个习惯看起来简单，但真的帮我跳过很多隐性配置问题，比如配置文件没生效、端口没开放、认证方式不兼容等等。

还有一个小技巧想分享：遇到任何奇怪的MySQL问题，先别急着百度，先看错误日志。MySQL的error log里会明确指出问题的具体位置和原因，比如InnoDB启动失败会告诉你redo log文件损坏，权限问题会告诉你具体的OS错误码。日志路径通常在datadir下面，文件名叫hostname.err。Windows下一般在MySQL安装目录的data文件夹里。这个习惯帮我解决过至少几十个“看起来毫无头绪”的问题，比任何经验帖都靠谱。