写在前面：
作为甲方，对于乙方派来的开发人员，我是会自己面一下。总体来说遇到的水平不一，于是经过这三年多的面(cui)试(can)，总结了一套自己的面试套路，中间也遇到过很多想吐槽的东西，于是大概记录了下来。在后面， 也写了些关于这方面的职业发展和我个人的建议。
问题很基础，DBA路过误笑，同行高手欢迎过来喷一喷，一起进步。
先说下面试的顺序，首先我们现有的开发人员问基本的SQL语句问题和SSIS组件问题，然后我继续问以下问题。
问题1：假如有一个job突然失败了，那么你第一时间应该先去看哪里。
我的答案：
首先去看job history，看具体的错误信息，根据这个信息决定如何去解决问题。
如果在ETL中有自定义的日志输出，那么再去看自定义日志的内容。
吐槽：
居然很大一部分人不看job history，而是看自定义的日至。还有看哪里都不知道的，开发ETL不管后期的维护和错误排查，就算再简单的ETL，也不可能一直不出问题，好比写个代码不知道如何排错一样，所以到底做没做过ETL开发 ，这个问题直接能看出来。
另，往往大型项目会有自定义日至输出，但是能说出这一点的先别给高分，因为很有可能只是知道而已，具体了解多少还要参考下面几个问题。
问题2：假如一个job本来应该在凌晨两点跑完的，但是早上上班的时候发现还没有跑完，接下来会怎么做。
我的答案：
这么久的延迟最有可能是阻塞，比如下游报表或者客户端仍在数据仓库里查数。
排除这个问题，先用系统自带的报表查看目前是否有阻塞，或者用sp_who3网上大家扩展的一个方法来进行查询。如果发现ETL进程被阻塞，kill掉阻塞的进程，确保ETL能正常进行下去。
避免类似阻塞的情况发生，可以在ETL进行之前终止报表服务或查询账号，ETL成功之后再启动他们。
吐槽：
很多人都归结到数据量的巨增导致，这对一个正常的业务来说可能性比较低一些，但如果能说出这个原因也会多少加一点分。能知道用sp_who3来看目前有哪些语句在转的会加很大一部分分数，这个意识很关键。
问题3：接到用户抱怨说一个报表运行的很慢，如何处理。
我的答案：
先跑一下这个报表，重现一下运行缓慢的现象。然后在sql server端sp_who3一下看看到底是卡在了哪条查询，把查询单独拿出来进行进一步分析和优化。
点评：
偶尔问题也会问成ETL运行很慢，像上一个问题一样，主要还是考察是否有查看当前哪些语句在跑的意识。
吐槽：
会有人回答说把报表源代码拿过来一行一行去分析，这样虽然有可能找到问题，但是很慢。所以我会对做这个超过三年经验的人产生质疑。
问题4：如何进一步优化
我的答案：
看执行计划，查看几个关键点，比如索引缺失，SQL语句需要优化等问题。
点评：
能第一时间想到索引问题的加分，能想到SQL语句写法不地道的也加分。
这个需要追问，进一步考察执行计划，详见下一个问题。
吐槽：
有不少说一行一行去看的，所以会继续追问执行计划的问题。
问题5：如何快速的知道是由于索引缺失导致的
我的答案：
看执行计划，通常执行计划会直接提示具体缺失哪个索引，并且提供相应语句创建索引。
另外这个时候在执行计划里，看是否有表扫描，如果有说明索引缺失，如果看到索引查找说明是命中索引的。
如果系统无法给出的，可以先看执行计划里哪部分消耗的资源（百分比）最高，然后看里面所消耗的io数值是否很高，如果是的话说明索引也是有缺失，需要根据具体的情况添加索引。
点评：
如果提到WHERE顺序的加分。
没提执行计划，但是提到看join条件，再看有没有索引的，我只能少加点分，毕竟这样查问题效率不高。
吐槽：
居然很少人提到系统自动的索引缺失提示。。。
半数人说看执行计划里每个步骤的时间 。。。
也有半数人知道看执行计划，但是说不出表扫描和索引扫描。
能看io消耗的真的很少很少。
问题6：索引的进一步问题。
比如：
聚集索引和非聚集索引的区别。（看对叶级结点的区别）
为什么聚集索引只能有一个。
一个表是否有聚集索引，对这个表的数据存储方式区别是什么。（这个回答不上来通常不减分）
吐槽：
具体答案就不写了，主要看回答是否能回答到点上，比如叶级结点的区别，数据排序，堆表等。
面试的所有人当中，能把部分问题说明白的很少，部分人也只是背书。
写在后面：
这些问题，估计做DBA的或者BI的同行应该是在边看边笑吧，但我吐槽的大家也看到了，能答到点子上的，在北京，很少，也许你说我们的vendor不给力，我可没这么说。
另外汇总了下我个人认为的，ETL开发对于不同工作年限的最低要求。
工作一年的要求：
熟悉各种SQL语句的写法，熟悉SSIS包里常用的模块。
三年：
知道索引，知道优化SQL语句，熟悉建模。能够处理日常ETL以及数据库级别的常见问题。
五年：
知道如何规划整个ETL，对设计数据仓库非常熟悉。
七年：
可以带领团队实施大规模的项目。
最后的最后：
说实在的，这行能一直干下来的很少很少，大多都是半路转过来，或者干不下去转别的了。
另外纯ETL开发从技能角度来说，如果只偏向这个方向确实以后的路越走越窄，同时配合些辅助的技能会路子宽很多，比如报表开发，DBA，架构，大数据等。
还有，甭管做什么，对业务的理解也很重要，而做BI这方面，是最适合对整个公司的系统架构有比较宽泛和略微深入的理解的，很多招聘要求里，都需要对某领域的业务有一定的了解，所以可以看出来这个的重要性，以及从乙方跳到甲方的重要资本。