在毕业后因为对于软件开发的兴趣，他成为一名 Web 全栈工程师，参与移动互联网产品的开发。现在他就职于一家跨国银行。在节目中，他聊到职场新人如何成长、技术专家的思维方式以及银行业 IT 技术转型升级等等话题。

相信他保持开放心态、持续学习、终身学习的态度也会给你启发和动力，期待你关注我们的播客，并把节目分享给更多朋友。也欢迎你发邮件分享自己的故事，也许我们会邀请你作为 freeCodeCamp 播客的嘉宾。你可以在这篇文章中找到邮箱地址。

freeCodeCamp 最近上线了很多关于编程和英语的新课程，接下来 Miya 会专注于英语课程的编写，同时将新课程翻译为中文，中文播客会暂停一段时间，谢谢大家支持，期待第二季再见。也期待你把节目分享给朋友们，我们一起带给更多人启发和动力。

如果你感兴趣和我一起翻译新课程，请查看贡献指南。

欢迎在 https://chinese.freecodecamp.org/ 查看更多免费的编程学习资源。

主要话题

• 04:17 对于编程从兴趣到职业
• 15:15 移动互联网行业 Web 开发
• 21:20 职场新人如何提升实践能力
• 31:58 银行业 IT 技术转型
• 39:23 微服务
• 47:10 跨国银行中的技术更新
• 1:01:10 安全与合规
• 1:07:12 数据库
• 1:16:31成为技术专家
• 1:28:41 外企的企业文化
• 1:35:02 养垂耳兔和练咏春拳
• 1:39:43 什么时候提问
• 1:44:42 保持开放心态和虚心学习

提到的资源

• 《MVC 架构详解》
• 微服务
• MySQL
• PostgreSQL：PostgreSQL 系列 4 篇文章
• UniApp
• JEECG

创建用户，专门用来实现数据复制

create user replica with replication login password 'replication';

检查postgresql.conf配置文件

wal_level = replica

检查pg_hba.conf权限配置文件

建议在最后追加一行host replication replica all md5，其中all也可以替换为从库所处机器的ip地址，比如192.168.0.10/32

生成备份库

 pg_basebackup -h 192.168.0.21 -p 54321 -U replica -R -P -v -C --slot=pgstandby1 -D /Users/liurui/pg2

• -R 说明会创建standby.signal文件，以及补充postgresql.auto.conf的内容
• -P 显示备份进度
• -v 显示更加详细信息
• -C 同时创建复制槽
• --slot 指定复制槽的名字（一个备库一个名字）
• -D 生成备库的路径

复制槽的好处
主库的事务日志一直处于滚动消耗的状态，如果备库下线，随着主库频繁的数据变动，可能就会存在当备库重新上线后，已经找不到之前没有拉取的事务日志的情况（被主库回收掉了）。
但是有了复制槽，主库就会为复制槽保留它没有消费的日志，等待它上线后进行消费。当然代价是对磁盘的消耗，不过只要备库不是永久丢失，磁盘消耗对于大部分场景来说不是问题。
但是如果备库永久丢失了，要记得删除主库中对应的复制槽。删除复制槽的语句为select pg_drop_replication_slot('pgstandby1');

注意
备库的操作系统环境最好与主库一致，如果一个是Windows一个是Linux，几乎一定会遇到字符集不一致的问题，导致备库无法启动。

启动备库

pg_ctl -D /Users/liurui/pg2 start

验证流复制可用性

• 在主库进行数据变动，在备库可进行观察
• 在主库执行select * from pg_replication_slots;能够观察到复制槽
• 在主库执行select * from pg_stat_replication;可以观察到备库连接情况，只有备库上线的情况下，该查询才会返回数据
• 顺便说一下，从库的数据目录会生成名为postgresql.auto.conf的文件（对应上面的-R参数），里面存放了主库的连接信息，感兴趣的小伙伴可以观察看看，但是这个文件不建议手动编辑。
• 注意，这样创建的备库其实叫异步备库，极端情况下，备库的数据跟主库比是有一定延迟的，如果需要无延迟的备库，就需要启动同步模式，当然它会牺牲更多的性能，也要付出更高的运维成本，本文并不涉及同步模式的介绍。

如何获得指定延迟时间的备库（可选）

大部分情况下，备库与主库保持一致是我们需要的。但是有时候，我们也需要的也一个比主库有延迟的备库，比如延迟三十分钟，也就意味着，当主库的数据被不小心删除后，三十分钟内，我们都可以在备库里找到。此时需要在备库配置：

recovery_min_apply_delay = 30min

手动把备库提升为主库

备库平时只能作为只读数据库使用，因为可写数据是主库才有的特权。但是一旦主库挂掉，并且已知备库的数据足够完整的情况下，我们可以迅速把备库提升为主库。只要找到备库的文件路径，把里面的standby.signal文件删除即可。顺便说一下，这个文件是没有内容的，它是一个空文件，通过这个文件的存在来表明自己是个备库，所以删掉或者重命名该文件，都能把这个备库提升为主库。当然，别忘了删除该文件后，重启备库才能生效。

补充：在docker环境下生成备库

1. 像平常在docker使用一样，启动一个数据库，当然要注意该备库的版本与主库保持一致。一个典型的yml文件如下：

   version: '3'
   services:
    postgres15-bak:
     image: postgres:15.1
     ports:
      - 34325:5432
     volumes:
      - /root/docker/volume/postgres15:/var/lib/postgresql/data
   

2. 使用docker-compose启动该镜像后，再通过docker exec进入它

3. 切换用户：su postgres

4. 进入postgres拥有权限的路径：cd /var/lib/postgresql/data

5. 生成备库：pg_basebackup -h 192.168.0.21 -p 54321 -U replica -R -P -v -C --slot=pgstandby1 -D ./bak 此时备库路径就在/var/lib/postgresql/data/bak下

6. 退出docker，回到宿主机，并关闭刚刚使用的docker镜像

7. 在宿主机把刚才镜像映射的文件夹调整一下，以上面的yml文件为例，就应该先把/root/docker/volume/postgres15/bak文件夹拷贝出来，再把/root/docker/volume/postgres15文件夹删除掉，之后把刚拷贝出来的bak文件夹还原为/root/docker/volume/postgres15，此时该镜像映射的文件夹就是我们新产生的从库备份了。

8. 启动上面的docker镜像。则从库已经接入主库。

今天我还会介绍一个属于PostgreSQL独有的特性，并且这个特性如同一把钥匙，可以给你打开一个崭新的数据库编程世界，至少我是这么认为的，那么我们赶紧开始吧。

SQL这种东西，本身是面向结果的，而不是面向过程的。这跟传统的编程语言有很大的区别，比如你在使用JavaScript、Java时，这些语言都是基于过程的，你要一步一步通过代码表达式把要做的逻辑过程编写出来，让计算机理解。而SQL是不具备这种能力的，虽然它看起来更高级，你只需要对着数据库说“要有光”(select light from universe)，“光”就来了。

但是不可否认，SQL语言的表达能力是有限的，有些复杂的逻辑我们无法依赖SQL直接实现。比如：计算当前时间是本年度的第几周，这显然已经超出了SQL的能力范围。所以数据库的创造者们，给数据库增加了SQL之外的能力，也就是Procedural Language（过程语言）简称PL。这种过程语言就给开发者提供了传统编程语言的逻辑方式，方便我们在数据里实现一种叫存储过程/函数的东西，进而拓展了数据库本身的逻辑能力。

几乎每个关系型数据库都有自己的PL实现，比如Oracle的PL/SQL、SQL Server的T-SQL，而在PostgreSQL中，提供的就是PL/pgSQL。

这当然也不是什么新鲜事。作为本系列的最后一篇，如果只是讲讲PL/pgSQL未免有些平淡了。

容我给你展示一组清单：

• PL/Java
• PL/PHP
• PL/Perl
• PL/Python
• PL/V8

结合前文所述，您大概已经猜到了。PL/xxx其实就是在说用基于某个语言实现数据库里的存储过程。换句话说，我们可以用自己熟知的高级语言，如：Java、PHP、Python来编写数据库的存储过程。当然了，这个功能是PostgreSQL独有的，别的数据库可享受不到。至于PL/V8，如果你熟悉前端开发的话，应该不难猜出这里说的是JavaScript的V8引擎。

下面我就用PL/Python来演示下，如何用Python3来开发PostgreSQL的存储过程。

首先需要在数据库服务器上安装Python3，然后再安装PostgreSQL的Python3扩展。以ubuntu为例，你需要执行：

apt-get install postgresql-plpython3-13

注意最后的数字13，应该与你本地的PostgreSQL版本相对应。一旦扩展安装关闭，就可以通过一条SQL语句，在数据库中开启对应的扩展功能，你需要执行。

create extension "plpython3u";

下面我们尝试创建一个存储过程（其实称为“函数”可能更准确，不过“存储过程”比“函数”更贴近数据库的专有词汇，为了方便大家理解，我采用了“存储过程”的说法）。

create function pymax(a integer, b integer)
  returns integer
language plpython3u
as $$
if a > b:
    return a
return b
$$;

这是一个简单的比较两个整型大小的存储过程，本身没什么技术含量。需要特别注意的是$$之间的代码段是通过language指定的，当我们指定了plpython3u后，就可以用Python3来编写函数了。

简单执行测试一下:

studypg=# select pymax(2, 3);
 pymax
-------
     3
(1 row)

可以看到函数顺利执行成功了。

聪明的你可能会说，能利用上Python的语言本身固然有点意思，但是实际价值却不大。要是能利用上Python的生态，那才是真的强。答案当然是Yes啦。

众所周知，最近几年Python在机器学习领域可谓是独领风骚。这得益于其多年在数学领域的积累，而numpy这个包，更是所有数学工作者的最爱。下面我就用numpy演示，如何在PostgreSQL中使用Python的强大生态。

首先安装numpy包，执行：

pip3 install numpy

然后我们创建一个存储过程，用来计算以e为底的自然数对数，语句如下：

create or replace function pylog(x float)
  returns float
language plpython3u
as $$
import numpy as np

return np.log(x)
$$;

看下执行结果：

studypg=# select pylog(1);
 pylog
-------
     0
(1 row)

studypg=# select pylog(0.1);
       pylog
-------------------
 -2.30258509299405
(1 row)

非常完美，借助Python生态的力量，我们仅用几句话就实现了原本SQL根本无法实现的功能。其实这还只是冰山一角。笔者甚至通过Python版的数据库函数作为数据库表的触发器，拦截到数据的变化，直接把变化信息转发到MQTT服务器，从而让其他外部应用，可以通过对MQTT消息的订阅，得到数据变化的推送信息。

好了，关于PostgreSQL中神奇的存储过程，就介绍到这里了。其实在PostgreSQL中还有很多神奇的事情值得挖掘，比如触发器，PostgreSQL不光可以拦截DML还可以拦截DDL；还有外部数据源FDW，PostgreSQL中可以引用多种外部数据，包括MySQL、Oracle等主流关系型数据库，甚至还支持Redis、MongoDB等非关系型数据库。总之，只有想不到，没有做不到。

关于PostgreSQL的系列文章至此就结束了。希望我的文章能激发出你对数据库的兴趣，愿这门悠久而强大的技术能够在你的工作中起到一些积极作用。最重要的，请一定要多实践。我们下个话题再见😃

推荐阅读本系列的其他文章：

• 2021年了，你真的应该考虑PostgreSQL了（1）
• 2021年了，你真的应该考虑PostgreSQL了（2）
• 2021年了，你真的应该考虑PostgreSQL了（3）

想象我们在做一个企业业务管理系统，需要为客户提供各种业务的增删改查功能。比如进销存这样的系统，我们要管理采购、入库、销售、出库等一系列的业务，而这些业务通常会有一些通用的设计，比如制单人、制单时间等等。

采用传统数据库的时候，我们通常就会在所有的业务表都添加这些相同的字段，虽然繁琐点，也并非无法忍受。但是当你积攒了成百个这种业务时，如果再想增加个字段，比如增加个修改人、修改时间什么的，那场面就不太美妙了。

还有另外一个场景，企业的业务，几乎每个单据（业务），都会有一个叫编号的东西，比如：订单编号、物流单号、支付流水号。这时，如果你的产品经理跟你提个需求，想做一个万能搜索，用户可以在文本框里随便输入一个编号，就能对系统中所有的业务单据编号进行模糊匹配，你打算怎么设计呢？

来看看在拥有表继承特性的PostgreSQL你该怎么做吧。

1. 创建业务基础表（父表），仅需包含几个关键字段即可：

   create table basic_business
   (
   	id varchar default gen_random_uuid()
   		constraint basic_business_pk
   			primary key,
   	v_code varchar,
   	t_create timestamp default now()
   );
   

   为了演示方便，这里我只准备三个字段，分别是：主键（uuid）、编码、创建时间。

   也许你注意到了varchar类型我们并没有指定长度，这又是一个PostgreSQL的精彩特性，varchar类型的长度是可选的，并且长度仅仅是一种约束，而不会对性能产生丝毫影响。所以大胆地采用无长度限制能够在不牺牲性能的情况下帮我们免去很多烦恼——我猜你肯定经历过录入数据超长引起的bug。

2. 创建业务表A：

   create table a_business
   (
   	a_column varchar
   ) inherits (basic_business);
   

   这里我们通过inherits关键字，声明了a_business对basic_business的继承关系。因为这种继承关系的存在，basic_business表中已经存在的字段，无需再次创建，我们仅需要在a_business中关注该业务独有的字段即可。

3. 需要注意一点，表继承关系，可以传递默认值、非空约束等，但是主键行为不会传递，所以针对创建成功的a_business表，我们还要给他补一个主键声明：

   alter table a_business
   	add constraint a_business_pk
   		primary key (id);
   

4. 同样的，我们也准备一个业务B的表b_business，方式跟A一样，就不再赘述了。最后我们获得了如下图展示的三张表：

   

5. 下面尝试在a_business、b_business两个表中分别插入一些数据：

   insert into a_business (v_code, a_column) values ('A0001','test_1');
   insert into a_business (v_code, a_column) values ('A0002','test_2');
   insert into a_business (v_code, a_column) values ('A0003','test_3');
   
   insert into b_business (v_code, b_column) values ('B0001','test_1');
   insert into b_business (v_code, b_column) values ('B0002','test_2');
   insert into b_business (v_code, b_column) values ('B0003','test_3');
   

6. 我猜你已经迫不及待想去select一下basic_business了吧，那咱们赶紧来查看一下：

   select * from basic_business;
   

   你将会得到如下结果：

   

   可以看到我们插入在a_business及b_business中的数据都被查询到了。并且由于basic_business的字段只有三个，所以结果返回的也是这三个字段。

   是不是有点意思呢？更精彩的还在后面。

   当我们尝试对basic_business追加一个字段，比如增加一个i_status用来标记单据状态，并且我还给这个字段指定了一个默认值0。

   alter table basic_business
   	add i_status int default 0;
   

   这个时候，当我们回过头来select任意一个业务表的时候，你会惊喜的发现，业务表也会相应的追加字段，并且连默认值都准备就绪了。

   select * from a_business;
   

   你会看到如下结果：

   

   甚至当你觉得basic_business字段需要调整一下，重命名或者是改个类型，也都没有关系，比如我们可以这样：

   alter table basic_business rename column v_code to t_code;
   alter table basic_business alter column t_code type text using t_code::text;
   

   这个时候，我们再查询下b_business看看效果

   select * from b_business;
   

   结果如下：

   

   怎么样？是不是所有的结果都与我们期望的一样。

   顺便说一下，我们刚才把一个varchar类型改成了text，其实这是一种几乎无意义的操作。在PostgreSQL中varchar就是text另一种叫法。他俩唯一的区别就是varchar可以声明长度限制，仅此而已。

   爱动脑筋的你，是不是会问这么一个问题，如果我们在子表，也就是a_business中修改一个父表带过来的字段会怎么样呢？咱们就来试试看：

   alter table a_business alter column t_code type varchar using t_code::varchar
   

   当我们打算把a_business表中的t_code类型从text改为varchar时，PostgreSQL给出了一个报错：

   ERROR: cannot alter inherited column "t_code"
   

   这我们就明白了，对子表来说，继承而来的字段是不允许修改的。其实这是完全符合直觉的，毕竟如果子表可以二次定义继承字段的话，假设父表也对该字段做了变更，系统就不知道以谁为准了。所以最佳实现方式，就是单向传递，以避免潜在的冲突。

7. 下面让我们来实现之前描述的第二个业务场景——通过对父表的t_code的模糊查询，同时对多个业务进行数据匹配：

   select * from basic_business where t_code like '%01%';
   

   结果如下：

   

   我们已经读到了分别位于a_business和b_business的两条数据。结果是不是很美妙呢？以后就是有再多的子表都不怕，只要都是继承basic_business的，我们都能查出来客户想要的数据。甚至不需要怎么修改代码。

   你可能会问了，单看上面两行数据，并没有办法明确标记出该行数据具体属于哪个表呢？不着急，PostgreSQL已经替我们想到了，如果想多查询一列，用以显示具体该行数据的事实归属，我们可以这样做：

   select *,TABLEOID::regclass from basic_business where t_code like '%01%';
   

   这样结果就多了一列，如图：

   

   讲到这里你应该明白了，数据事实上永远只有一份，并且只是存在于具体的子表中。之所以查询父表能够看到子表的数据，只是PostgreSQL帮我们做的一点小魔法，这说起来有点像一个union了好多表的视图。

8. 假设我查询父表的时候，不想带出子表的数据，该怎么做呢？其实也很简单，一个关键字的事：

   select * from only basic_business;
   

   这样你就只会获取到明确insert到basic_business表中的数据了。

总结

表继承功能算不上有很强技术储备的设计，但却异常实用。除了上面演示的抽象业务通用字段，其实还有好多地方可以用上这个特性，比如软删除、跟第三方对接数据（你控制父表，他控制子表）等等，小伙伴们还是开动脑筋自己多多尝试一下吧。
关于PostgreSQL表继承特性，今天就先介绍到这里。我想你应该体会到作为一款关系型数据库，PostgreSQL提供了不少颇具巧思的设计，以方便我们在实际业务场景中使用它。更多PostgreSQL实用特性，欢迎你继续关注我的专栏，咱们下期再见。

推荐阅读本系列的其他文章：

• 2021年了，你真的应该考虑PostgreSQL了（1）
• 2021年了，你真的应该考虑PostgreSQL了（2）
• 2021年了，你真的应该考虑PostgreSQL了（4·终章）

首先，我必须强调，SQL虽是一门古老的技术，但却并非停滞不前。看下历代SQL标准年表：

SQL-86 SQL-89 SQL-92 SQL:1999 SQL:2003 SQL:2006 SQL:2008 SQL:2011 SQL:2016

标准这种东西迭代太快也不行，不然就算程序员们的头发能受了，数据库厂家也受不了。所以目前SQL标准这种稳健的迭代是比较正确的做法。但是，即使是这样，数据库厂家们也没能跟上节奏，至今没有任何一家数据库产品声称完全符合SQL:2016的核心特性。

那么数据库里的优等生，我们的主角PostgreSQL表现得到底怎么样呢？

As of the version 13 release in September 2020, PostgreSQL conforms to at least 170 O of the 179 mandatory features for SQL:2016 Core conformance. As of this writing, no relational database meets full conformance with this standard.

也就是说目前SQL:2016标准中的核心标准中的179项特性，PostgreSQL至少实现了170项，虽说离“完全体”还有一点差距，但是考虑到至今也没有任何一个关系型数据能够完全吻合标准，PostgreSQL的表现还是相当不错的。如果你感兴趣的话，可以看看其他数据库的标准完成度，基本都还差得远呢，甚至有些数据库因为实在是跟不上标准，竟然对此有点讳莫如深了。

关于SQL的技艺展示，没有几本大部头的书是讲不完的。本文将从PostgreSQL入手，展示几个在实际项目中会用到的SQL特性。这些特性可能并非PostgreSQL独有，也并不是只有最新版本的PostgreSQL才支持。关于PostgreSQL独家特性展示，我将放在下一期的文章中。

想象这样一个表（表名:score），罗列了不同同学、不同课程的成绩单。现实场景中，人员信息、课程信息可能都需要单独的表进行存放，成绩单应该通过人员ID、课程ID字段对前两者进行关联。但是本文着重介绍PostgreSQL的特性，为了大家阅读方便，采用了这个非标准范式的设计方案。

需求1. 找出每门课程的第一名

目标结果：

传统做法：

select a.*
from score as a
         join (
    select v_course, max(i_score) as i_score
    from score
    group by v_course
) b on a.v_course = b.v_course and a.i_score = b.i_score;

PostgreSQL做法：

select distinct on (v_course) * from score order by v_course, i_score desc;

怎么样？本来需要子查询join一下才能解决的问题，PostgreSQL轻松一行搞定。

需求2. 查询每名同学的总平均分、文科平局分、理科平均分

目标结果：

传统做法：

select v_name,
       avg(i_score) as 总平均分,
       sum(case when v_type ='文' then i_score else 0 end)/sum(case when v_type ='文' then 1.0 else 0 end)  文科平均,
       sum(case when v_type ='理' then i_score else 0 end)/sum(case when v_type ='理' then 1.0 else 0 end)  理科平均
from score
group by v_name

说实话，这样写看着也还行，但是case when这种东西对索引实在是不够友好，在应对大数据量的时候会力不从心。

PostgreSQL做法:

select v_name,
       avg(i_score) as 总平均分,
       avg(i_score) filter ( where v_type = '文' ) as 文科平均,
       avg(i_score) filter ( where v_type = '理' ) as 理科平均
from score
group by v_name

可读性立马高很多，隐隐有种SQL艺术的感觉，执行效率也要比前者高。

需求3. 查询每名同学的成绩与该课程平均分的差异

目标结果：

传统做法：

select score.*, avg as 该课平均, round(i_score - avg, 2) 成绩差
from score
         left join (
    select round(avg(i_score), 2) as avg, v_course
    from score
    group by v_course
) as a on a.v_course = score.v_course
order by score.id;

进阶做法：

with cte as (
    select round(avg(i_score), 2) as avg, v_course
    from score
    group by v_course)

select score.*,avg as 该课平均, round(i_score - avg, 2) 成绩差
from score
         left join cte on cte.v_course = score.v_course
order by score.id;

PostgreSQL中究极做法：

select *,
       round(avg(i_score) over (PARTITION BY v_course), 2) as 该课平均,
       round(i_score - avg(i_score) over (PARTITION BY v_course), 2) as 成绩差
from score
order by score.id;

怎么样，如果你惊叹于SQL的强大，但是对此还不太了解的话，可以搜一下窗口函数。主流的商用数据库都是支持的，PostgreSQL作为一款开源免费的数据库，对于窗口函数的支持也是第一梯队的。

需求4. 算出成绩单的合计值以及每个人的总成绩

目标结果：

说实话，对于这种需求，不给我一个高级语言的话，真的是有点为难我了。好在我们有PostgreSQL，做起来并没有你想象中的难。

SELECT
    CASE WHEN GROUPING(v_name) = 1
             THEN '合计'
         ELSE v_name END,
    CASE WHEN  GROUPING(v_name) <> 1 and GROUPING(v_course) = 1
             THEN '总分'
         ELSE v_course END,
    sum(i_score)
FROM score
GROUP BY ROLLUP (v_name, v_course)
ORDER BY GROUPING(v_name) DESC ,v_name DESC, GROUPING(v_course) DESC ,v_course DESC;

很神奇是不是？寥寥数语就解决了需要高级语言编写逻辑代码才能搞定的问题。

总结

SQL是一门古老而强大的技艺，我一直觉得SQL的优雅是一种介于技术与艺术之间的美。在本文中，我以PostgreSQL为例展示了一些实用的SQL用法，本质上说，这些用法都是存在于SQL标准中的，而并非PostgreSQL独有，但不可否认，PostgreSQL作为一款开源免费的产品，能提供如此优秀的标准支持，是社区为全世界开发者提供的宝贵财富。

很多开发人员，他们的日常工作常常陷在无边的业务堆叠之中，每日都是在做增删改查。我听到过不止一次，大家对增删改查的厌倦、厌恶，甚至是彻头彻尾的鄙视。但是请不要忘记两点：

1. SQL是绝大多数软件系统运转的基石，在这个世界上任何被称作基石的东西，都不可以被轻视，谁轻视它，谁就要栽跟头。
2. “世事洞明皆学问”，增删改查一样可以彰显技术实力。同样是搬砖，优秀的人，总有优秀的解决方案。

相信今天你已经初步体会到了PostgreSQL与SQL之美，在下一期中，我会展示真正属于PostgreSQL的独门绝技，带你领略更绚丽的风景，我们下期再见。

推荐阅读本系列的其他文章：

• 2021年了，你真的应该考虑PostgreSQL了（1）
• 2021年了，你真的应该考虑PostgreSQL了（3）
• 2021年了，你真的应该考虑PostgreSQL了（4·终章）

本篇是这个系列的第一篇，着重讲讲PG的背景知识和国际、国内的应用地位。如果你的团队或者项目还没有使用过PG，希望这篇文章能消除你的顾虑，大胆在项目中尝试一下，PG一定不会让你失望。

The World's Most Advanced Open Source Relational Database

这是PG官网对自己的介绍，是的，你没有看错，“世界上最先进的开源关系型数据库”。一段严重违反我国广告法的话，上一个敢那么叫嚣的技术是PHP，“世界上最好的语言”，然后这句话就成了码农界最广为人知的梗，存在于各种笑料中。不过PG并没有因为这样明目张胆地自吹自擂而遭到什么抨击或调侃，事实上，无论在务实的码农界，抑或是讲究章法的学术界，人们对PG都是赞许有加，PG是完全当得起这句话的。

感兴趣的小伙伴现在也可以打开MySQL的官网，那里也有一句违反我国广告法的话。

在讨论PG的强大功能之前，我们先了解一下开源协议相关的背景知识。

Open≠Free，开源不等于免费，这是个老生常谈的问题了，无奈有些公司还没有意识到。这里转一张老图：

图中最令人闻风丧胆（非贬义）的协议就是GPL，一种传染协议，也就是要求你动了源码或者仅仅只是做了静态连接（Static Link）就必须也是用GPL协议开源出来。采用这个协议的典型代表就是Linux 内核，当年小米公司被国外开发大神硬怼，也就是受这个协议的影响，感兴趣的小伙伴可以搜搜小米 GPL 指责。关于开源协议的条条框框和经典案例足够出一本书了。这里大家知道一点就好，GPL是一种非商业友好协议，如果你要在商业项目上选择开源框架或者其他什么工具，一定要留意避开GPL以免带来不必要的麻烦。

为什么说这么多协议的事情呢？其实就是想提醒一下大家。目前业内使用量最多的开源数据库MySQL数据库，大家都是免费用的吧？而这个免费用的MySQL社区版，恰恰就是GPL协议的。这个在官网写得明明白白：

虽然说数据库这种东西，跟大家的软件项目是松耦合运行的。通常来说，我们编写的软件项目也不会被MySQL的GPL协议传染，但是随着数据库的使用深入，当MySQL的原始功能满足不了现有的场景，当你打算在MySQL的源码上动刀子的时候，情况就变得很微妙了。

还有一个问题这两年也日益凸显，就是说起我国因技术被卡脖子的事情，不管是政府还是民间，大家现在普遍对国外的技术，尤其是被美国技术寡头掌控的关键技术持有谨慎的态度。所以着眼未来的话，如果还选择由Oracle公司控制着的MySQL，我觉得是有一定风险的。

当我们回过头来看看PG，之前的顾虑都可以一扫而光。

首先PG的开源协议是一种类BSD的自有协议——PostgreSQL License，事实上早期的PG就是采用的BSD协议，后续换成自有协议并没有多少改变，依然属于最为友好的协议类型。不论是自用还是商用，都是完全没有问题，修改代码并且用来盈利也是毫无商业风险的。

其次，PG事实上不被任何一家公司所掌控，它背后的控制机构——PostgreSQL全球开发小组，是一个松散的组织。其核心成员来自全球各地的不同公司，如果你感兴趣，可以在PG官网查询到这个组织的成员列表。可以这么说，没有任何一个公司享有对PG的绝对控制权，PG永远是属于社区的。

那么是什么造就了今天的PG呢，咱们稍微回顾一下历史，感受一下开源的力量。PG源于UC Berkeley大学1977年的Ingress计划，这个项目由Michael Stonebraker领导。平平无奇的一句话，透露出三个信息：

1. 1977，相当有年头的事情了，估计此刻正在阅读本文的你，在那时还未呱呱坠地😃。
2. UC Berkeley，可以搜一下，世界最知名的7所大学之一，美国最好的公立大学。
3. Michael Stonebraker，2015年图灵奖获得者，绝对的大佬。

用咱们中国老话说，天时、地利、人和正好应对以上三条。可见PG一出生就不同凡响。

时间推移到1994年，UC Berkeley大学两个研究生Andrew Yu、Jolly Chen给PG增加了SQL语言解释器，建立了Postgres95，随后的1996年，正式重命名为PostgreSQL，从此开启了PG辉煌的二十余年。

仔细留意一下上面两个研究生的名字，是不是看着很亲切？我特意搜了下这俩哥们的照片，放出来给大家看看：

看了照片感觉更亲切，这俩兄弟是哪国人，不言自明了吧：）

往后的事，有意思也很多，但是限于篇幅，咱们不能一直扯。这里就讲一点，估计也是大家最为关心的一点，既然PG历史这么悠久，如果它真的如宣传所说，这么强的话，为什么现在大家都在用MySQL而不是PG呢？

说实话，这个问题，同样困扰了我很久，我也向一些前辈请教过，至今也没有权威的答案。这里就谈谈我自己的思路，两个原因：

1. PG支持Windows太晚了。有多晚呢？直到2005年，才原生支持Windows，2005年啊，比PG支持SQL晚了十年，比互联网在中国兴起、繁荣、泡沫戳破也晚了好几年。想想最重要的2000年前后，多少懵懂的站长都在使用Windows，PG错过了Windows就错过了最重要的一批在互联网上尝到甜头的人，从此一步错步步错（这个“错”不是“错误”的意思，而是“错过”的意思）。
2. LAMP的崛起，继续将PG边缘化。现在很少有人提LAMP这个缩写了，最早它是Linux/Apache/MySQL/PHP的意思。我第一次听到这个缩写是08年，那年我还在读大二。可以想象一下这个缩写有多火，连一个大二的学生都听过，而且那年我还无数次的给同学们安利这套技术，因为它看起来真的很时髦。而直到我参加工作的几年后，才第一次听说PG，等在项目中正式使用PG，已是2015年之后的事了。（一不小心，又是十年）

时也，命也，怎不令人唏嘘？

扯远了，让我们说回现在。

最近两年数据库国产化的呼声也很高。应该说咱们也取得了一些成果，比如华为的openGauss，腾讯的Tbase，老牌的达梦，风头正盛的TiDB，阿里的OceanBase，还有百度的BaikalDB等等等等，可谓是百花齐放。

这里咱单说前面那哥俩，华为的openGuauss，腾讯的Tbase都是跟PG颇有渊源的数据库。如果你查看它们的官网，或许不会看到Postgres的字样，但是如果你去GitHub看看它们的源码及说明，就会发现离不开PG的影子，用大白话说，它俩都是在PG上衍生出来的。当然这也不是什么秘密，不重复造轮子乃是业界共识，事实上无论是华为还是腾讯，都在PG上做了不少工作，也为我国PG社区的繁荣出过很多力。

我举这个例子主要是想说明一个问题，PG的开源协议非常友好，你甚至可以把它拿来改头换面，说成是自己的数据库，也没有什么法律风险。

当然大部分小伙伴也就是把PG拿来用在项目上，我想你们肯定关心，都有哪些公司已经在使用PG了呢？这里我也准备了一张老图，几年前的了：

怎么样？还可以吧？可以看出PG在各行各业都扮演了重要的角色，这还是几年前的图。有些大公司也没给列出来，像中国移动、平安科技、摩拜单车、探探科技、苏宁云商，也都在使用PG哦。

有了这么多大公司对PG的认可，PG在整个数据库领域的热度也是与日俱增。这里有一张最近几年循环洗脑的图，估计大家也在各种场合见过：

可以看出PG在一众数据库中披荆斩棘，绝对是众多关系型数据库中最靓的仔😉。

当然DB-Engines的排名也不能太当回事，我觉得远不如直接做问卷调查更有说服力，只要样本够大就能说明一些问题。还好Stack Overflow作为世界上最大的开发者问答社区，在今年二月做了一份问卷调查，共收集到65000份样本，整理了一份非常有价值的报告。如果你还没有看过，那我强烈建议你看一看。

现在我带大家简单看一下关于数据库方便的调查结果。首先是最受欢迎的数据库：

第一名是Redis，人见人爱的数据库，并不意外。紧随其后的就是咱们的PG了，并且与第一名的差距非常小，也就是说PG是最受欢迎的关系型数据，怎么样，这样的结果是不是有点猛呢？

还有一个统计数据也很能说明问题，就是受调查者正在使用的数据库的情况：

可以看到PG虽然落后MySQL一个身位，暂居第二，但是这已经比DB-Engines中的第四的排名提高了不少。可以这么理解，在活跃于社区的开发者中，采纳PG的比重还是比较高的，至少比Oracle高不少，即使跟Microsoft Sql Server比较也丝毫不逊色。

总结

本篇是关于PostgreSQL系列中的第一篇。本文中用了不少笔墨介绍了PG的过去和现在，我想你应该对这门存在了几十年的技术有点兴趣了吧。下一篇，我会用更加技术流的方式介绍下PG到底牛在哪里，有什么让人大呼过瘾的特色。

PG从不让人失望，我们下一篇再见。

推荐阅读本系列的其他文章：

• 2021年了，你真的应该考虑PostgreSQL了（2）
• 2021年了，你真的应该考虑PostgreSQL了（3）
• 2021年了，你真的应该考虑PostgreSQL了（4·终章）