寫在前面：

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