数据开发面试里，SQL 优化很常见。低分回答往往是“不要用 select 星号、加分区、建索引”。这些建议有时有用，但太碎。面试官更想听的是：一个任务为什么慢，你怎么定位，改了什么，怎么确认结果没错。
数据开发的难点不只是速度，还包括口径准确、任务稳定和上下游依赖。只讲性能，不讲数据正确性，回答会显得不完整。
慢任务先看数据范围
很多慢 SQL 的根因不是语法，而是扫描了过多数据。面试里可以先讲分区裁剪：查询是否限制日期分区，条件是否写在能被识别的位置，是否因为函数包裹分区字段导致无法裁剪。比如把日期字段先做函数转换再过滤，可能让引擎无法直接跳过无关分区。
还要看字段选择和中间结果。明明只需要三个字段，却把整张宽表拉进中间层；明明只看最近七天，却扫了全量历史。这类问题在真实任务里很常见。
关联要警惕数据倾斜
大表关联大表时，面试官经常追问数据倾斜。数据倾斜可以理解为少数 key 的数据量特别大，导致某些计算任务处理压力远高于其他任务。比如大量空用户、默认门店、热门商品，都可能让一个分组或关联任务变得很慢。
回答时可以讲定位：看任务执行阶段是否少数任务特别慢，查看关联键分布，统计高频 key。处理方式包括过滤无效 key、把空值单独处理、对高频 key 拆分、广播小表、预聚合后再关联。不要只说“调参数”，参数只能缓解，不能替代数据分析。
SQL 优化不能改坏口径
数据开发面试里，一个很加分的点是主动提口径。优化 SQL 时，不能为了跑得快改变业务含义。比如去重口径、时间窗口、订单状态、退款处理、跨天归因，都可能影响结果。改写 SQL 后要做结果校验：总量对比、抽样对比、核心维度对比、异常波动检查。
如果你能说出一次“优化后发现指标变了，最后定位到去重口径不一致”的经历，会比单纯讲性能技巧更真实。
调度稳定性也是面试重点
数据任务不是跑通一次就结束。面试官可能问：上游晚到怎么办？任务失败怎么补？重复跑会不会覆盖错数据？节假日数据波动怎么处理？
回答可以从依赖、重跑和告警讲起。重要任务要明确上游依赖，失败后支持按分区重跑，产出表写入要避免半成品污染下游。告警不能只看任务失败，也要看数据量异常、关键指标突增突降、产出延迟。数据开发的稳定性，很多时候体现在这些细节上。
一段更完整的面试表达
可以这样说：我优化过一个日统计任务，最初运行时间很长。定位时先看扫描范围，发现分区过滤写法不规范，实际扫了更多历史数据；再看关联阶段，发现部分默认用户标识导致数据倾斜。优化时先规范日期分区过滤，只取需要字段；对无效标识单独过滤和统计；小维表改成广播关联；部分明细先按订单粒度预聚合再汇总。改完后不仅看运行时长，还对总订单数、分渠道金额、核心商户样本做对比，确认口径没有变化。最后补了任务延迟和数据量异常告警。
数据开发面试里的 SQL 优化，不是技巧背诵，而是一套从数据范围、执行过程、业务口径到调度稳定性的排查方法。
SQL 优化先保证口径
数据开发里的 SQL 优化，第一原则不是跑得快，而是结果不能变。面试时如果只讲加索引、加分区，容易忽略指标口径和数据完整性。
缩小扫描范围：可能收益是减少读取数据，可能风险是漏掉跨天或迟到数据，验证方式是对账总量和抽样明细。调整关联顺序：可能收益是减少中间数据，可能风险是数据倾斜仍然存在，验证方式是看执行计划和倾斜 key。
- 增加分区过滤：可能收益是提升任务速度，可能风险是分区字段口径不一致，验证方式是比较历史结果。
- 预聚合：可能收益是降低重复计算，可能风险是明细追溯变难，验证方式是保留可回溯链路。
真正成熟的表达是：我先确认慢在哪里，再改写 SQL，最后用总量、分组和抽样明细验证口径没变。速度和正确性要一起讲。