MySQL服务端分为连接层、服务层、引擎层、文件系统层四层，主链路为连接→解析→优化→执行→引擎→落盘，需厘清执行器与引擎职责边界。
理解 MySQL 整体分层结构是起点
面试官常从“MySQL 是怎么工作的”切入，不是考背诵，而是看你有没有系统观。MySQL 服务端典型分为四层：连接层（处理 TCP 连接、权限校验）、服务层（SQL 解析、优化器、执行器）、引擎层（InnoDB/MyISAM 等插件化存储引擎）、文件系统层（数据文件、日志文件落盘）。重点讲清楚连接→解析→优化→执行→引擎→落盘这条主链路，尤其要区分“执行器”和“引擎”的职责边界——执行器调用引擎接口读数据，但索引如何扫描、MVCC 如何实现、行锁怎么加，全由引擎决定。
围绕业务场景讲清选型与拆分逻辑
架构设计不是堆参数，而是对齐业务需求。常见考察点包括：
- 为什么默认选 InnoDB？ —— 要答出事务支持（ACID）、行级锁、MVCC 并发控制、外键约束、崩溃恢复能力（redo log + undo log），对比 MyISAM 说明其不适用高并发写场景；
- 什么时候考虑读写分离？ —— 不是“一主多从”就叫合理，得说清前提：读多写少、能接受主从延迟（比如秒级）、应用层可路由（或中间件支持）、写操作必须走主库；
- 分库分表是否必须？ —— 先说替代方案：单库优化（索引、SQL 改写、归档冷数据）、垂直拆分（按业务域切走用户、订单、商品库）；再讲水平拆分的触发条件（单表超 2000 万行 / 主键查询变慢 / 写入瓶颈明显），强调分片键选择决定成败（如用 user_id 分片，订单表就得冗余 user_id 或双写关联）。
高可用与容灾不能只提 MHA 或 MGR
说出工具名字只是门槛，关键讲清设计取舍：
- 主从复制原理要闭环：binlog 格式（ROW 更安全）、GTID 作用（简化故障切换、避免位点错乱）、半同步复制（rpl_semi_sync_master_enabled）解决丢数据风险；
- 故障切换必须定义 SLA：MHA 切换通常 10–30 秒，但需人工确认；MGR 自动选主快（秒级），但要求至少 3 节点、网络稳定、写冲突需应用兜底；
- 备份策略要落地：物理备份（xtrabackup 增量+全量）用于快速恢复；逻辑备份（mysqldump）适合小库或结构迁移；必须强调备份有效性验证（定期 restore 测试 + binlog 断点续备）。
性能瓶颈定位要体现排查路径
面试不是让你背命令，而是展示思维链条。遇到慢查询，按顺序问自己：
- 是偶发还是持续？查 show processlist 看是否有长事务或锁等待；
- 慢在 SQL 还是资源？用 slow_query_log + pt-query-digest 定位 Top SQL；
- 执行计划是否走索引？explain format=json 看 key、rows、filtered、extra（尤其注意 Using filesort / Using temporary）；
- 是不是锁导致？查 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS；
- 服务器层面是否打满？看 CPU、IO Wait、内存 swap、磁盘 iops（iostat -x 1）。
