MySQL面试聚焦存储引擎、数据类型、索引、事务锁、SQL优化、高可用六大块；InnoDB支持事务/行锁/聚簇索引，适合读写混合；MyISAM仅表锁/非聚簇，适用于只读场景但8.0已弃用。
MySQL 面试问题集中在存储引擎、数据类型、索引机制、事务与锁、SQL 优化、高可用架构这六大块，覆盖初级到高级岗位的核心考察点。不背概念，重在理解差异和实际影响。
InnoDB 和 MyISAM 的本质区别在哪？
不是“谁更好”，而是“谁更适合当前场景”：
- InnoDB 是事务型引擎：默认支持 ACID、行级锁、外键、崩溃恢复；数据和主键索引绑定（聚簇索引），适合读写混合、高并发、强一致性业务（如订单、支付）。
- MyISAM 是非事务型引擎：只支持表级锁、无外键、不支持崩溃安全恢复；索引与数据分离（非聚簇），查询快但写入时整表阻塞；适用于以读为主、极少更新的场景（如日志归档表、报表快照），但MySQL 8.0 已彻底移除 MyISAM 默认支持，官方明确不推荐新项目使用。
char、varchar、text 怎么选？
关键看长度是否固定、是否参与索引、是否需要全文检索：
- char(n)：长度严格固定（1–255），存短且等长字段，比如国家代码（CHAR(2)）、性别（CHAR(1)）。存 "a" 也占 n 字节，尾部空格在检索时被自动去除。
- varchar(n)：变长，最大 65535 字节（受行总长度限制），真实占用 = 字符数 + 1 或 2 字节（存长度）。定义 varchar(200) 和 varchar(5) 存 "abc" 占用空间完全一样，性能无差别——别盲目设 255，按业务上限合理定义，避免后续加索引失败（如 utf8mb4 下 varchar(255) 索引超 767 字节限制）。
- text / tinytext / mediumtext / longtext：用于超长文本，不支持直接建普通索引（需前缀索引），不能有默认值，排序和比较效率低；适合文章正文、用户评论等，不要用 text 存 JSON 或配置项——优先考虑 JSON 类型（MySQL 5.7+）或拆成结构化字段。
datetime 和 timestamp 用哪个？
核心看是否需要时区自动转换和时间范围要求：
- datetime：范围大（1000–9999 年），8 字节，存什么显示什么，不受数据库时区设置影响，适合记录“绝对时间点”，如创建时间、发货时间、合同签署时间。
- timestamp：范围小（1970–2038 年），4 字节，存入时转为 UTC，查询时按当前会话时区转回，适合记录“相对系统时间”的操作日志（如 last_login_at），且能节省空间。注意：2038 年问题已成现实风险，新系统慎用 timestamp 存长期时间。
为什么推荐 B+ 树做索引？
不是“B+ 树比 B 树好”，而是它更适配磁盘 IO 和常见查询模式：
- 所有数据都存在叶子节点，非叶子节点只存索引键，同样大小页能容纳更多键值 → 树更矮 → 减少磁盘 IO 次数。
- 叶子节点用双向链表连接 → 支持高效范围查询（如 WHERE id BETWEEN 100 AND 200）和 ORDER BY + LIMIT 场景。
- InnoDB 主键索引即聚簇索引：叶子节点直接存整行数据；二级索引叶子存的是主键值 → 查二级索引后要回表，所以主键别太长（推荐 BIGINT 自增，不用 UUID）。
事务隔离级别和常见并发问题怎么对应？
MySQL 默认是 REPEATABLE READ，但它通过 MVCC + Next-Key Lock 解决了幻读，不是靠“不允许多个事务同时读”：
- READ UNCOMMITTED：脏读（读到未提交数据）→ 基本不用。
- READ COMMITTED：解决脏读，但可能不可重复读（同一事务两次 SELECT，结果不同）→ 适合对一致性要求不高、读多写少的统计类应用。
- REPEATABLE READ：解决不可重复读，InnoDB 用间隙锁防止幻读（如 INSERT 被阻塞）→ 大多数 OLTP 场景首选。
- SERIALIZABLE：最高级别，全表/行加读锁 → 并发极低，仅用于极端一致性要求场景（如金融核对）。
慢查询到底怎么定位和优化？
别只盯着 EXPLAIN，要闭环排查：
- 先开慢日志：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1;，再查SHOW VARIABLES LIKE 'slow_query_log_file';找日志位置。 - 用
EXPLAIN FORMAT=TRADITIONAL看执行计划：重点关注type（最好到 range 或 ref）、key（是否走了索引）、rows（扫描行数）、Extra（是否有 Using filesort / Using temporary）。 - 优化方向分三层：SQL 写法（避免 SELECT *、函数操作字段、隐式类型转换）、索引设计（联合索引最左匹配、覆盖索引减少回表）、表结构（冷热数据分离、大字段拆出、分区表慎用）。
