ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花MySQL 中当表存在多个索引时，并非所有索引都会被生效，而是由优化器（Optimizer）基于特定规则和成本评估，选择“最优”索引执行查询。这一机制的核心是 基于成本的优化器（Cost-Based Optimizer, CBO），即优化器通过计算不同索引的执行成本，选择成本最低的方案，而非单纯依赖索引类型或定义顺序。理解这一机制，能帮助开发者设计更合理的索引、写出更高效的SQL，避免因索引选择不当导致的查询性能瓶颈。一、多索引选择的核心逻辑MySQL 优化器的核心目标是最小...

（打个码避免被开盒）我被组内委婉劝退，然后需求对接正好对面有个暑期失利的产品，后面聊了一会儿，感觉同是天涯沦落人。然后今天他要私了（离职），在账号停用的前1min，我发了个祝福，然后就如图所示了。此情此景就像我常玩的gal一样凄美，让我触动（纯感概场景，对别人没有意思哈）

小米oc了，但是在犹豫去不去。如果接受的话，小米正职待遇太差了，而且也不是互联网大厂，不确定这段经历对于秋招的背书有多大。算上餐补实习薪资5100，感觉太低了，并且岗位是中台开发，会干一些杂活，而且没有专门的mentor，和纯后端有一定区别。但是如果不接受的话，害怕接下来找不到好的offer，暑期0offer。图一是我简历上的项目和所学知识，图二是JD。实习的岗位不垂直，对秋招帮助大吗，该不该去，去了之后能胜任任务吗？

1、为什么引入父子索引，为什么引入 BM25，比例是怎样的，具体流程是什么，有没有 rerank父子索引主要是为了解决 切块后召回准，但是上下文不完整 的问题。如果文档直接按 300～500 token 切成小块做向量检索，确实更容易召回到具体答案，但很容易丢掉原文结构，比如标题、段落关系、表格上下文、前后约束条件。所以会把文档拆成两层：父块：保留完整语义单元，通常是 800～1500 token子块：用于召回，通常是 200～400 token检索时先搜子块，命中后回源到对应父块，再把父块内容喂给大模型。这样既保证召回精度，也保证上下文完整性。引入 BM25 是因为向量检索对语义相似比较敏感...