寫在前面：
作為甲方，對於乙方派來的開發人員，我是會自己面一下。總體來說遇到的水平不一，於是經過這三年多的面(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這方面，是最適合對整個公司的系統架構有比較寬泛和略微深入的理解的，很多招聘要求里，都需要對某領域的業務有一定的了解，所以可以看出來這個的重要性，以及從乙方跳到甲方的重要資本。