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

訪談嘉賓：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、DB2、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基礎教程》的譯者。

---

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