三分钟后，群里炸了。 "这个分布式事务方案考虑过补偿机制吗？" "高并发场景下这个锁粒度是不是太大了？" "建议看下我们之前做的链路压测报告，第三方依赖的超时配置需要调整。" 我盯着屏幕，手指悬在键盘上，不知道该先回复哪一条。 导师在群里@了我："别慌，一个来。这些问题都很有价值，正好周五下午技术评审会，你来讲讲你的思路。" 周五下午，会议室里坐满了人。 我打开PPT，深吸一口气："这是我设计的分布式缓存一致性方案，主要解决高并发场景下的数据同步问题……" 话音刚落，架构师就提了第一个问题：&q...

28届2本非科班大概很快要找实习了，应该是偏ai应用开发方向

年后投到现在至今0约面，是哪里出了问题，是背景问题还是简历问题呢希望大佬指点一下

一、 索引为什么是 B+ 树？在计算机科学中，有很多数据结构可以实现快速查找，比如哈希表、平衡二叉树、B 树。为什么 MySQL 最终选择了 B+ 树？1. 对比哈希表 (Hash)优势： O(1) 的查询速度，快到极致。劣势： 只能处理“等值查询”（where id = 1）。一旦遇到范围查询（where id > 10），哈希表就彻底废了，因为它内部是无序的。2. 对比二叉搜索树 (BST / AVL / 红黑树)劣势：树太高了。物理意义上的痛点： 数据库数据存在磁盘上。每经过一个树节点，都要进行一次磁盘 IO。如果数据有百万级，二叉树的高度可能是 20 层，意味着查一个数据要 20...