Java 面试题›MySQL 面试题›InnoDB 中索引类型有哪些？
面试考察点
基础掌握度：面试官不仅仅是想知道索引类型的名称，更是想知道你是否理解不同索引的底层结构（聚簇 vs 非聚簇）、存储方式、查询效率差异。
性能优化意识：考察你是否清楚各类索引的适用场景，能否在实际表设计中根据业务特点选择合适的索引类型，避免索引失效或不必要的索引。
原理深度：是否理解 “回表”、”覆盖索引”、”最左前缀” 等核心概念，能否解释为什么某些查询快、某些查询慢。
核心答案InnoDB 的索引从结构上分为 两大类，从功能上分为多种类型：
按结构分类：
聚簇索引（Clustered Index）：主键索引，叶子存数据。
二级索引（Secondary Index）：非主键，叶子存主键值。
按功能分类（二级索引）：
普通索引（Index）： 最基本的索引 。
唯一索引（Unique） ：允许 NULL，值唯一 。
主键索引（Primary Key）：不允许 NULL，唯一非空。
联合索引（Composite）：多列组合索引 。
前缀索引（Prefix）：字符串前 n 个字符。
全文索引（Fu ...
Java 面试题›MySQL 面试题›count(1)、count(*) 与 count(列名) 的区别？
面试考察点
SQL 基础理解：面试官不仅仅是想知道 “有什么区别”，更是想考察你是否理解 COUNT() 函数的语义——统计的是 行数 还是 非 NULL 值的数量。
NULL 值处理：考察你是否清楚 count(列名) 会忽略 NULL 值，而 count(*) 和 count(1) 不会，这是很多面试者容易踩的坑。
性能优化意识：考察你是否了解不同写法在 MySQL 不同版本中的执行效率差异，以及 InnoDB 对 count(*) 的优化机制。
核心答案三种 COUNT 方式的语义对比：
写法
统计内容
NULL 值处理
执行效率
count(*)
统计 总行数
不忽略 NULL
⭐⭐⭐⭐⭐ 最优（MySQL 优化）
count(1)
统计 总行数
不忽略 NULL
⭐⭐⭐⭐ 等同于 count(*)
count(列名)
统计 该列非 NULL 的行数
忽略 NULL
⭐⭐⭐ 需要判断列值
一句话总结：count(*) 和 count(1) 效果 ...
Java 面试题›MySQL 面试题›唯一索引和主键索引的区别？
面试考察点
索引类型理解：面试官不仅仅是想知道 “有什么区别”，更是想考察你是否理解主键索引（聚簇索引）和唯一索引（二级索引）在存储结构上的根本差异。
NULL 值处理：考察你是否清楚主键不允许 NULL，而唯一索引可以（但只能有一个），这是很多面试者容易忽略的细节。
性能优化意识：理解聚簇索引和非聚簇索引的查询效率差异，能否在设计表结构时做出正确选择。
核心答案主键索引：一种特殊的唯一索引，每张表只能有一个，用于唯一标识每一行记录，InnoDB 中主键是 聚簇索引。 唯一索引：保证索引列的值唯一，一张表可以有多个唯一索引，InnoDB 中唯一索引是 二级索引（非聚簇索引）。 核心区别对比：
对比维度
主键索引（PRIMARY）
唯一索引（UNIQUE）
数量限制
每表 只能有 1 个
每表 可以有多个
NULL 值
不允许 NULL
允许 NULL（但最多 1 个）
存储结构
聚簇索引，叶子节点存完整数据
二级索引，叶子节点存主键值
索引回表
不需要回表
需要回表（查询非索引列时）
创建 ...
Java 面试题›MySQL 面试题›为什么不推荐使用外键？
面试考察点
性能意识：面试官不仅仅是想知道 “不推荐外键” 这个结论，更是想考察你是否理解外键带来的性能开销——每次写入都要检查约束、加锁、可能导致死锁。
架构设计思维：考察你是否具备分布式系统的设计视角，外键在分库分表、微服务架构下根本无法使用，需要在应用层维护数据一致性。
权衡取舍能力：外键能保证数据一致性但也有代价，考察你能否根据业务场景（强一致性 vs 高性能 vs 可扩展性）做出合理选择。
核心答案外键（Foreign Key）：用于建立表与表之间的关联关系，保证参照完整性。但互联网大厂普遍 不推荐在生产环境使用外键。 不推荐外键的核心原因：
问题维度
具体影响
严重程度
性能开销
每次插入/更新/删除都要检查外键约束
⭐⭐⭐⭐
锁竞争
外键检查会锁住父表记录，影响并发
⭐⭐⭐⭐⭐
死锁风险
跨表操作容易产生死锁
⭐⭐⭐⭐
扩展性
分库分表后外键失效
⭐⭐⭐⭐⭐
运维困难
批量数据迁移、删表受外键约束
⭐⭐⭐
一句话总结：外键通过数据库层面的约束保证一致性，但 ...
Java 面试题›MySQL 面试题›自增主键用完了怎么办？
面试考察点
数据类型理解：面试官不仅仅是想知道 “用完了怎么办”，更是想考察你是否清楚不同整数类型的取值范围，以及 INT 和 BIGINT 的区别。
系统设计思维：考察你是否具备前瞻性的系统设计能力，能否在表设计阶段就考虑到数据量增长的问题。
分布式 ID 方案：当单机自增主键不够用时，是否了解分布式 ID 生成方案（雪花算法、UUID 等），这是高并发系统的必备知识。
核心答案自增主键用完的后果：当自增 ID 达到数据类型的最大值后，再次插入数据会报错 Duplicate entry 'xxx' for key 'PRIMARY'，新的数据无法写入。 各整数类型的主键容量：
数据类型
字节数
最大值
容量级
TINYINT
1
127（有符号）/ 255（无符号）
百级
SMALLINT
2
32767 / 65535
万级
MEDIUMINT
3
8388607 / 16777215
百万级
INT
4
2147483647 &# ...
Java 面试题›MySQL 面试题›什么是回表查询？如何避免？
面试考察点
索引原理理解：面试官不仅仅是想知道 “回表” 这个概念，更是想考察你是否理解 InnoDB 的聚簇索引和二级索引的区别，以及 B+ 树的存储结构。
性能优化意识：回表会带来额外的 I/O 开销，考察你是否具备 “减少回表次数” 的优化思维，能否在实际开发中设计出高效的索引。
覆盖索引应用：考察你是否掌握 “覆盖索引” 这一核心优化手段，以及如何通过 EXPLAIN 命令判断是否发生了回表。
核心答案回表查询：当通过二级索引（非主键索引）查询数据时，如果 SELECT 的字段不完全包含在索引中，MySQL 需要先从二级索引树查到主键 ID，再回到聚簇索引树根据 ID 查找完整记录，这个过程叫 “回表”。 核心对比：
查询类型
索引类型
是否回表
性能
主键查询
聚簇索引
❌ 不需要
⭐⭐⭐⭐⭐ 最快
覆盖索引查询
二级索引（字段全覆盖）
❌ 不需要
⭐⭐⭐⭐ 快
普通二级索引查询
二级索引（字段未覆盖）
✅ 需要回表
⭐⭐⭐ 较慢
一句话总结：回表的本质是 “二级索引 → ...
Java 面试题›MySQL 面试题›InnoDB 加索引，这个时候会锁表吗？
面试考察点
DDL 机制理解：面试官不仅仅是想知道一个 “是” 或 “否” 的答案，更是想知道你是否理解 MySQL 的 DDL（数据定义语言）执行机制，以及 Online DDL 的原理。
版本差异意识：考察你是否清楚 MySQL 5.5、5.6、8.0 在 DDL 操作上的重大差异，能否根据版本给出准确回答。
生产实践能力：是否知道在线上加索引的正确姿势，如何避免影响业务，以及遇到紧急情况如何处理。
核心答案分情况回答：
MySQL 版本
加索引行为
是否锁表
MySQL 5.5 及以下
COPY 方式
✅ 锁表，全表禁止读写
MySQL 5.6+
Online DDL（默认）
❌ 不锁表，支持并发读写
MySQL 8.0+
Instant DDL（部分支持）
❌ 秒级完成，几乎无影响
一句话总结：MySQL 5.6 之后默认使用 Online DDL，加索引不会阻塞读写，但在准备和提交阶段会有短暂的元数据锁（MDL），生产环境建议使用 ALGORITHM=INPLACE, ...
Java 面试题›MySQL 面试题›MySQL 深度分页如何优化？
面试考察点
问题识别能力：面试官不仅仅是想知道优化方案，更是想看你能否识别出深度分页的性能瓶颈——为什么 LIMIT 1000000, 10 会慢？MySQL 到底在做什么？
原理理解深度：考察你是否理解 MySQL 的 LIMIT offset, size 执行机制——它需要扫描 offset + size 条记录再丢弃前面的，而不是”直接跳到第 offset 条”。
方案选型思维：深度分页有多种优化方案，考察你能否根据业务场景（是否允许用户跳页、是否有连续自增主键等）选择最合适的方案。
核心答案深度分页问题：当使用 LIMIT offset, size 且 offset 值很大时，MySQL 需要扫描 offset + size 条记录后丢弃前面的 offset 条，性能急剧下降。 优化方案对比：
方案
核心思路
适用场景
性能提升
子查询优化
先查主键 ID，再回表查数据
有自增主键索引
⭐⭐⭐⭐
INNER JOIN
同上，写法不同
有自增主键索引
⭐⭐⭐⭐
游标分页
记录上次最大 I ...
Java 面试题›MySQL 面试题›谈谈 InnoDB 中的表级锁、页级锁、行级锁？
面试考察点
锁粒度理解：面试官不仅仅是想知道你背过这三种锁的名字，更是想知道你是否理解不同锁粒度对并发性能和数据安全的影响，能否在设计上做出合理权衡。
InnoDB 特性掌握：考察你是否清楚 InnoDB 默认使用行级锁，以及什么情况下会 “意外” 升级为表级锁（这可是生产事故的高发区）。
锁兼容性机制：是否理解共享锁（S 锁）和排他锁（X 锁）的兼容矩阵，以及意向锁在多粒度锁定中的作用。
核心答案InnoDB 支持三种粒度的锁，从细到粗依次为：
锁类型
锁定范围
并发度
锁开销
适用场景
行级锁
单行记录
⭐⭐⭐ 最高
⭐⭐⭐ 最大
OLTP 高并发事务
页级锁
一个数据页（16KB）
⭐⭐ 中等
⭐⭐ 中等
BDB 存储引擎（InnoDB 不常用）
表级锁
整张表
⭐ 最低
⭐ 最小
全表更新、DDL 操作
一句话总结：InnoDB 默认使用行级锁实现高并发，但在无索引查询、全表扫描等场景会升级为表级锁，需特别注意避免 “锁表” 事故。
深度解析一、三种锁粒度对比
...
Java 面试题›MySQL 面试题›InnoDB 和 MyISAM 有什么区别？
面试考察点
基础掌握度：面试官不仅仅是想知道两个引擎的字面区别，更是想知道你是否理解 MySQL 存储引擎的底层机制，能否在实际项目中做出正确的技术选型。
架构设计能力：考察你是否清楚不同引擎在事务、锁、索引、崩溃恢复等方面的差异，能否根据业务特点（读多写少、高并发、强一致性等）选择合适的引擎。
生产实践经验：能否结合实际场景（如电商订单、日志分析、全文搜索等）给出合理的选择建议，而不是只会背概念。
核心答案InnoDB 和 MyISAM 是 MySQL 最经典的两种存储引擎，核心区别如下：
对比维度
InnoDB
MyISAM
事务支持
✅ 支持 ACID 事务
❌ 不支持事务
锁粒度
行级锁，支持 MVCC
表级锁
外键约束
✅ 支持
❌ 不支持
崩溃恢复
✅ 支持（redo log、undo log）
❌ 不支持，可能数据损坏
聚簇索引
✅ 聚簇索引（主键即数据）
❌ 非聚簇索引
全文索引
MySQL 5.6+ 支持
✅ 原生支持
存储文件
.frm + . ...
