MySQL面试高频考点全解析：存储过程、索引优化与锁表实战

1. 从一道“简单”的存储过程题说起：分隔符和异常处理

最近帮一个朋友复盘MySQL面试，被问到存储过程时他卡了壳，其实这是面试场景题里很经典的一类——题目本身不难，但你得刷出“经验感”。

面试官当时出了这么一道题：写一个存储过程，向订单表批量插入100条数据，要求注释清楚，同时处理“主键冲突”的情况。很多人第一反应是直接把循环写出来，但真上手的时候，第一个问题就栽了：delimiter 到底有什么用？为什么在命令行里面写完存储过程总报语法错误？

“mysql中触发器中分隔符”这个热搜词常年挂在MySQL相关搜索里，说明这是新人重灾区。你可以在navicat、workbench这类图形工具里轻松写完一个存储过程，因为图形工具在一定程度上帮你处理了语句分隔的问题，但面试时考官更希望你理解底层逻辑。

这里用一个生活类比：你把一段话写到纸上，句号表示一句话结束。但如果你这段话里有一块是“嵌套引文”，引文里又有句号，那你在读的时候怎么知道哪个句号是真正的结束？delimiter要解决的就是这个。默认情况下MySQL客户端把分号当作一条语句的结束标志，而存储过程体内部每行都有分号。如果不用delimiter把整个过程的结束符临时改成//或$$，MySQL会在第一个分号处就认为语句结束了，于是报错。

实操里我习惯这样写：

sql复制DELIMITER $$

DROP PROCEDURE IF EXISTS batch_insert_orders$$

CREATE PROCEDURE batch_insert_orders(IN insert_count INT)
BEGIN
    DECLARE i INT DEFAULT 1;
    WHILE i <= insert_count DO
        INSERT IGNORE INTO orders(order_no, amount, create_time)
        VALUES (CONCAT('SO', DATE_FORMAT(NOW(),'%Y%m%d'), LPAD(i,4,'0')), 100.00, NOW());
        SET i = i + 1;
    END WHILE;
END$$

DELIMITER ;

注意看几个细节：

• 在DELIMITER $$之后，存储过程的结尾用$$，而过程体内部的分号不再被当作整段语句的结束。
• 写完过程后，立刻把分隔符改回分号。很多人容易漏这一步，漏了之后当前mysql交互终端里，连普通的SELECT * FROM table;都会出问题。
• 用INSERT IGNORE而不是INSERT，配合主键冲突“跳过”而不是“报错中断”。这在实际批量初始化数据时很实用。

既然提到了异常，就顺势把“mysql储存过程+错误信息”也一起聊了。面试里常见的进阶问题是：存储过程里INSERT遇到重复键，你怎么单独捕获并继续执行？大多数人的第一反应是写DECLARE EXIT HANDLER FOR SQLEXCEPTION，但这里有个容易搞混的点，EXIT和CONTINUE语义差别很大。

sql复制DELIMITER $$

CREATE PROCEDURE insert_order_with_handler(IN order_no VARCHAR(30))
BEGIN
    DECLARE CONTINUE HANDLER FOR 1062
    BEGIN
        SELECT 'duplicate key, skip this record' AS warn_message;
    END;

    INSERT INTO orders(order_no, amount, create_time)
    VALUES (order_no, 50.00, NOW());
END$$

DELIMITER ;

1062是MySQL主键/唯一键重复的ER_DUP_ENTRY错误码，CONTINUE HANDLER表示“出错后继续执行后面的语句”，适合批量场景；“EXIT HANDLER”则表示“出错后直接退出当前begin end块”，适合希望立刻感知异常的场景。面试时能把这两点讲清楚，比背一堆语法更能体现你的实战经验。

提示：在MySQL 8.0里，还可以用GET DIAGNOSTICS拿到更具体的错误信息，但面试笔试阶段很少有人深入到这里，知道原理即可，真用到时再翻官方文档。

2. 排名问题：窗口函数、变量、自连接三种解法

“mysql排序”相关的题目在面试题里几乎是必出题型。最常见的场景就是：有一张学生成绩表，要求查出每个班级总分排名前三的学生。

第一反应当然是用MySQL 8.0的窗口函数：

sql复制SELECT class_name, student_name, total_score, ranking
FROM (
    SELECT 
        class_name,
        student_name,
        total_score,
        ROW_NUMBER() OVER (PARTITION BY class_name ORDER BY total_score DESC) AS ranking
    FROM student_score
) t
WHERE ranking <= 3;

这里特别要注意RANK()、DENSE_RANK()和ROW_NUMBER()三者的区别：

• ROW_NUMBER()：顺序编号，同分也会生成不同名次，比如两个并列第一，会给出1、2。
• RANK()：相同分数相同名次，且会跳号，比如两个并列第一，下一个名次是3。
• DENSE_RANK()：相同分数相同名次，但不跳号，两个并列第一之后是2。

面试官如果追问“需求是并列名次也同时输出，该用哪个”，答RANK()即可。

如果面试官让你用低版本MySQL实现，不能走窗口函数，那常见的做法是用@变量来模拟“分区排序”。这个方案有一个经典坑：变量在跨分区时没有自动归零，必须按班级分组、排序后，再按班级修改或者用“双字段”方式计算排名字段。

我见过一个常见的错误写法是：

sql复制SET @rank = 0;
SET @prev_class = '';
SELECT 
    class_name,
    student_name,
    total_score,
    @rank := IF(@prev_class = class_name, @rank + 1, 1) AS ranking,
    @prev_class := class_name
FROM student_score
ORDER BY class_name, total_score DESC;

这段逻辑看起来正确，但执行顺序上，SELECT里对@prev_class赋值后再判断@rank，容易产生“错位”。更稳妥的办法是把排序结果先扔进一个派生表，再在外面计算名次：

sql复制SET @rank = 0;
SET @prev_class = '';

SELECT 
    class_name,
    student_name,
    total_score,
    IF(@prev_class = class_name, @rank := @rank + 1, @rank := 1) AS ranking,
    @prev_class := class_name
FROM (
    SELECT class_name, student_name, total_score
    FROM student_score
    ORDER BY class_name, total_score DESC
) t;

用变量还有一个隐患：MySQL官方文档里并没有承诺用户变量在SELECT表达式中按你书写的顺序求值。也就是说，靠“同一行里先给@rank赋值再给@prev_class赋值”的做法，本质上属于“依赖执行顺序的编程”。在8.0版本里窗口函数已经够成熟，实在没必要纠结变量方案，但如果面试官故意问老版本兼容，你至少得说出变量方案“存在求值顺序风险”。

再说第三种解法：自连接。如果成绩表里不存在完全同分的情况，可以这样写：

sql复制SELECT a.class_name, a.student_name, a.total_score
FROM student_score a
WHERE (
    SELECT COUNT(*)
    FROM student_score b
    WHERE a.class_name = b.class_name AND b.total_score > a.total_score
) < 3
ORDER BY a.class_name, a.total_score DESC;

这个写法的核心逻辑是“找出班里成绩比当前学生高的，人数少于3”，那么当前学生就是班级前三。缺点是成绩列没有唯一索引时，完全同分的场景会比预期多查出一些记录，所以判断“是否需要去重并列”时，用自连接得带上AND b.student_id <> a.student_id这类条件，具体看需求。

顺带提一嘴排序类的性能问题：如果total_score列上有索引，且查询条件里带了WHERE class_name = '某个班'，排序大概率能走索引，但如果是要对整张大表做ORDER BY total_score DESC LIMIT 3，通常避免不了filesort。面试里如果被问到“怎么优化排序”，不要只答“建索引”，要分析filesort发生在内存还是磁盘，然后提到控制排序行宽、使用覆盖索引、max_length_for_sort_data参数等方向。

提示：窗口函数在MySQL 8.0、MariaDB 10.2+里都支持。如果面试官提到生产库还是5.7，那么用“自连接 + 派生表”的方案可能更稳妥，但查询复杂度会高一些。

3. 锁表了，你的排查思路是什么

“mysql锁表”是面试中特别容易引出连环追问的话题。面试官常见的套路是：线上有一张订单表的UPDATE语句突然执行很慢，一段时间后直接报锁等待超时，你怎么排查？

实话实说，最早我也踩过坑。有一次执行一个批量更新，条件字段没有走索引，结果锁范围从单行扩展到了全表，后面所有针对该表的写操作全被卡住。当时第一个反应是“重启”，但重启前先查了information_schema.innodb_trx和sys.innodb_lock_waits，很快就锁定事务ID，然后KILL，整个过程不到一分钟。

面试时可以直接把这段真实经历讲出来，再补充几个关键知识点：

• 根据数据行所在索引类型，InnoDB锁可以分为记录锁、间隙锁、临键锁。更新数据尽量走唯一索引或主键，可以很大程度上减少锁冲突。
• 如果UPDATE条件的列上没有索引，InnoDB会锁住全表扫描到的所有记录，相当于把整张表都堵住了。
• 长事务是锁等待的根源，要控制事务大小，频繁提交，不要把多个业务操作塞进一个事务里。
• 明确“当前读”和“快照读”的区别。SELECT ... FOR UPDATE、UPDATE、DELETE都是当前读，读取最新版本并加锁；普通SELECT是快照读，靠MVCC实现不加锁读取。

接着面试官如果有兴趣，会追问间隙锁和临键锁。最典型的场景：在可重复读隔离级别下，执行

sql复制SELECT * FROM orders WHERE amount BETWEEN 100 AND 200 FOR UPDATE;

如果amount列上存在索引，命中的记录加记录锁，同时还会在100~200这个区间加间隙锁，防止其他事务在这个区间插入新记录。这就是InnoDB防止幻读的重要手段——本质上，间隙锁锁的是“索引记录之间的间隙”，而不是“某条具体记录”。

完整排查实践中，我可以给出一个可用的SQL组合：

sql复制-- 查看当前所有事务
SELECT * FROM information_schema.innodb_trx\G;

-- 查看锁等待关系
SELECT 
    r.trx_id AS waiting_trx_id,
    r.trx_mysql_thread_id AS waiting_thread,
    b.trx_id AS blocking_trx_id,
    b.trx_mysql_thread_id AS blocking_thread
FROM performance_schema.data_lock_waits w
JOIN information_schema.innodb_trx r ON w.requesting_engine_transaction_id = r.trx_id
JOIN information_schema.innodb_trx b ON w.blocking_engine_transaction_id = b.trx_id;

注意，8.0里我曾用information_schema.innodb_lock_waits，这个视图在部分版本中可能不再推荐，改用performance_schema.data_lock_waits更稳。如果确定了阻塞线程，就用：

sql复制KILL <thread_id>;

关于避免锁表，我的经验就一句话：UPDATE和DELETE一定要带主键或唯一索引条件，并确保索引有效。此外，大范围批量更新可以拆成小批次，每次更新500~1000条，配合SLEEP(0.1)，能大大降低锁竞争。

最后如果面试官问“死锁怎么排查”，你就说看SHOW ENGINE INNODB STATUS里的LATEST DETECTED DEADLOCK段落，里面会明确指出两个事务各持有什么锁、等待什么锁。一般死锁都是由两个事务以不同顺序加锁导致的，解决方式就是约定一致的加锁顺序。

4. 索引失效的几个典型场景

面试里索引失效是必考点，基本上会拿一条多条件查询让你判断“能不能走索引”。我总结最常考的几类：

第一类：最左前缀原则理解不到位。有一个联合索引(a, b, c)，查询条件是WHERE b = 1 AND c = 2，很多人以为“用了联合索引”，但实际只能走a的等值匹配？等等，这里是没带a，那这个查询就完全用不到该联合索引，或者最多用索引条件下推优化，但无法高效定位。

第二类：在索引列上做函数运算或隐式类型转换。比如WHERE DATE(create_time) = '2025-01-01'就可能导致索引失效，但如果把条件改成WHERE create_time >= '2025-01-01' AND create_time < '2025-01-02'，就能走范围索引。隐式类型转换则是经典的WHERE phone = 13800001111，若phone字段是varchar，查询条件写成了数值，MySQL会把字段值转成数值再比较，索引也就失效了。

第三类：LIKE '%关键词%'会导致索引失效，而LIKE '关键词%'可以走范围索引。这个比较简单，很多人也知道。

第四类：OR语句。热搜词里正好有一个“mysql的or能去重吗”，说明很多人在面试/实际使用中含糊不清。

先直接回答“or能去重吗”这个问题：or本身是逻辑或，它不去重。 去重是DISTINCT或UNION的功能。比如：

sql复制SELECT id FROM t1 WHERE a = 1 OR b = 2;

这个SQL是返回所有满足a=1或b=2的行，如果存在同一条记录同时满足两个条件，它只会被查出来一次？不对，实际上如果WHERE条件匹配的是同一行，那它自然只出现一次，因为SELECT返回的是表里的行，不是集合运算结果。但如果该行a=1,b=2同时满足，它作为一行记录只出现一次，这跟“去重”无关，只是结果集本身就是行集合。

如果把问题理解成“OR能不能把多个条件的结果去重合并”，那么在SQL层面，OR确实不会做去重合并，它就是一个逻辑表达式。想要把两个查询结果合并并且去重，应该用UNION；不需要去重用UNION ALL。这题问到本质，面试官是想确认你有没有混淆“OR条件”和“UNION集合操作”的概念。

回到索引失效，OR还有一个大坑：WHERE a = 1 OR b = 2，如果a和b只有其中一个字段有索引，MySQL很可能会放弃索引走到全表扫描，因为OR连接的两个条件需要“并集”结果，使用索引合并（index merge）优化器，往往只有在两个条件都列上有索引时才可能生效。

面试中如果出这样的题：“有一张表t，字段a有索引，b没有索引，查询WHERE a = 1 OR b = 2，会怎么执行？”标准答案是大概率全表扫描。如果改为WHERE a = 1 UNION SELECT ... WHERE b = 2，自己把两个条件拆开，反而能分别用索引。

第五类：NOT IN / !=容易让优化器放弃索引（但也不是绝对，与数据分布有关）。MySQL优化器有时会根据区分度决定是否走索引，所以死背“不等于一定不走索引”不严谨，但面试时可以按“通常会导致优化器选择全表扫描”来回答。

我建议准备这类题时，多准备一个“实操验证”的思路，这也是面试加分项：

sql复制EXPLAIN SELECT ...;

通过EXPLAIN看type列，是const、ref、range还是ALL，一眼就能判断有没有走索引。如果面试官允许你现场演示，这个细节会让你显得很专业。

5. 容易忽视的细节题：int(5)、UPDATE语法、关键字字段、端口号

这类题不属于“手写大段SQL”的场景，但往往能在小问题上拉开差距，因为它考察的是“踩坑经验”。

5.1 int(5)到底是什么意思

热搜词里“mysql中int+5”被反复搜索，说明很多人被它误导过。记住一句话：int(5)不是限制存储数值范围为5位，它只是显示宽度。int(5)和int(11)在存储范围上完全一样，都是-2147483648到2147483647（无符号则是0到4294967295）。只有在搭配ZEROFILL属性时，显示宽度才会起作用：比如INT(5) ZEROFILL，存12会显示00012。

面试时如果说“int(5)限制最大是99999”，那就直接翻车了。

5.2 UPDATE语法的正确姿势

“mysql update语法”热搜词背后，反映的是很多人写UPDATE时没有先SELECT确认条件字段。面试中有一个经典连环题：执行UPDATE t SET a = a + 1 WHERE id = 1;，如果事务没提交，另一个会话执行同样语句会怎样？

回答：先看隔离级别。在可重复读下，另一会话执行该UPDATE会等待行锁；在提交读下，同样会等待，然后读到最新已提交的值并执行。真正值得讲的点是：UPDATE语句本身会加锁，如果条件没走索引，那么锁的范围会扩大。

另一个坑是“批量更新顺序不一致导致死锁”，比如事务A先更新id=1再更新id=2，事务B先更新id=2再更新id=1，两个事务大概率死锁。解决方式是业务层对更新操作按相同顺序排列。

5.3 字段是关键字怎么办

热搜词“mysql表中字段为关键字”也是高频踩坑点。比如建表时某个列叫order、group、desc、key，这时不加任何处理直接写SQL就会报语法错误。

正确做法是用反引号包裹：

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

注意这里连表名order_info都可能需要反引号，如果表名也叫order。更本质的规避手段是建表时就避免用保留字做字段名，比如改成order_no、order_status，这也符合实际编码规范。

5.4 触发器里的NEW和OLD

触发器是MySQL中容易忽略的知识点。面试题里往往这样出：写一个BEFORE INSERT触发器，把新插入数据的create_time自动设置为当前时间。这里的关键就是NEW和OLD。

• NEW代表新记录。
• OLD代表被修改前的旧记录。
• INSERT里只有NEW可用；DELETE里只有OLD可用；UPDATE里两者都可。

结合热搜词“mysql中触发器中分隔符”，写一个完整示例：

sql复制DELIMITER $$

CREATE TRIGGER trg_orders_before_insert
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
    IF NEW.create_time IS NULL THEN
        SET NEW.create_time = NOW();
    END IF;
END$$

DELIMITER ;

这种“触发器内做默认值兜底”在老的业务系统里很常见。但面试时最好补充一句“触发器会带来隐式逻辑，审计定位困难，新项目里我会更倾向在应用层统一处理默认值。”

5.5 端口号和连接错误

“mysql端口号”和“mysql连接2059错误”是热搜里的难兄难弟。MySQL默认端口号是3306，这个面试必背。但2059错误非常多见：当你用Navicat连接MySQL 8.0时，经常会报Authentication plugin 'caching_sha2_password' cannot be loaded，错误码正是2059。

原因是MySQL 8.0默认认证插件改了。旧版本是mysql_native_password，8.0默认换成caching_sha2_password，旧版客户端不识别，所以连不上。解决办法有两种：

第一种，改用户的认证插件：

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

第二种，更新客户端版本，使其支持caching_sha2_password。实际工作中，如果内网环境大量使用旧客户端，我通常会选择第一种兼容方式，但要注意这是降低了一点安全性换取兼容性。

提示：面试时能主动联系到“8.0默认认证插件变更”这一背景，说明你确实在真实环境里遇到过问题，而不是背了一堆手册。

6. 关于索引、连接、Workbench和数据库设计，还有几个值得提前准备的题

既然这是一篇面试场景题的延续，我就把热搜里其余几个容易被当成“理所当然”的知识点也一并整理出来，因为你不知道面试官会从哪个角度切入。

6.1 如何用Workbench快速建表

热搜词“mysql workbench如何快速用命令行新建数据表”说明很多图形工具用户在面试时对纯命令行操作没底气。其实这类题问的是“你会不会建表”。手写建表SQL应当干净利落：

sql复制CREATE TABLE students (
    student_id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '学生ID',
    student_name VARCHAR(50) NOT NULL COMMENT '姓名',
    class_id INT UNSIGNED NOT NULL COMMENT '班级ID',
    total_score DECIMAL(5,1) DEFAULT 0.0 COMMENT '总分',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (student_id),
    KEY idx_class_id (class_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='学生成绩表';

这段建表语句里有几个细节会加分：

• DECIMAL(5,1)能存最大9999.9，正好适合存百分制成绩。
• ON UPDATE CURRENT_TIMESTAMP让记录更新的时间自动维护，很多人在面试手写时容易漏。
• 表字段和表都加COMMENT，这体现了实际开发里的好习惯。
• utf8mb4比utf8更推荐，因为它能存emoji和特殊字符，是8.0时代的基本默认值。

如果被追问“为什么用DECIMAL而不用FLOAT”，就答：金额/成绩这类精确数值用浮点数容易出现精度误差，DECIMAL是定点数，按十进制存储，更可靠。

6.2 学生课程成绩信息实体表设计

热搜词里专门有一条“学生课程成绩信息实体表设计mysql”，这是一个数据库设计的经典场景题，非常适合作为面试压轴题。

核心场景是三张核心表加两张关联表，但“成绩”到底是放在关联表里，还是单独建一张表？这个点值得讨论一下：

最简单合理的设计是：

• 学生表：student_id、student_name、gender、class_name
• 课程表：course_id、course_name、credit
• 成绩表：score_id、student_id、course_id、score_value、exam_time

为什么成绩要单独建成一张表？因为同一个学生在同一门课上可能参加多次考试（补考、重考），需要保留每次成绩。如果把成绩字段当作学生表和课程表之间的关联属性字段，就无法自然地保存历史多次记录。

完整的建表SQL参考：

sql复制CREATE TABLE student (
    student_id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
    student_name VARCHAR(30) NOT NULL,
    gender TINYINT DEFAULT 0 COMMENT '0未知 1男 2女',
    class_name VARCHAR(50)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE course (
    course_id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
    course_name VARCHAR(50) NOT NULL,
    credit DECIMAL(3,1) DEFAULT 0.0
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE student_score (
    score_id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
    student_id INT UNSIGNED NOT NULL,
    course_id INT UNSIGNED NOT NULL,
    score_value DECIMAL(5,1) NOT NULL,
    exam_time DATETIME NOT NULL,
    KEY idx_student_course (student_id, course_id),
    CONSTRAINT fk_score_student FOREIGN KEY (student_id) REFERENCES student(student_id),
    CONSTRAINT fk_score_course FOREIGN KEY (course_id) REFERENCES course(course_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='考试成绩表';

成绩表上建联合索引(student_id, course_id)，是因为最常见的查询就是“查某个学生的所有成绩”和“查某门课的所有学生成绩”。联合索引可以同时覆盖这两种查询的定位需求。外键约束在面试中可以提到，但实际开发中很多团队会禁用物理外键，改用应用层保证完整性，因为物理外键在分库分表时反而会带来迁移麻烦。

6.3 常用函数与存储过程扩展

热搜里“mysql常用函数”和“mysql储存过程+错误信息”一并出现，面试时可能会要求你“说出几个常用的聚合函数和字符串函数”。一般这样回答比较稳：聚合函数COUNT、SUM、AVG、MAX、MIN；字符串函数CONCAT、SUBSTRING、REPLACE、LENGTH；日期函数NOW、DATE_FORMAT、DATEDIFF、DATE_ADD。

不要贪多，挑几个常用的快速说出用途就够了，重点是如果你提到GROUP BY，要能接住“聚合函数与分组的关系”、“HAVING和WHERE的区别”这类连环题。

6.4 实体关系图导出与更复杂的场景

热搜词“mysql的表导出er关系图”比较偏工具类。如果你在MySQL Workbench里，可以这样操作：菜单Database → Reverse Engineer，然后选择连接，自动逆向生成ER图。Navicat里则是：选中模型，然后从数据库导入表结构。面试不会直接考“点击哪个按钮”，但如果你简历里写了“熟悉数据库设计”，面试官可能让你用一句话描述“你如何快速梳理现有系统的表关系”，逆向ER图是一个实用的回答。

7. 几个“伪装成操作题”的经验型选择题

在我的面试复盘经验里，MySQL相关考察往往会从具体问题延伸到“你到底有没有在生产环境踩过坑”。这里把最容易踩坑的几个情况一起讲掉。

7.1 执行过一次更新，但数据没变，为什么

类问题：执行UPDATE t SET status = 1 WHERE id = 1;，影响行数返回0，但数据明明就是status=1。有的人以为更新失败了。实际上影响行数0不代表出错，可能只是新值和旧值相同，MySQL默认行为是如果更新前后值一样，就不实际修改。这是InnoDB在UPDATE执行时做的一个“值对比”优化。

面试考点是“你知道ROW_COUNT()返回什么吗？”如果你执行UPDATE但值没有变化，ROW_COUNT()返回0；如果加上CLIENT_FOUND_ROWS标志，返回的才是“匹配到的行数”。JDBC里可以通过useAffectedRows=true/false控制。这种冷门细节在面试里一般不会深入，但知道会让你显得经验充足。

7.2 用Docker安装MySQL时容易忽略的端口映射问题

热搜里“docker安装mysql”和“mysql端口号”经常一起出现。Docker跑MySQL很容易遇到“容器内能连，宿主机连不上”，本质上是端口映射或权限配置问题。如果面试被问到“Docker部署MySQL需要注意什么”，不一定是在考Docker，更可能是考“你懂不懂MySQL初始化”。

至少应该提到这几点：

• 挂载数据目录到宿主机，避免容器删除后数据丢失。
• 设置环境变量MYSQL_ROOT_PASSWORD、MYSQL_DATABASE等。
• 映射端口如3306:3306时，如果宿主机3306被占，可以改3307:3306。
• 连接时因为认证插件问题连不上的话，参考上面第5.5节所说的caching_sha2_password处理方式。

7.3 连接、端口、JDBC驱动版本

如果面试官问“MySQL JDBC连接串怎么写”，你得能脱口而出：

code复制jdbc:mysql://localhost:3306/test_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false

注意serverTimezone参数在8.0 JDBC驱动里几乎是必备的，因为驱动会校验服务器时区。此外allowMultiQueries=true（允许一次执行多条SQL）实际中一般不建议开启，因为会增加SQL注入面。

如果面试问“为什么驱动版本要匹配数据库版本”，你答“旧驱动不支持新版本默认认证插件和新的通信协议”会比较专业。

7.4 数据库连接池与连接超时

提到JDBC，面试官经常会顺嘴问“连接池里的连接多久会断开”。答案与wait_timeout参数有关。如果数据库的wait_timeout设置为8小时，连接池中的连接超过8小时没有活动，会被服务器主动断开。客户端虽然不知道，但再次使用时会报“Connection is not available”之类的异常。

这是需要从JDBC和连接池层面同时解决的：连接池负责每次获取连接时做一次SELECT 1的活性和刷新，数据库侧可以适当调整wait_timeout，两者结合才能让连接复用更稳定。

8. 面试前我建议你亲手做一次的环境小实验

既然这是一篇给准备面试或刚入门的人看的内容，我给你一个只要有一台普通电脑就能做的验证清单，花一下午跑完，比背三天八股文都有效。

第一步，在本机装一个MySQL 8.0（Docker或直接安装都行）。建一个测试库，导入学生成绩数据，至少造10个班、每班50人。

第二步，分别用窗口函数、变量、自连接三种方式实现“每个班前三名”的查询，对比两种老方案的SQL写法和结果差异。

第三步，在ORDER BY total_score DESC LIMIT 3上加和不加idx_total_score索引，执行EXPLAIN查看type列的变化，观察Extra里有没有Using filesort。

第四步，开两个终端做锁等待实验：终端A开启事务执行UPDATE但不提交，终端B执行同一条UPDATE，模拟等待；期间在第三个终端查询information_schema.innodb_trx。

第五步，测试几条你印象中的“索引失效SQL”，比如WHERE DATE(create_time) = ...和WHERE create_time >= ... AND create_time < ...，用EXPLAIN对比。

这些实验做完，面试时聊起“MySQL实践心得”就有话可说，不再只是复述概念。

最后分享一个实际经验：面试官问MySQL相关问题时，比起背诵“索引失效七条规则”，他更愿意听到你用“有一次线上慢查询，我通过EXPLAIN发现……然后……”的方式讲一个具体故事。这也是我写这篇系列博文的初衷。

MySQL的面试题其实都可以落到“这题背后的原理，是为了解决什么问题”上。你把每一次报错、每一次锁等待、每一次EXPLAIN的结果当成面试素材，自然就不会发怵了。