后端开发工程师面试题及数据库优化方案含答案

2026年后端开发工程师面试题及数据库优化方案含答案一、编程题（共3题，每题20分）1.题目（20分）：实现一个函数，输入一个非负整数`n`，返回`n`的汉诺塔移动步骤。例如，输入`n=2`，输出应为`["movefromAtoC","movefromAtoB","movefromCtoB","movefromAtoC","movefromBtoA","movefromBtoC","movefromAtoC"]`。2.题目（20分）：给定一个字符串数组`words`，请返回其中最长的无重复字符的子串的长度。例如，输入`["abcabcbb"]`，输出`3`（对应子串`"abc"`）。3.题目（20分）：设计一个LRU（LeastRecentlyUsed）缓存系统，支持`get`和`put`操作。`get(key)`返回键对应的值，如果不存在返回-1；`put(key,value)`插入或更新键值对，如果缓存已满则删除最久未使用的项。假设缓存容量为`capacity`。二、系统设计题（共2题，每题30分）1.题目（30分）：设计一个高并发的短链接系统。要求：-支持将任意长度的URL转换为固定长度的短链接（如`/abc123`）。-支持通过短链接快速还原原始URL。-系统需具备高可用性、高扩展性，并考虑分布式部署方案。2.题目（30分）：设计一个微博点赞系统。要求：-支持用户对微博进行点赞/取消点赞操作。-实时显示微博的点赞数。-支持按时间倒序展示微博列表。-考虑数据库表设计、索引优化和缓存策略。三、数据库优化方案（共2题，每题35分）1.题目（35分）：某电商平台订单表`orders`（`order_id`INT,`user_id`INT,`product_id`INT,`order_time`DATETIME,`status`VARCHAR(10)）存在以下问题：-查询订单时`order_time`查询效率低。-大量更新`status`字段导致锁竞争严重。-分区表设计不合理。请提出优化方案，并说明原因。2.题目（35分）：某新闻聚合平台文章表`articles`（`article_id`INT,`title`VARCHAR(255),`content`TEXT,`publish_time`DATETIME,`category`VARCHAR(20)）查询慢，具体表现为：-`SELECTFROMarticlesWHEREcategory='tech'ORDERBYpublish_timeDESCLIMIT10`执行时间长。-`content`字段全文搜索效率低。请提出优化方案，并说明原因。答案及解析编程题答案及解析1.汉诺塔移动步骤（20分）答案：pythondefhanoi(n,source,target,auxiliary):ifn==1:return[f"movefrom{source}to{target}"]steps=[]steps+=hanoi(n-1,source,auxiliary,target)steps.append(f"movefrom{source}to{target}")steps+=hanoi(n-1,auxiliary,target,source)returnsteps示例：n=2print(hanoi(2,'A','C','B'))解析：递归解法：1.将前`n-1`个盘子从`source`移动到`auxiliary`。2.将第`n`个盘子从`source`移动到`target`。3.将前`n-1`个盘子从`auxiliary`移动到`target`。时间复杂度：`O(2^n)`，空间复杂度：`O(n)`。2.最长无重复字符子串（20分）答案：pythondeflength_of_longest_substring(s):char_map={}left=0max_len=0forrightinrange(len(s)):ifs[right]inchar_map:left=max(left,char_map[s[right]]+1)char_map[s[right]]=rightmax_len=max(max_len,right-left+1)returnmax_len示例：["abcabcbb"]print(length_of_longest_substring("abcabcbb"))解析：滑动窗口法：-使用`char_map`记录字符最后出现的位置。-维护`left`和`right`窗口边界，若`char`已存在且位置大于等于`left`，则移动`left`。时间复杂度：`O(n)`，空间复杂度：`O(min(m,n))`（`m`为字符集大小）。3.LRU缓存系统（20分）答案：pythonclassLRUCache:def__init__(self,capacity:int):self.capacity=capacityself.cache={}self.head=Node(0,0)self.tail=Node(0,0)self.head.next=self.tailself.tail.prev=self.headdef_remove_node(self,node):node.prev.next=node.nextnode.next.prev=node.prevdef_add_node(self,node):node.prev=self.headnode.next=self.head.nextself.head.next.prev=nodeself.head.next=nodedefget(self,key:int)->int:ifkeyinself.cache:node=self.cache[key]self._remove_node(node)self._add_node(node)returnnode.valuereturn-1defput(self,key:int,value:int)->None:ifkeyinself.cache:self._remove_node(self.cache[key])node=Node(key,value)self.cache[key]=nodeself._add_node(node)iflen(self.cache)>self.capacity:lru=self.tail.prevself._remove_node(lru)delself.cache[lru.key]classNode:def__init__(self,key,value):self.key=keyself.value=valueself.prev=Noneself.next=None示例cache=LRUCache(2)cache.put(1,1)cache.put(2,2)print(cache.get(1))#1cache.put(3,3)#去除键2print(cache.get(2))#-1解析：双向链表+哈希表：-双向链表维护访问顺序，头为最近使用，尾为最久未使用。-哈希表`cache`实现`O(1)`时间复杂度。-`get`操作将节点移动到头部，`put`操作若超出容量则删除尾节点。系统设计题答案及解析1.短链接系统设计（30分）答案：核心思想：-使用哈希函数将长URL映射为固定长度短链接。-分布式部署，使用Redis缓存热点数据。-微服务架构，支持水平扩展。技术方案：1.URL哈希生成：-使用`Base62`编码（`a-z`、`A-Z`、`0-9`），将长URL通过SHA-256哈希，再取前`6`位（如`abc123`）。-哈希碰撞处理：添加随机前缀或使用布隆过滤器。2.分布式存储：-主库负责写入，从库备份。使用Raft或Paxos保证一致性。-短链接ID映射到长URL，存储在Redis（热点数据）或分布式数据库（如TiKV）。3.服务架构：-API网关路由请求到短链接服务。-短链接服务处理请求，先查Redis，若未命中则查数据库。架构图（文字描述）：用户请求->API网关->短链接服务↘Redis(缓存热点数据)↗数据库(分布式，如TiKV)解析：-高可用性：分布式部署+主从复制。-扩展性：微服务+无状态设计，支持集群扩容。-性能优化：Redis缓存减少数据库压力，Base62编码减少短链接长度。2.微博点赞系统设计（30分）答案：核心思想：-使用Redis存储实时点赞数，数据库存储点赞关系。-分区表设计+索引优化提高查询效率。技术方案：1.数据库设计：sqlCREATETABLElikes(like_idBIGINTAUTO_INCREMENTPRIMARYKEY,user_idBIGINTNOTNULL,article_idBIGINTNOTNULL,create_timeDATETIMEDEFAULTCURRENT_TIMESTAMP,FOREIGNKEY(user_id)REFERENCESusers(user_id),FOREIGNKEY(article_id)REFERENCESarticles(article_id));2.索引优化：-`user_id`和`article_id`复合索引，加速点赞查询。-`create_timeDESC`索引，支持倒序查询。3.实时点赞数：-使用Redis`INCR`原子操作更新点赞数，`GET`读取。-定时同步Redis到数据库，避免数据丢失。4.缓存策略：-用户关注的微博列表缓存Redis，减少数据库压力。-使用分页查询+延迟加载优化列表性能。架构图（文字描述）：用户请求->微博服务↘Redis(实时点赞数)↗数据库(点赞关系)解析：-高并发：Redis保证实时点赞数高性能。-数据一致性：通过定时同步保证Redis与数据库一致性。-可扩展性：分区表设计+索引优化支持大数据量。数据库优化方案答案及解析1.电商平台订单表优化（35分）问题：1.`order_time`查询慢，未分区。2.`status`频繁更新，锁竞争严重。3.分区表设计不合理。优化方案：1.分区表设计：sqlCREATETABLEorders(order_idINTPRIMARYKEY,user_idINT,product_idINT,order_timeDATETIME,statusVARCHAR(10))PARTITIONBYRANGE(YEAR(order_time))(PARTITIONp2023VALUESLESSTHAN(2024),PARTITIONp2024VALUESLESSTHAN(2025),PARTITIONp2025VALUESLESSTHAN(2026));原因：-按年份分区减少查询数据量，提高效率。-支持快速查询特定年份订单。2.索引优化：sql--主键索引已存在CREATEINDEXidx_statusONorders(status);CREATEINDEXidx_user_timeONorders(user_id,order_time);原因：-`status`索引加速查询特定状态订单。-`user_id`+`order_time`复合索引支持按用户查询近期订单。3.锁优化：-使用乐观锁（版本号`version`字段）替代悲观锁。sqlUPDATEordersSETstatus='completed',version=version+1WHEREorder_id=xxxANDversion=xxx;原因：-减少锁竞争，提高并发写入性能。解析：-分区表：按时间分区提高大数据量查询效率。-索引优化：针对常用查询字段加索引。-锁优化：乐观锁减少锁等待。2.新闻聚合平台文章表优化（35分）问题：1.`category`查询慢，未分区。2.`content`全文搜索效率低。优化方案：1.分区表设计：sqlCREATETABLEarticles(article_idINTPRIMARYKEY,titleVARCHAR(255),contentTEXT,publish_timeDATETIME,categoryVARCHAR(20))PARTITIONBYLIST(category)(PARTITIONp_techVALUESIN('tech'),PARTITIONp_entVALUESIN('entertainment'),PARTITIONp_otherVALUESIN('other'));原因：-按分类分区加速特定分类查询。2.全文搜索优化：-使用MySQL`FULLTEXT`索引：sqlALTER