《SQL基礎教程（第2版）》做者MICK：上帝存在於細節之中（圖靈訪談）

本文僅用於學習和交流目的，不得用於商業目的。非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/art...

訪談嘉賓：MICK， 就任於日本的一家系統開發公司，是性能方面的工程師。專業領域是BI/DWH之類的大規模數據解析系統的設計和性能優化，若是發生性能問題，也會去應對OS資源或者Java的內存解析等各個方面。此外，最近也擔任培訓工做，培養公司內部的年輕工程師。

從學生時期開始，MICK就一直是合唱團（choir）的一員，不過最近的興趣主要是作孩子的玩伴。

---

【推薦語】

本書針對那些初次接觸SQL和關係型數據庫的讀者，幫助他們從SQL的基礎知識開始學習，包含從最初的SELECT／UPDATE／DELETE這些SQL的基本語法，到CASE表達式、表結合、關聯子查詢、窗口函數等重要功能的知識點。此外，因爲本書以標準SQL的語法做爲基礎進行學習，因此不論數據庫產品有什麼差異，均可以做爲一項便攜有用的技術常伴身邊。——MICK

---

訪談實錄：

日文版

我的話題

技術人士給人的印象通常會比較「宅」，生活中您是怎樣的一我的呢？

去年秋天，個人小孩兒出生了，因此如今的我的時間基本上都是陪孩子的。一塊兒去動物園啊（新聞報道了熊貓寶寶出生的消息），一塊兒玩玩具什麼的。雖然可以親眼看着孩子成長是件很是快樂和使人感動的事，但孩子身上總也用不完的能量和精力，對於陪伴他們成長的父母來講倒是很頭疼的事情（笑）。如今，基本上沒有什麼時間學習技術，也是挺苦惱的。

日本技術圈會經過哪些形式相互交流、學習呢？

日本這邊的學習會和研討會特別的頻繁和活躍。雖然時間基本上多數是在平日下班以後舉辦，但仍然有不少人在繁忙的工做中擠出時間來參加。這樣的學習會有時會分行業舉辦，有時也會以特定的技術領域（DB、Java、Ruby、機器學習等）爲主題舉辦。我本身也會參加DB的學習會，還曾經被委託作過演講。由於這不只僅對本身，並且對整個IT行業的發展很是重要，因此在接到委託的時候，我基本全都會接受。

日本是個講究效率的社會，生活節奏相對較快。您作到兼顧工做、生活、寫做的祕訣有哪些？

祕訣啊......好難啊（笑）。坦白說，20多歲的時候，是憑體力。那時候公司的工做很忙，晚上很晚才能回家，回家後經常也會繼續學習或者寫書。可是這樣確定不能持續太長時間，那只是年輕時的特權而已。說到竅門，就是活用間隙的時間。我是坐電車上下班的（到公司大概45分鐘），從智能手機普及以來，我就會在電車中把忽然浮現出的文章記錄下來，或者翻譯英語的技術報道，回一回郵件，整理瑣碎的任務，等等。這樣就能夠有大量的時間用於學習和寫書等真正重要的活動了。

寫書話題

什麼契機讓您開始編寫技術書的？

最初，我是在本身的我的網站上刊登技術相關的信息。

原本並無寫書的打算，只是想把備忘錄跟你們分享而已。後來，看過網站的出版社編輯給我發來了爲網絡雜誌編寫技術報道的邀請，我接受了那個邀請，慢慢開始成爲了一個撰稿人，繼而開始寫書。

《SQL基礎教程》出版以來，廣受讀者好評，您認爲這本書受到讀者喜好的緣由有哪些呢？

能在日本和中國兩個不一樣語言的國家都受到好評，我真的很是高興。我在寫這本書的時候比較注重的是「寫一本當本身仍是初學者時想要讀的書」。不只是SQL還有那些編程語言的入門書，基本上都不會對詳細的原理進行講解，「暫且記住這麼寫」這樣的內容也不少。這些就是所謂的「料理書」或者「食譜」書。對我來講，即使是入門書，我也不會採用這樣的寫法。由於若是最開始不理解其中的原理，終究沒法脫離初學者的階段。

要寫出如此淺顯易懂、細緻入微的入門書，須要對事物有細緻的觀察和深入的理解，請問您是如何作到的呢？

確實，我很是注意不能疏於「對事物細緻入微的觀察」這一點。換句話說，就是「不能無視細小的不協調」。 開始學習某個領域的時候，我經常會帶着「爲何會這樣呢」這種疑問，而且從不無視這樣的疑問，認真調查直到真正解決問題爲止。

例如，最開始學習SQL的時候，若是要檢索NULL，咱們不能用「<列名> = NULL」，必須寫成「<列名> IS NULL」，這樣的語法規則很是難以想象。爲何不能使用「=」呢？這樣的疑問，若是不深究，只是按照「就是這樣寫的」背下來，也是能夠的。可是，這樣作就沒法掌握實際的應用能力，很快就會遇到成長的瓶頸期。我認爲，可以達到理解本質的最好方法，就是不要無視見到的瑣碎疑問。「上帝存在於細節之中(God is in the details)」是個人座右銘之一。

將來有第三版的寫做計劃嗎？若是有，會在哪些方面對第二版進行補充或更新？

雖然如今尚未第3版的寫做計劃，不過若是做爲補充的話，我會考慮如下兩種方式。一種是加入SQL的應用技術。如今，SQL做爲大數據加工分析的工具，出現了不少比之前更高級的用法。經過活用窗口函數和CASE表達式，能夠建立出很是方便的程序。目前已經出版了的兩個版本都是停留在基本使用方法的講解上，因此正在考慮擴充一些順應時代的內容。另外一種是加入關於SQL/RDB在系統開發總體中位置的說明。例如，追加一些相似SQL注入原理和對策，針對實際系統開發中如何應用SQL/RDB的內容。

技術書翻譯

咱們知道，您曾經翻譯過Joe Celko的書，關於Joe Celko和他的著做，能夠說一下您的見解嗎？

Celko的 Joe Celko's SQL for Smarties 是我學習SQL時的教科書。能夠說，關於SQL的幾乎全部知識都是從他那裏學到的。這是一本很是龐大而且難懂的書，因此讀起來很是辛苦。實際上，我寫書的動機之一，就是「想把Celko的書講解得更加容易理解」。提及來，個人書其實就是對Celko書的註解。

做爲譯者，您是怎麼決定是否翻譯某本書的呢？

如今，我正在翻譯Celko的另外三本書。從20歲出頭開始讀他的書以來，就一直很是地尊敬他，因此一直想何時能有機會翻譯他的書。我本身甚至有向出版社提案的那種熱情。除了Celko之外，也有不少很是好的數據庫方面的英文書，也但願何時能翻譯這樣的書。

翻譯技術書，對譯者的現有知識有哪些影響？翻譯過程當中，譯者會加入一些本身的理解或建議嗎？

如上所述，Celko的書很是難懂，僅讀一次不管如何也沒法理解。因此，翻譯的時候，會加入不少可以讓讀者容易理解的註釋。另外，不贊同做者意見的時候，也會努力作到代表本身的觀點，爲讀者提供能夠本身思考的機會。

在中國，存在着大量針對以《論語》爲首的深奧古籍的註解書。像朱熹的《論語集註》和何晏的《論語集解》，在日本也有普遍的讀者。這樣的註釋文本不只僅是說明語言的意思，而且加入了不少獨立思考的內容，很是有創造性。我也但願像這樣，不作單純的語言變換，而是覺得原書帶來更多的附加價值爲目標進行翻譯。

關係型數據庫和非關係型數據庫

能夠簡單介紹一下關係型數據庫和非關係型數據庫（NoSQL）的特色及適合的應用場景嗎？

NoSQL剛出現的時候，就有一些關於它會不會取代關係型數據庫這樣的說法。可是通過了這麼多年，如今已經穩定在了「適才適所」的形式上。NoSQL的種類很是多，因此沒法一語概之，比較有表明性的是按照種類來區分。

(1)Key Value Store (KVS) Memcached、Redis、DynamoDB(※)等

(2)文本型DB MongoDB、DynamoDB等

※也具備文本型DB的功能。

我以爲(1)的優勢有兩個。一個是經過將數據構造進行Key-Value這種一對一的單純化處理，使高速查詢變成可能。放棄SQL查詢的自由度，取而代之的則是對速度的追求。使數據增長時的可擴展性更加豐富。經過KVS，特別是將數據內存化以後，可使性能得到提升。

(2)的優勢是，經過JSON和XML等形式，能夠將過去關係型數據庫中以「表」的形式存在、比較難處理的數據，變得很是自由。這樣，就能夠用來處理那些沒有進行正規化嚴密設計的各式各樣的數據了。

不過，無論是哪一種類型，都會犧牲掉關係型數據庫那種高度的事務處理功能和數據安全性。從「結果一致性」字面意思就能知道，它只能保證數據變動後最終保持在正確的狀態，容許有暫時的不一致。所以，(1)能夠應用於「須要高速應答，容許某種程度的數據不一致和消失」的數據處理。具體來講，就是像SNS投稿那樣的流數據或者EC網站中用戶的Session信息，等等。對於Session信息來講，即便是最糟糕的丟失情況，也能夠經過再次登陸來重置。但是那些已購商品記錄和付款數據的消失是絕對不能容許的。所以，相似這樣的狀況就須要使用KVS做爲前臺，關係型數據庫做爲後臺這種常規的設計。

此外，還有一些用來處理非結構數據的數據庫（雖然對其是否能夠稱爲NoSQL仍存在乎見分歧）。總之，就是相似於圖像和聲音等非文字數據，以及像圖形結構這種過去的關係型數據庫處理起來比較棘手的數據。這樣的數據庫，是專門用來處理那些關係型數據庫沒法處理（或者難以處理）的數據的，在特定用途領域，也有取代關係型數據庫而存在的可能性。

可是，儘管如此，由於關係型數據庫的穩定性和泛用性很是傑出，因此使用關係型數據庫構建核心系統，在更加輕便的前端等細分領域使用NoSQL，這樣的形式從此會一直持續下去。

非關係型數據庫（NoSQL）未來會成爲數據管理的將來趨勢嘛？

我認爲NoSQL有兩個發展方向。一是NoSQL從此還有獨自發展的可能性。另外就是它做爲關係型數據庫的一個功能被吸取的可能性。實際上，過去的XML數據庫，最初是做爲獨立的數據庫產品出現的，可現現在已經做爲大多數DBMS的一個功能被吸取了。即便如今，關係型數據庫也存在擴充處理JSON和地圖信息（Spatial DB）的功能，最終成爲一個包含NoSQL功能的「你們族」的可能性。無論怎樣，我想做爲工程師，學習如何處理非結構數據的技術從此都會愈來愈重要。

後輩寄語

您認爲，新手在學習SQL時有哪些平時須要培養的習慣？在效率和規範性等方面，可否給出一些建議？

我想應該是，最開始不要去熟記那些小聰明式的技巧和「祕訣」，而是可以用心去理解動做原理吧。SQL跟Java等其餘編程語言相比，由於其函數和功能的數量比較少，又接近英語這種天然語言，因此乍一看很簡單。但實際上，那些「簡單的功能」（關聯、CASE表達式、窗口函數、HAVING語句，等等）組合到一塊兒，就會變得極爲複雜。這一點上SQL可能跟積木很像。若是忽略了對每一個基礎積木塊的理解，那就絕對不可能作出很高的建築物。

若是之後想從事軟件開發工做，初學者在學習完《SQL基礎教程》之後，還須要在哪些方面努力？您可否給些專業的建議？

本書終歸是聚焦於幫助你們理解SQL語法這一目的。實際上，對於技術人員所必需的知識而言，這些SQL的知識是遠遠不夠的，因此但願你們可以將目光投向更廣闊的領域。例如，即便只是在數據庫領域，也存在相似ER建模，Oracle、MySQL等產品的設計技術，SQL性能優化等，都是須要花不少年來學習的技術領域。若是各位讀者是軟件開發人員的話，我想也必須學習Java、PHP、Python等開發語言吧。

你們的目標是什麼，這是由你們本身的職業意向和市場需求決定的，因此我不能一律而論地給出建議。但無論是哪一個領域，帶着興趣學習是很是重要的。所以，儘早找到本身可以保持學習動力的領域，可以持續保持興趣地進行工做，是很是重要的。

在軟件概要設計的初期，不一樣的項目須要選擇不一樣的數據庫。您可否簡單介紹一下該怎樣選擇合適的數據庫？

如今，在日本能夠選擇的關係型數據庫有Oracle、SQL Server、DB二、PostgreSQL、MySQL這5個表明。如何選擇，對技術工程師來講是很是重要的問題，是必須綜合考慮多種因素的難題。

但現實中，有時候咱們並無選擇權。一句話，就是經常會受到「錢」的制約。譬如在公司啓動，須要創建新服務的時候，爲了儘可能下降許可證的費用，除了PostgreSQL和MySQL這些基於OSS的數據庫之外別無選擇。而若是是爲金融機構和公共機構構建那種追求很是高的可用性和性能的系統時，則必須選擇Oracle這種具備高功能而且能做爲供應商提供細緻周到的支持服務的產品。又或者是EC網站之類的信息流量隨季節變更比較頻繁的場合，選擇Amazon RDS之類基於雲上的，做爲SaaS的數據庫，多是性價比最高的。

近年來，任何一種數據庫產品，在功能的充實性方面都難分伯仲，所以跟過去的選擇基準相比，上面給的預算制約、非功能性、支持的充實度等方面就變得更加劇要了。

關於提升SQL的性能，能夠跟咱們分享一下您的經驗和建議嗎？好比複雜SQL（多表嵌套查詢，關聯查詢）或存儲過程當中，通常在什麼地方容易引起性能問題？

SQL性能優化是個人專業之一。雖然SQL很是容易引起性能問題，但其實坦率地說，主要仍是由於數據庫處理的數據量太大引發的。Web服務器和AP服務器最多隻能處理可以保存在內存中的那個水平的數據量（GB級別）。可是，在數據庫服務器上處理TB級別的數據倒是理所固然的。近年來，隨着大數據的流行，數據量也逐漸增大。

這必然會使從存儲器中讀取數據時的速度成爲難以超越的瓶頸，也就形成了不少SQL的性能問題。特別是在進行大表關聯的時候，這樣的問題更加顯著。

若是要在本次採訪中講述解決辦法的話，篇幅可能不太夠。我計劃寫一本專門針對SQL性能改善的書。可是，若是要舉一個立刻能夠實踐的改善方法的例子的話，那就是在DB服務器上儘可能多的搭載物理內存，給數據庫分配更多的內存好讓數據庫可使用更多的內存。之前，內存的價格比較高，但最近正趨於低價格化，32GB或者64GB的內存，均可以毫無壓力地搭載在通常的DB服務器上。內存與通常的HDD相比速度要快不少，若是能在內存上保存數據的話，就能夠解決不少性能方面的問題。雖然這只是用金錢來代替頭腦的解決方案，不過由於這種投資效果顯著，因此仍是比較推薦的。（笑）

若是要舉一個設計上須要注意的例子，那就是儘可能減小SQL處理的數據量，把它做爲基本方針。那些幾乎不須要的舊數據能夠轉移到歷史數據表中。對於能在畫面上設定的數據查詢條件，儘可能讓用戶來設定，等等。

SQL性能優化是針對經過設計上的努力也沒法解決的問題的最後手段。不要從一開始就依賴SQL性能優化，不須要SQL性能優化的設計纔是很是重要的，這一點請你們牢記。

---

特約記者：

孫淼，從事對日軟件設計和研發工做十餘年，曾於2007年至2009年赴日學習工做，2015年至今再次長期赴日工做。精通應用Java、PHP進行Web框架的設計開發，而且有Oracle、Teradata、MySQL、NoSQL等多種數據庫的設計開發經驗。樂於品味生活細微的點滴，熱衷於品嚐和製做美食。是《SQL基礎教程》的譯者。

---

更多精彩，加入圖靈訪談微信！