五种分布式事务解决方案及适用场景。二 PC 方案依靠数据库实现分准备、提交 / 回滚两阶段事务协调者通知参与者开启事务并执行业务操作未提交时全局堵塞异常时统一回滚缺点是全局堵塞影响性能。三 PC 方案在二 PC 基础上增加询问阶段事务协调者先确认参与者可用性参与者仅回复状态不执行业务可避免参与者不可用时的资源浪费但仍存在事务全局堵塞问题。TCC 方案通过 Try、Confirm、Cancel 三个代码方法实现Try 阶段排除业务异常并准备资源Confirm 阶段完成最终提交Cancel 阶段异常时回滚阻塞力度小但与业务代码强耦合。Saga 方案将长事务拆分为多步本地事务正常时依次执行提交异常时反向回滚操作可减少长事务堵塞时间但无法保证事务隔离性高并发下可能出现超卖。消息最终一致性以 RocketMQ 为例生产者先发送半消息执行本地事务成功后通知 MQ 投递消息消费者接收后执行业务异常时生产者删除半消息或消费者重试重试失败需人工干预保证最终数据一致。MySQL 索引优化的核心逻辑与慢查询解决的三层防御体系以面试场景为例点明单列索引的陷阱。单列索引陷阱MySQL 单表查询多数仅能使用一个索引若为订单查询的用户名、手机号、下单时间字段分别建单列索引优化器会按字段基数选过滤性最优的索引其余字段需在索引结果中二次过滤若选错过滤性差的索引可能扫出十万行数据回表速度比全表扫描还慢。第一层防御理解索引选择底层逻辑优化器依据字段基数预估过滤性来选索引明确单查询仅用一个索引的规则。第二层防御用 explain 查看执行计划的 key、rows 等字段开启 optimizer_trace 追踪优化器选索引的成本计算开启慢查询日志捕获索引使用异常情况精准定位问题。第三层防御用区分度从高到低排序的联合索引替代单列索引若查询字段固定可建覆盖索引省去回表优化器选索引错误时可 forceindex 强制指定索引同时配合监控、业务限制如限定查近三个月订单优化查询。索引并非越多越好需结合 MySQL 优化器逻辑精准使用。MySQL 中回表与覆盖索引的底层逻辑及关联关系。两类索引定义InnoDB 引擎的主键索引聚簇索引叶子节点存整行数据类比户口本辅助索引普通索引叶子节点仅存主键值类比身份证号。回表流程解析用名字辅助索引查完整用户信息时先通过辅助索引获取主键值再持主键值到主键索引查询整行数据该二次查询过程即为回表会增加磁盘 I/O 损耗。覆盖索引说明覆盖索引是一种查询状态若查询所需信息已包含在辅助索引如名字 年龄联合索引中数据库无需回表直接从辅助索引获取数据可提升查询速度。后续内容预告面试官后续可能追问最左前缀原则、联合索引工作原理等高频面试题将在后续讲解。以上内容可帮助面试者清晰回应 MySQL 回表与覆盖索引相关问题。MVCC 仅适用于读已提交和可重复读两种隔离级别且两者的 readview 创建时机存在本质区别。隔离级别基础视频先讲解 4 种事务隔离级别读未提交、读已提交、可重复读、串行化通过账户余额案例解释脏读、不可重复读、幻读问题说明 MySQL 默认隔离级别为可重复读Oracle 为读已提交。MVCC 核心机制以读已提交为例拆解三大关键点隐藏列事务 ID、历史数据指针等、undolog 存储历史版本数据、readview 通过四个条件定位可读取的历史数据。MVCC 适用场景读未提交不使用 MVCC串行化依赖表锁读已提交每次查询创建 readview可重复读仅在事务首次查询创建一次 readview。Java 后端面试中 MySQL 快速加索引的答题方法及相关背景。面试背景说明Java 后端开发者吐槽面试被问非本职的 MySQL 加索引问题还需承担前端、运维、测试甚至客服等额外工作。早期加索引方式MySQL 早期用 copy 模式需建新表、拷数据、替换旧表全程锁表阻塞读写处理 1 亿条数据耗时极长。在线 DDL 模式MySQL 引入 inplace 模式的 online DDL直接在原表构建索引无需拷贝数据设置 LOCKNONE 可不阻塞 DML 操作通过 row log 记录增量变更索引构建完成后应用日志保证一致性仅最后阶段秒级锁表。特殊场景方案修改列类型等原生不支持的操作可使用 PT-OSC、gh-ost、OSC 三类工具或借助云数据库的无锁变更功能。答题套路总结面试时先讲 online DDL 原理再补充工具方案最后提及云数据库无锁变更可体现原理与工程实践能力。面试官详解用户点击下单到数据库落库全链路的高并发风险与应对方案。接入层防护险境为瞬间流量洪峰打垮后端对策是用令牌桶、漏桶算法限流网关每秒仅放行指定数量请求当下游服务报错超阈值时触发熔断器的关闭→开启→半开状态流转执行降级逻辑防止故障蔓延。业务层控并发险境为商品超卖、用户重复下单扣库存可在读多写少场景用乐观锁带 stock0 条件的 update 语句写冲突高场景用悲观锁select...for update高性能场景用 Redis 预扣减再异步同步数据库幂等性可通过订单表唯一索引或分布式锁加订单状态机实现。中间件削峰险境为数据库连接池被打满、CPU 占比 100%对策是引入消息队列业务服务发消息后立即返回消费者异步处理落库同时需开启生产者确认、MQ 持久化、消费者手动 ACK 防消息丢失消费者端做幂等性处理防重复消费临时扩容消费者或转积压消息防消息积压。存储层扩能险境为单表数据过亿导致读写缓慢对策是分库分表按 user_id 哈希分片用雪花算法生成全局唯一 ID其由 1 位符号位 41 位时间戳 10 位工作机器 ID12 位序列号组成遇时钟回拨可等待时钟追上、预留序列号缓冲或切换机器 ID。该面试题考察后端开发者对高并发、高可用、数据一致性的综合理解。