Java 面试题›MySQL 面试题›为什么互联网大厂不推荐使用多表 JOIN？
面试考察点
架构思维：面试官不仅仅想知道 JOIN 有什么问题，更想考察你是否理解分布式架构下的数据访问模式，能否从系统可扩展性角度分析问题。
性能意识：是否理解 JOIN 操作在大数据量场景下的性能瓶颈，能否从索引、锁、内存等角度分析 JOIN 的成本。
实践经验：是否了解大厂的分库分表策略，能否给出替代 JOIN 的具体方案。
核心答案互联网大厂不推荐使用多表 JOIN，核心原因如下：
问题维度
具体表现
影响
性能问题
大表 JOIN 消耗大量内存和 CPU
查询变慢甚至超时
锁竞争
JOIN 涉及多表，锁定时间更长
并发性能下降
分库分表
跨库 JOIN 无法直接执行
架构受限
可扩展性
数据量增长后 JOIN 性能急剧下降
系统瓶颈
索引依赖
JOIN 依赖关联字段索引
索引维护成本高
代码耦合
SQL 逻辑复杂，难以维护
开发效率低
一句话总结：JOIN 在单机小数据量场景可用，但在大数据量、高并发、分布式架构下，会成为性能杀手和架构绊脚石。
深度解析一 ...
Java 面试题›MySQL 面试题›为什么不建议使用存储过程？
面试考察点
架构思维：面试官不仅仅想知道存储过程有什么缺点，更想考察你是否具备分层架构意识，能否理解 “业务逻辑应该在应用层而非数据库层” 的设计原则。
工程实践：是否经历过存储过程带来的维护痛点，能否从调试、版本控制、团队协作等角度分析实际问题。
权衡能力：是否了解存储过程适用的场景，而非一刀切地否定，懂得根据业务特点做技术选型。
核心答案现代互联网架构中，不建议使用存储过程，主要原因如下：
问题维度
具体表现
影响
可维护性
代码分散在应用和数据库，难以统一管理
排查问题困难
可调试性
缺乏完善的调试工具，日志难以追踪
定位 bug 成本高
可移植性
不同数据库语法差异大，迁移困难
技术绑定风险
扩展性
业务逻辑绑定数据库，难以水平扩展
性能瓶颈
团队协作
DBA 和开发职责混淆，代码审查困难
开发效率低
版本控制
SQL 代码难以纳入 Git 等版本管理
回滚困难
一句话总结：存储过程把业务逻辑下沉到数据库，违背了分层架构原则，导致维护难、调试难、扩展难。
深度解析一、架构层 ...
Java 面试题›MySQL 面试题›设计索引时应遵循哪些原则？
面试考察点
实战经验：面试官不仅仅想知道你会不会写 CREATE INDEX，更想考察你是否具备在生产环境中设计合理索引的能力，能否平衡查询性能与写入成本。
原理理解：是否理解 B+ 树结构、最左前缀原则、索引下推等底层原理，而非只会死记硬背几条规则。
权衡意识：索引不是越多越好，考察你是否懂得在查询性能、存储空间、写入性能之间做取舍。
核心答案设计索引应遵循以下 7 大核心原则：
原则
核心要点
关键词
选择合适的列
WHERE、JOIN、ORDER BY、GROUP BY 列优先
高频查询列
区分度高优先
选择性 = 唯一值/总行数，越高越好
基数大、离散度高
最左前缀原则
联合索引按顺序匹配，从左到右连续使用
范围查询断后
覆盖索引
索引包含查询所需全部字段，避免回表
SELECT 列也在索引中
控制索引数量
单表索引不超过 5 个，单个索引字段不超过 5 个
写入成本、空间占用
前缀索引
长字符串只索引前 N 个字符，节省空间
牺牲部分选择性
索引下推
...
Java 面试题›MySQL 面试题›binlog、redolog 和 undolog 的区别？
面试考察点
日志体系理解：面试官不仅仅是想知道三种日志的名字和定义，更是想知道你是否理解 MySQL 的日志体系架构，以及每种日志在整个事务生命周期中扮演的角色。
崩溃恢复机制：考察你是否清楚 MySQL 如何通过 redo log 保证持久性（D）、通过 undo log 保证原子性（A）和实现 MVCC，以及 binlog 在主从复制中的作用。
两阶段提交原理：是否理解 redo log 和 binlog 的 “两阶段提交” 机制，为什么需要这个机制来保证数据一致性。
核心答案MySQL 中这三种日志各司其职，核心区别如下：
对比维度
redo log
undo log
binlog
归属层级
InnoDB 引擎层
InnoDB 引擎层
MySQL Server 层
核心作用
崩溃恢复，保证持久性
事务回滚、MVCC，保证原子性
主从复制、数据备份
写入方式
循环写，空间固定
按事务写入
追加写，文件可配置
内容形式
物理日志（在某某页修改了什么）
逻辑日志 ...
Java 面试题›MySQL 面试题›如何进行 SQL 调优？
面试考察点
系统性思维：面试官不仅仅想知道你会不会加索引，更想考察你是否具备从”发现问题 → 定位问题 → 解决问题 → 验证效果”的完整调优思路。
工具掌握度：考察你是否熟练使用 EXPLAIN、SHOW PROFILE、慢查询日志 等调优工具，能否从执行计划中识别性能瓶颈。
原理理解深度：是否理解索引的数据结构（B+ 树）、索引失效场景、MySQL 优化器的工作机制，而非只会照搬网上八股文。
核心答案MySQL SQL 调优是一个系统化工程，核心流程如下：
flowchart LR
A["开启慢查询日志<br/>slow_query_log=ON"] --> B["定位慢 SQL<br/>mysqldumpslow 分析工具"]
B --> C["分析执行计划<br/>EXPLAIN 执行计划"]
C --> D["优化 ...
Java 面试题›MySQL 面试题›用了索引还是很慢，可能是什么原因？
面试考察点
索引原理理解深度：面试官不仅仅是想知道你背过 “索引失效的几种情况”，更是想考察你是否真正理解 B+ 树索引的工作原理、索引的选择性、覆盖索引等核心概念，以及为什么这些因素会影响查询性能。
生产环境排查能力：考察你是否具备实际的慢查询排查经验，能否通过 EXPLAIN 分析执行计划，定位到具体的性能瓶颈（是索引失效、回表次数过多、还是其他原因）。
系统性优化思维：面试官想了解你是否具备从多个维度（SQL 写法、索引设计、表结构、数据库配置、硬件资源）来分析和解决性能问题的能力，而不仅仅是知道 “加索引” 这一种手段。
核心答案即使查询使用了索引，仍然可能很慢，主要原因可以归纳为 6 大类：
类别
具体原因
影响
索引设计问题
索引选择性差、索引列顺序不当、索引冗余
扫描行数过多
SQL 写法问题
SELECT *、LIKE ‘%xxx’、函数操作、类型转换
索引失效或回表过多
数据分布问题
数据量过大、数据倾斜严重、热点数据集中
即使走索引也慢
表结构问题
字段过大、行过长 ...
Java 面试题›MySQL 面试题›什么是数据库死锁，怎么解决？
面试考察点
基础概念掌握：面试官不仅仅是想知道你听过 “死锁” 这个词，更是想考察你是否真正理解死锁产生的四个必要条件（互斥、占有并等待、不可抢占、循环等待），以及为什么在数据库中会发生死锁。
实际场景应对能力：考察你是否在项目中遇到过死锁问题，能否快速定位死锁的原因，以及是否有实际解决问题的经验。这反映了你对生产环境的掌控能力。
预防与解决的系统性思维：面试官想了解你是否具备从多个维度（数据库配置、SQL 编写规范、业务逻辑设计、监控预警）来预防和解决死锁的能力，而不仅仅是知道几个零散的知识点。
核心答案数据库死锁是指两个或多个事务在执行过程中，因争夺资源而造成的一种互相等待的现象。当死锁发生时，这些事务都无法继续执行，除非有外力介入打破这种循环等待。 解决方案可以从三个层面来处理：
层面
方法
说明
数据库层面
超时机制、死锁检测
innodb_lock_wait_timeout 设置等待超时；innodb_deadlock_detect 开启死锁检测（默认开启）
SQL 编写层面
统一访问顺序 ...
Java 面试题›MySQL 面试题›脏读、幻读、不可重复读是什么？
面试考察点
基础掌握度：面试官不仅仅是想知道三个概念的定义，更是想知道你是否理解它们产生的根本原因 —— 并发事务之间的数据干扰，以及它们之间的本质区别。
隔离级别理解：考察你是否清楚 MySQL 的四种事务隔离级别，以及每种隔离级别能解决哪些并发问题。
实践应用能力：能否根据业务场景选择合适的隔离级别，是否了解 MVCC（多版本并发控制）如何解决这些问题。
核心答案脏读、不可重复读、幻读是 数据库并发事务 中三种典型的数据不一致问题：
问题
定义
关注点
严重程度
脏读
读到其他事务未提交的数据
数据被回滚
⭐⭐⭐ 最严重
不可重复读
同一事务内，两次读取同一行数据结果不同
数据被修改/删除
⭐⭐ 中等
幻读
同一事务内，两次查询结果行数不同
数据被新增
⭐ 较轻
一句话总结：脏读是读了未提交的数据；不可重复读是同一条数据变了；幻读是结果集行数变了。
深度解析一、三种问题详解
时间线
事务 A
事务 B
T1
BEGIN;
T2
BEGIN;
T3
UP ...
Java 面试题›MySQL 面试题›慢查询怎么排查？
面试考察点
基础掌握度：面试官不仅仅是想知道慢查询日志怎么开，更是想知道你是否掌握从发现问题、定位问题、分析问题到解决问题的完整排查链路。
性能优化意识：考察你是否熟悉 EXPLAIN 执行计划的各项指标，能否根据执行计划判断 SQL 的性能瓶颈（全表扫描、索引失效、临时表等）。
生产实践经验：能否结合实际场景讲述慢查询优化的完整案例，包括如何定位、如何分析、如何优化、优化效果如何验证。
核心答案MySQL 慢查询排查遵循 “发现 → 定位 → 分析 → 优化 → 验证” 五步法：
步骤①：开启慢查询日志，捕获慢 SQL。
步骤②：查看慢查询日志，定位问题 SQL。
步骤③：使用 EXPLAIN 分析执行计划。
步骤④：根据分析结果优化（索引/SQL 改写）。
步骤⑤：验证优化效果，对比执行时间。一句话总结：开启慢查询日志定位问题 SQL，用 EXPLAIN 分析执行计划，针对性优化索引或改写 SQL，最后验证效果。
深度解析一、开启慢查询日志-- 1. 查看慢查询日志配置SHOW VARIABLES LIKE ...
Java 面试题›MySQL 面试题›truncate、delete、drop 的区别？
面试考察点
基础掌握度：面试官不仅仅是想知道三个命令的用法，更是想知道你是否理解它们在执行机制、事务支持、性能表现上的本质差异。
生产安全意识：考察你是否清楚哪些操作可回滚、哪些不可逆，能否在生产环境中做出安全的选择，避免 “删库跑路” 的悲剧。
原理深度：是否了解 DML 与 DDL 的区别、事务日志（undo log、redo log）的作用、自增 ID 重置机制等底层原理。
核心答案DELETE、TRUNCATE、DROP 是 MySQL 中三种删除数据的方式，核心区别如下：
对比维度
DELETE
TRUNCATE
DROP
SQL 类型
DML（数据操作语言）
DDL（数据定义语言）
DDL（数据定义语言）
删除内容
表中的数据行
表中的所有数据
表结构 + 数据 + 索引
WHERE 条件
✅ 支持
❌ 不支持
❌ 不支持
事务回滚
✅ 支持（需在事务中）
❌ 不支持
❌ 不支持
触发器
✅ 触发 AFTER/BEFORE
❌ 不触发
❌ 不触 ...
