本文仅用于学习和交流目的，不得用于商业目的。非商业转载请注明作译者、出处，并保留本文的原始链接：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、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基础教程》的译者。
更多精彩，加入图灵访谈微信！
