我面试一位女程序员被吊打了！
职场
科技
2024-11-05 12:13
上海
昨天发布了一个短视频是关于 MySQL 性能优化，我觉得内容很干很不错，分享给各位，一共 6 问，层层递进，我相信你会很过瘾的。追求短平快可以看下面视频，因为短视频时间限制，下面分享的文字是 8问，你可以做深度思考。面试官：工作3年就应聘我们公司的后端P7技术专家，你哪来的自信，你确定么？ 面试官：讲真你3年经验是没面试机会的，但看简历上写你多次处理线上数据库事故， 这个面试题是夺命连环8连问，看你能扛住几问？问题是你负责的系统生产环境卡顿，初步排查是MySQL性能瓶颈，第一步怎么做？候选人：面试官，这个很简单呀，从慢查询日志开始，使用(slow query log)定位具体的慢 SQL ，还会分析执行计划。重点关注慢SQL啊、是否全表扫描、是否选择了不合适的索引等。面试官：小姑娘可以呀，第二问，假如发现一个查询的执行计划，应该走索引没走，咋办?候选人：这里的原因可能是查询条件使用了函数、隐式转换或者其他导致优化器选择错了。我会通过 EXPLAIN 计划中 key_len 、 rows 等字段来找原因，还会查看是不是表的错误统计信息导致出了问题。 面试官：可以可以，你及格了，第三问，假如在索引层面优化后依然存在性能问题，比如高并发下锁等待频繁，又咋办?2，可适当的修改隔离级别(如已提交读代替可重复读)还可以在 底层修改InnoDB的Buffer Pool的配置，适当增大innodb_buffer_pool_size 。3、同时分配多实例innodb_buffer_pool_instances，优化Buffer Pool中的⻚缓冲管 理，从而减少磁盘访问4、通过精确控制 innodb_io_capacity 和innodb_io_capacity_max ，可以将I/O线程的负载限制在合理范围面试官：不错有两把刷子，第4问，发现一个事务涉及多个表的多次复杂联表查询，执行缓慢且I/O负载较大，要怎么办?1、最经常用的办法是对于复杂的多表关联查询，可以将大查询拆分成小查询，并引入中间结果缓存，降低I/O和锁竞争。2、对于死锁问 题，可以通过SHOW ENGINE INNODB STATUS来分析死锁日志，优化事 务代码避免锁定顺序冲突。3、更进一步，可以将⻓事务拆分为多个小事务执行，减少锁持有时间 面试官：优秀优秀呀，第5问，如果面对数据量巨大、查询依然较慢的问题，怎么解决？ 候选人：首先看你数据库表是采用水平还是垂直分片。比如根据用户id来进行水平切分将数据分布到多数据库实例。或者对多个宽表进行列切分，将高频访问数据列和不高频数据列分开，降低对主表的I/O开销。甚至可以水平和垂直一起，但垂直拆分对业务代码的侵入较大。面试官：我们继续深挖，第六问，你会如何确保证分片事务的数据一 致性?候选人：主要有2种。一种在数据库层面的2pc或3pc 的分布式事务机制，另一种就是在业务层面基于TCC模型的事务补偿机制。 面试官:第7问，那么又发现大量查询导致CPU使用率飙升且上下波动明显，又怎么 办?(考察MySQL的查询优化器的使用 )候选人: MySQL查询优化器通过代价模型(Cost Model)选择执行路径， CPU使用率过高可能是优化器错误选择了执行计划。通过设置optimizer_switch 参数调整优化策略，避免不必要的回表。对于⻓查 询，可以使用优化器提示(如STRAIGHT_JOIN、USE INDEX)控制执 行路径。此外，可以适当调整 query_cache_size 和query_cache_type ，尽量避免频繁查询缓存失效，减少查询计划的重算负载 。面试官:最后一问，在生产环境中如何设计MySQL的高可用方案呢?候选人:在生产环境中，部署主从复制(Master-Slave)或双主复制 (Master-Master)模式，通过GTID实现复制的可靠性，并借助MHA、 Orchestrator实现自动化故障转移。为了保证数据的实时性与一致性， 可以使用半同步复制降低数据丢失⻛险。容灾方面，可以结合阿里云、 AWS等云服务实现异地多活，借助云端的存储快照备份与容灾，确保数 据的持久性和可恢复性。讲真，这个女程序员数据库知识很扎实，我问不倒呀，各位你们留言一个问题问倒她。最后，上周六连麦直播了一次，效果非常好，用户平均直播间停留时间25分钟，一群人排队来连麦，给大家解决问题的感觉太好了，这周六继续！所以，你若有工作上/者找工作困难的/职业上的困惑/转型的，或想搞个副业无从下手，或快 35 岁了还在一线当大头兵不知道如何破局？等问题都可以来。欢迎本周六晚上 21 点来直播间「语音连麦」，当然欢迎你带着你的其他个性问题来直播间提问，我知无不言，我们不见不散哈～以往热文推荐：
真实案例：两位程序员压力大到睡不着，莫慌军哥来解惑！
![]()
