高级Java开发SQL面试题：三高场景性能优化实战

不少测试人员于面试之际会发觉，SQL优化已然成了必考题目。为何公司对这般能力如此重视呢？是由于一条运行缓慢的SQL便可能致使整个线上服务陷入困境，在2025年双十一那段时期，有电商平台因索引失效致使订单出现超时长达30分钟的情况了。

执行计划是SQL调优的第一把钥匙

测试人员运用EXPLAIN关键字剖析SQL之际，最为需要予以关注的是type字段。该字段自最优状态至最差状态依次分别是system、const、eq_ref、ref、range、index、ALL。一旦type呈现为ALL之时，这表明数据库正处于全表扫描的状态，在即将到来的2026年初，某家专门从事物流业务的公司所开展的配送查询操作，恰恰是由于全表扫描这类情况，进而致使响应时间从原本的50毫秒骤然剧增到8秒。

不包括type，还要审阅key_len与rows。key_len展现索引运用的字节数量，rows为预估扫描的行的数量。在2025年12月，某在线教育平台的一条统计SQL扫描了总计200万行数据，借助调整联合索引的顺序，将扫描的行的数量降低到了5000行。EXPLAIN还能够看出using filesort以及using temporary，这两者皆为性能杀手，意即数据库在内存或者磁盘上进行额外的排序。

索引设计决定查询成败

聚簇索引跟数据行一起存放着，每张表仅有一个聚簇索引，在InnoDB引擎里边，倘若没有主键，会挑选第一个不含有NULL值的唯一索引当作聚簇索引。2025年的时候，某社交平台的用户表，因未对主键进行合理设计，致使二级索引查询得进行两次回表操作，在改造之后，查询速度提高了3倍。

辅助索引即是二级索引，叶子节点所存的是主键值，联合索引是遵循最左前缀原则的，像index(a,b,c)这样，当查询条件仅有b和c时索引是不会生效的，某支付公司于2025年7月排查时发现，一个依据时间范围进行查询的SQL执行了全表扫描，而其原因在于联合索引将时间字段放置在了最后，把位置调整以后扫描行数从80万下降到了2000行。

高可用架构下的SQL挑战

MySQL高可用的基础架构是主从复制，主库会写入binlog，从库会读取并回放，2025年有某游戏公司碰到主从延迟达到了15秒的情况，具体原因是主库进行大量删除操作从而生成了10GB的binlog，解决这个问题的办法是把大表删除分成多个小批次来处理，每一批次均为删除1000行且要sleep 1秒。

MGR集群具备相较于传统复制更为强大的一致性保障。在2026年1月，有一家金融公司采用了MGR，其故障切换时间从分钟级实现了缩短至5秒以内。测试人员需要对切换过程中有无数据丢失进行验证，能够借助GTID来对比主从节点的事务执行状况。在故障切换演练里，要着重关注应用连接池是否支持自动重连。

分布式场景的ID生成策略

分库分表之后，数据库自身的自增ID难以确保全局的唯一性。雪花算法是一种经常被采用的数据解决办法，它借助64位的整数去存储时间戳、机器ID以及序列号。早在2025年的时候，某订单系统运用了雪花算法，每天能够生成2亿个ID，并且没有出现重复的征象。然而，需要留意时钟回拨的问题，某公司正是由于NTP时间同步才致使生成了重复的订单号。

UUID在理论层面是全球唯一的，然而当其作为主键使用时，会致使索引碎片极为严重。测试所得到的数据表明，当以UUID作为主键时，插入性能相较于自增ID要慢40%。数据库的自增ID适宜用于单库场景，在分库之后能够通过设置不同的步长来予以解决，举例来说，倘若分4个库，那么就将步长设置为4。某一家物流公司于2025年采用了分段号段方案，每个服务实例预先获取1000个ID，不但能够保证唯一性，而且还能提升性能。

存储选型要匹配业务场景

对于强事务场景而言，MySQL是适合的，像订单支付、账户余额这类情况。而Redis呢，适合高性能缓存以及计数器，在2026年的时候，某秒杀系统采用Redis的decr命令来进行扣库存操作，单机的QPS能够达到10万。然而，Redis是不可以做复杂查询的，曾经有某公司把报表数据放置在Redis当中，最终导致内存占用从2GB急剧飙升到40GB。

ES擅长进行于全文检索以及日志分析，某电商平台运用ES来存储为期3年的订单日志，其搜索响应时间处于200毫秒以内。MongoDB适宜存储采用JSON格式的动态字段，某物联网平台借助MongoDB存储设备上报的数据，单个表每日增加的数据量为1TB。测试人员在进行选型之时需要明确关于数据一致性的要求、查询模式以及预估的数据量。

异步架构的容错机制

在 2025 年，某外卖平台于大促期间出现了 MQ 消息积压这一常见问题，其中 RabbitMQ 积压了 500 万条消息。经排查得知是下游消费能力欠缺导致的，其解决方案是将消费线程数从 5 个调整至 20 个，并且启用批量确认。同时，监控告警阈值设定为积压超过 10 万条时触发扩容。

存在缓存与数据库不一致的情况，这就需要有兜底方案。有一个支付系统，它借助定时任务，每隔5分钟就执行一次扫描操作，去比对Redis缓存以及数据库里的库存值，一旦发现存在差异，便以数据库中的数据作为标准来进行修复。要是订单创建遭遇失败，那就采用指数退避重试策略，第1次重试是在1秒之后，第2次是在2秒之后，第3次是在4秒之后，最多可重试5次。

你于工作期间碰到过哪些缘自 SQL 性能问题所引发的线上故障，欢迎在评论区域分享你的排查经验，点赞以使更多测试同学瞧见这篇文章。