前言别笑，这真的是高频翻车题。在数仓面试考察建模理论这一块时，数据域和主题域的区别几乎成了必问问题。但奇怪的是，即便是在企业里干了三五年的同学，一聊到这两个概念，也常常含糊其辞。先看定义数据域：是从业务过程出发，对数据进行的分类管理，解决「数据如何管」的问题。主题域：是从分析视角出发，对数据进行的逻辑划分，解决「数据如何用」的问题。大家看完定义之后，可能还是无法对应到真实数仓建设中来，我们直接上企业真实案例！假设用户完成一次完整购物：登录 -> 浏览商品 -> 加购物车 -> 下单 -> 支付 -> 卖家发货 -> 买家收货 -> 评价/退款在整个购物...

谁懂啊！我实习遇到的公司，真的太把实习生当正式员工使唤了，刚入职没几天，连项目代码结构都没摸透，就被安排写项目了！一开始都是些接口对接、数据格式转换的基础活，听起来不难，但架不住我对项目的业务逻辑、代码规范一窍不通。对着前辈丢过来的需求文档，我一边查代码注释，一边翻技术文档，磕磕绊绊写完功能，也只知道 “这么写能跑通”，根本不明白 “为什么要这么设计”，妥妥的知其然不知其所以然。本以为这种基础活会干很久，结果没过多久，领导直接甩给我一个小功能的开发方案，让我负责从方案落地到功能对接、测试上线的全流程。当时我直接懵了，硬着头皮啃需求、画流程图、写核心代码，遇到不懂的就逮着前辈狂问，加班加点成了家常便饭。更没想到的是，后面居然让我独立负责一个模块的开发，还要做性能优化。从数据库索引调整，到接口响应速度提升，每一步都得自己琢磨、自己验证。那段时间真的累到飞起，每天下班脑子都是懵的尤其是发版的时候，我比谁都紧张，盯着监控屏大气不敢喘，生怕自己写的代码出 bug 导致系统崩溃。一旦出问题，就得立刻配合运维回滚版本，然后自己留下来加班排查修复，常常整栋办公楼只剩我一个人的工位亮着灯。每天加班到深夜，工作量比正式员工还饱和，我不止一次对着电脑发呆：我到底是来实习的，还是来打工的？虽然这段经历确实让我的技术能力突飞猛进，但那种被推着往前走的疲惫感，直到现在想起来都觉得累。

面试题简述MySQL如果数据库做了分库分表，那跨库查询一般怎么处理？面试官想听的1、分库分表带来的代价2、没有完美方案，只有取舍面试回答举例分库分表后，跨库查询本质上是一个复杂问题，一般不会完全交给数据库来做。 常见的解决思路有以下几种：详情请参考：http://xhslink.com/o/4WkaXwLo8R0由浅入深分析1、分库分表本身是为了解决容量和性能问题。2、跨库 JOIN 在设计上应尽量避免。3、查询能力往往通过架构手段补偿。面试加分点1、提到分库分表是有代价的。2、提到反范式设计。3、提到跨库 JOIN 违背了分库初衷，这一点非常加分。