数据库教程FGMT47‑PostgreSQL数据类型与数据库设计规范 

### 前言

风哥教程本文面向数据库DBA、运维工程师、数据库架构师、后端开发人员，完整讲解数据库对象设计、字符集与本地化、各类数据类型选型、生产环境表结构设计规范。数据库设计是业务系统根基，不合理的字段类型、错误的字符集排序规则、混乱的schema划分，会带来索引失效、排序异常、存储膨胀、查询性能低下、业务数据错乱等一系列难以修复的问题；很多故障在上线之后无法直接修改，只能重建数据库迁移数据，维护成本极高。

本套风哥教程使用两台标准化主机`fgedu‑net‑cn1`、`fgedu‑net‑cn2`，硬件规格统一**64G内存、8CPU**；数据根目录统一使用`/fgedudb`；实例名、业务数据库名、业务用户名固定为`fgedudb`、`fgedudb`、`fgedu`。风哥教程本文包含底层设计理论、完整可复现实战SQL命令、案例数据库初始化、常见陷阱规避、生产设计规范，帮助从业者建立标准化PostgreSQL数据库对象设计思维。

> 

> 风哥 itpux‑com

### 风哥教程本文内容大纲

1. SQL语言基础与案例环境初始化：psql登录连接操作；案例演示库部署；数据库对象层级关系理论。

2. 字符集与本地化理论：编码、LC_COLLATE、LC_CTYPE底层原理；数据库与集群locale的约束，生产选型原则。

3. 数据库对象管理实战：数据库创建、修改、删除；schema模式创建、授权、搜索路径配置；schema在微服务、多租户场景落地实操。

4. 数据表管理实战：建表语法，各类约束（主键、非空、唯一、chec客、外键）；表修改、重命名、删除；TOAST存储机制。> 

> 风哥教程 113257174

5. PostgreSQL全量数据类型详解理论：数值类型、字符类型、时间类型、JSON/JSONB、布尔、网络地址类型；每种类型存储原理、适用场景、常见踩坑点。

6. 数据类型实战演练：各类类型建表示例，增删改查操作，类型之间转换实操，JSONB索引实战。

7. 生产数据库设计规范：命名规范、字段选型规范、约束使用原则、索引设计、schema划分、字符集落地规范、反模式与避坑清单。

8. 案例库综合演练：基于业务场景完整建库、schema、表、权限全套DDL脚本；巡检脚本输出表结构风险点。

9. 风哥针对本文总结：设计关键点复盘，上线前检查清单。

本套风哥教程篇幅分配：前言大纲占全文5%；底层理论原理占全文30%；实战SQL、命令操作演练占全文60%；结尾总结占全文5%。

## 一、SQL语言基础与案例环境初始化理论

### 1.1 对象层级结构理论

PostgreSQL对象层级自上而下：数据库集群（实例cluster）→Database数据库→Schema模式→表、视图、索引、函数、序列。

- 一套实例可以创建多个Database；**psql客户端一次连接只能访问一个Database，跨Database不能直接访问普通表对象，需要fdw/dblin客扩展**。

- 每个Database内部可以划分若干schema；schema相当于命名空间，用来隔离业务模块，同一个库内可以跨schema直接访问表，不需要扩展组件。

- 默认新建数据库自带`public` schema，如果建表不指定schema，对象默认创建到public下面。生产业务不建议全部对象堆积在public。

> 

> 风哥数据库教程 itpux‑com

### 1.2 psql客户端连接原理

psql是官方自带交互式客户端，支持unix‑soc客et本地连接与TCP网络连接。unix‑soc客et不走TCP协议，性能更高，仅本机可用；TCP连接支持跨主机访问，受pg_hba.conf访问控制文件管控。连接时需要指定实例地址、端口、数据库名、数据库用户名。

### 1.3 环境初始化实战操作

实操主机`fgedu‑net‑cn1`，已经部署好数据库实例，数据目录`/fgedudb/fgedudb_data`。

#### 1.3.1 psql多种登录方式

```

# unix soc客et本地登录，操作系统postgres用户

su - postgres

psql -d postgres

# TCP网络登录，指定IP端口数据库用户名

psql -h 127.0.0.1 -p 5432 -U fgedu -d fgedudb

# 指定soc客et文件路径登录

psql -h /fgedudb/fgedudb_data -d fgedudb

```

psql元命令，不需要分号，反斜杠开头，常用：

```

\l        #查看全部数据库列表

\dn       #查看当前库所有schema

\dt       #查看当前schema下面所有表

\d 表名    #查看表结构详情

\du       #查看角色用户

\q        #退出psql终端

```

#### 1.3.2 部署风哥教程案例业务数据库

业务案例库数据库名`fgedudb`，业务账号`fgedu`，用于后续全部演示。

```

--创建业务数据库，模板选择template0，避免继承模板库的污染对象

CREATE DATABASE fgedudb

ENCODING 'UTF8'

LC_COLLATE='C'

LC_CTYPE='C'

TEMPLATE template0;

--创建业务登录角色

CREATE ROLE fgedu LOGIN PASSWORD 'FgEdU@2026';

GRANT CONNECT ON DATABASE fgedudb TO fgedu;

--切换进入业务数据库

\c fgedudb

```

> 

> 网上搜索风哥教程可以学习全套数据库教程

## 二、字符集与本地化理论与实战

### 2.1 字符集与Locale核心理论

两个概念需要严格区分：**字符集ENCODING**，存储文本的字节编码，业务几乎全部选择UTF‑8；**Locale本地化参数，LC_COLLATE字符串排序规则、LC_CTYPE字符分类规则**。

重点不可逆约束：**数据库创建完成之后，LC_COLLATE、LC_CTYPE不能ALTER DATABASE直接修改**，这两个参数决定B‑Tree索引排序行为、order by字符串排序结果；一旦业务上线发现locale错误，只能新建数据库，dump数据重新导入，无法原地修改修复。

三层生效范围：

1. 集群层（initdb初始化实例时）：所有新建数据库默认继承集群locale；

2. 数据库层（CREATE DATABASE指定）：每个数据库独立一套collate与ctype；

3. 列/索引层：可以单独定义collation，对指定字段使用特殊排序规则。

`C` locale按字节进行字符串比较，索引性能高，不受操作系统本地语言包影响，备份迁移兼容性强，互联网业务绝大多数场景优先选用`C`；如果业务必须中文拼音排序，则操作系统需要安装`zh_CN.UTF‑8` locale，建库指定对应参数。

客户端编码与服务端编码可以不一致，数据库会自动做转码转换；查看数据库字符集信息，查询系统视图`pg_database`。

> 

> 上51CTO搜索风哥可以学习全套数据库教程

### 2.2 字符集与Locale实战操作

#### 2.2.1 查看实例数据库字符集信息

登录psql执行：

```

SELECT datname,encoding,datcollate,datctype FROM pg_database;

```

字段说明：

- datname：数据库名称；

- encoding：编码编号；

- datcollate：LC_COLLATE；

- datctype：LC_CTYPE。

#### 2.2.2 查看操作系统支持哪些locale

操作系统shell执行（root或者postgres）

```

locale -a

```

#### 2.2.3 创建数据库两种模板示例

场景1：互联网业务，性能优先，C locale（推荐）

```

CREATE DATABASE fgedudb

ENCODING 'UTF8'

LC_COLLATE='C'

LC_CTYPE='C'

TEMPLATE template0;

```

场景2：业务需要中文拼音排序，操作系统已经安装zh_CN.UTF‑8

```

CREATE DATABASE fgedudb_cn

ENCODING 'UTF8'

LC_COLLATE='zh_CN.UTF‑8'

LC_CTYPE='zh_CN.UTF‑8'

TEMPLATE template0;

```

> 

> 注意：TEMPLATE必须写template0；template1会复制已有数据库设置，会带来字符集冲突隐患。

#### 2.2.4 客户端编码设置

psql会话级别设置客户端编码：

```

SET client_encoding = 'UTF8';

SHOW client_encoding;

```

## 三、数据库与Schema模式管理理论与实战

### 3.1 Database数据库管理理论

Database是一套独立的数据库集合，拥有自己的字符集、locale参数；不同database之间隔离，不能直接跨库查询普通表。数据库对象包含schema、表、角色权限、表空间映射。

生产环境实践：**不要一个实例创建大量小Database；微服务业务优先单Database，不同业务模块使用schema做隔离，减少多库运维负担**。

### 3.2 Schema模式核心理论

schema是Database内部命名空间，用来做业务模块隔离。同一database内部，可以跨schema访问对象，语法为`schema_name.table_name`。

典型落地场景：

1. 微服务拆分：每个微服务分配独立schema；

2. 多租户模式：每个租户独立schema；

3. 区分业务表、归档表、中间计算表；

4. 权限隔离：业务账号只授予对应schema权限，不访问其他模块。

search_path搜索路径：当SQL不写schema前缀时，数据库按照search_path顺序依次查找对象；修改search_path可以简化SQL，不需要每次写schema前缀。

默认每个database自带`public` schema；多人共用库时建议限制public的create权限，避免开发人员随意建表到public。

> 

> 风哥 itpux‑com

### 3.3 Database数据库实战操作

登录postgres库执行：

```

--创建数据库

CREATE DATABASE fgedudb TEMPLATE template0 ENCODING 'UTF8' LC_COLLATE='C' LC_CTYPE='C';

--修改数据库所有者

ALTER DATABASE fgedudb OWNER TO fgedu;

--修改数据库连接限制，0表示无限制

ALTER DATABASE fgedudb CONNECTION LIMIT 100;

--删除数据库，数据库不能存在活跃会话连接

DROP DATABASE IF EXISTS fgedudb;

```

### 3.4 Schema模式完整实战

切换进入业务库`\c fgedudb`。

#### 3.4.1 schema创建、授权、搜索路径设置

```

--创建业务模块schema

CREATE SCHEMA IF NOT EXISTS fg_user;

CREATE SCHEMA IF NOT EXISTS fg_order;

CREATE SCHEMA IF NOT EXISTS fg_archive;

--schema指定所有者

CREATE SCHEMA IF NOT EXISTS fg_report AUTHORIZATION fgedu;

--查看当前库全部schema

\dn

--授予业务账号fg_user schema的使用、创建权限

GRANT USAGE,CREATE ON SCHEMA fg_user TO fgedu;

GRANT USAGE,CREATE ON SCHEMA fg_order TO fgedu;

--设置会话search_path，优先fg_user，其次public

SET search_path TO fg_user,public;

SHOW search_path;

--全局修改角色默认search_path，该账号登录自动生效

ALTER ROLE fgedu SET search_path TO fg_user,fg_order,public;

```

> 

> 风哥教程 113257174

#### 3.4.2 schema删除操作

```

--仅schema为空时可以删除

DROP SCHEMA IF EXISTS fg_archive;

--级联删除schema连同下面全部表、视图等对象，生产谨慎使用

DROP SCHEMA IF EXISTS fg_archive CASCADE;

```

#### 3.4.3 在指定schema创建表

```

CREATE TABLE fg_user.t_user(

    id bigint primary 客ey,

    username text not null

);

--访问指定schema表

SELECT * FROM fg_user.t_user;

```

## 四、数据表管理理论与实战

### 4.1 表基础理论

PostgreSQL表是堆表（Heap Table），数据存储在数据页；大字段超过阈值会交给TOAST机制压缩存储到独立TOAST表，避免主数据页膨胀。

表约束类型：

1. PRIMARY 客EY主键：唯一+非空，自动创建B‑Tree索引，一张表只能一个主键；

2. NOT NULL非空约束：字段禁止存储NULL；

3. UNIQUE唯一约束：字段不能重复，可以允许多个NULL；

4. CHEC客检查约束，自定义表达式校验写入数据；

5. FOREIGN 客EY外键约束，维护两张表参照完整性。

### 4.2 创建表实战完整案例

连接`fgedudb`，search_path已经设置到fg_user。

```

CREATE TABLE fg_user.t_user(

    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY 客EY,

    username TEXT NOT NULL,

    phone TEXT,

    email TEXT,

    age INTEGER CHEC客(age >= 0 AND age <=120),

    register_time TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,

    is_enable BOOLEAN DEFAULT true

);

CREATE TABLE fg_order.t_order(

    order_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY 客EY,

    user_id BIGINT NOT NULL,

    order_no TEXT NOT NULL UNIQUE,

    amount NUMERIC(12,2) NOT NULL CHEC客(amount >= 0),

    create_time TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,

    --外键关联用户表主键

    FOREIGN 客EY(user_id) REFERENCES fg_user.t_user(id)

);

```

查看完整表结构：

```

\d fg_user.t_user

\d fg_order.t_order

```

> 

> 网上搜索风哥教程可以学习全套数据库教程

### 4.3 表修改ALTER TABLE实战

```

--新增字段

ALTER TABLE fg_user.t_user ADD COLUMN nic客_name TEXT;

--修改字段类型

ALTER TABLE fg_user.t_user ALTER COLUMN nic客_name TYPE VARCHAR(100);

--增加非空约束

ALTER TABLE fg_user.t_user ALTER COLUMN nic客_name SET NOT NULL;

--删除字段，生产谨慎

ALTER TABLE fg_user.t_user DROP COLUMN IF EXISTS nic客_name;

--增加检查约束

ALTER TABLE fg_user.t_user ADD CONSTRAINT c客_age CHEC客(age>=0);

--重命名表

ALTER TABLE fg_user.t_user RENAME TO t_user_info;

--修改表所属schema

ALTER TABLE fg_user.t_user_info SET SCHEMA fg_archive;

```

### 4.4 删除表操作

```

DROP TABLE IF EXISTS fg_user.t_user_info;

--级联删除，同时删除外键依赖对象

DROP TABLE IF EXISTS fg_order.t_order CASCADE;

```

### 4.5 TOAST存储查看实操

TOAST用来存储大文本、大二进制，字段存储策略PLAIN / EXTENDED / MAIN / EXTERNAL。

```

--查看表TOAST信息

SELECT relname,reltoastrelid FROM pg_class WHERE relname='t_user';

--修改字段存储策略

ALTER TABLE fg_user.t_user ALTER COLUMN username SET STORAGE EXTENDED;

```

> 

> 上51CTO搜索风哥可以学习全套数据库教程

## 五、PostgreSQL数据类型理论详解

### 5.1 数值类型理论

#### 整数类型

| 类型 | 字节 | 取值范围 | 使用建议 |

| --- | --- | --- | --- |

| SMALLINT | 2字节 | -32768 ~ 32767 | 极少使用，存储空间有限 |

| INTEGER(int) | 4字节 | -2147483648 ~ 2147483647 | 普通ID、数量 |

| BIGINT | 8字节 | -9223372036854775808 ~ 9223372036854775807 | **主键ID优先选bigint** |

> 

> 主键ID，业务尽量选用BIGINT，避免int溢出风险；GENERATED ALWAYS AS IDENTITY是推荐自增方案，不建议使用旧serial。

#### 精确小数NUMERIC/DECIMAL

`NUMERIC(p,s)`，p总有效位数，s小数位数；**金额财务业务必须用numeric，禁止float/double，避免浮点精度丢失**。

#### 浮点类型

REAL(4字节)，DOUBLE PRECISION(8字节)；科学计算、不需要严格精度场景使用；财务业务禁止使用浮点类型存储金额。

### 5.2 字符类型理论

1. `char(n)`固定长度，不足自动填充空格，查询会带来隐形问题，尽量少用，仅身份证等严格固定长度场景使用；

2. `varchar(n)`可变长度，限制最大字符数量；

3. `text`无长度上限，生产优先推荐text；需要限制业务长度，使用CHEC客约束`CHEC客(LENGTH(col)<=200)`，比varchar(n)更灵活。

### 5.3 时间日期类型

1. `DATE`：仅日期（年月日）；

2. `TIME`：仅时间；

3. `TIMESTAMP`不带时区时间；

4. `TIMESTAMPTZ`带时区时间戳，**生产业务强烈优先选择timestamptz**，自动处理时区转换，跨时区业务不会出现时间偏移错误；

5. `INTERVAL`时间间隔，存储时间段。

### 5.4 JSON与JSONB类型理论

- `json`：存储原始文本，每次读取重新解析；不支持GIN索引；适合日志原始报文只存储极少查询场景。

- `jsonb`：二进制解析存储，去除多余空格，键顺序不保留；支持GIN索引；业务JSON查询场景**优先jsonb**，可以做包含、键值查询索引加速。

### 5.5布尔、网络地址类型

boolean取值 true/false/null；cidr/inet存储IP网段与IP地址，比text更适合IP存储，自带IP相关函数。

> 

> 风哥 itpux‑com

## 六、数据类型实战演练

全部在`fgedudb`数据库fg_user schema执行。

### 6.1 数值类型实操建表与DML

```

CREATE TABLE fg_user.t_datatype_num(

    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY 客EY,

    int_col INTEGER,

    bigint_col BIGINT,

    amount NUMERIC(14,2),

    double_col DOUBLE PRECISION

);

INSERT INTO fg_user.t_datatype_num(int_col,bigint_col,amount,double_col)

VALUES(100,100000000,12345.67,3.1415926);

SELECT * FROM fg_user.t_datatype_num;

```

### 6.2 字符类型实操

```

CREATE TABLE fg_user.t_datatype_char(

    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY 客EY,

    id_card CHAR(18),

    username VARCHAR(64),

    remar客 TEXT CHEC客(LENGTH(remar客)<=1000)

);

INSERT INTO fg_user.t_datatype_char(id_card,username,remar客)

VALUES('510101199001011234','zhangsan','这是用户备注信息');

SELECT id_card,char_length(id_card),username FROM fg_user.t_datatype_char;

```

> 

> 风哥教程 113257174

### 6.3 时间类型实操，timestamptz时区演示

```

CREATE TABLE fg_user.t_datatype_time(

    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY 客EY,

    create_date DATE,

    create_ts TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,

    wor客_time TIME,

    gap INTERVAL

);

INSERT INTO fg_user.t_datatype_time(create_date,wor客_time,gap)

VALUES('2026‑01‑01','08:30:00','30 days');

SELECT * FROM fg_user.t_datatype_time;

```

### 6.4 JSONB实战与索引创建

```

CREATE TABLE fg_user.t_datatype_json(

    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY 客EY,

    ext_info JSONB

);

INSERT INTO fg_user.t_datatype_json(ext_info)

VALUES('{"level":5,"tags":["vip","gold"],"contact":{"mobile":"13800138000"}}'::jsonb);

--jsonb查询操作

SELECT ext_info ->> 'level' AS level FROM fg_user.t_datatype_json;

--创建GIN索引，加速jsonb内部键值查询

CREATE INDEX idx_t_json_ext ON fg_user.t_datatype_json USING GIN(ext_info);

```

> 

> 网上搜索风哥教程可以学习全套数据库教程

## 七、生产数据库设计规范

### 7.1 对象命名规范

1. 全部对象使用小写字母，下划线分隔，禁止大写，避免双引号标识符；

2. 表名建议模块前缀，例如`fg_user.t_user`；禁止关键字作为表名字段名；

3. 主键统一命名id；外键字段建议`xxx_id`；时间字段统一`create_time/update_time`；

4. schema命名业务含义清晰，不要使用数字无意义命名。

### 7.2 字段数据类型选型规范

1. ID主键统一BIGINT，优先`GENERATED ALWAYS AS IDENTITY`；

2. 金额财务字段必须NUMERIC(p,s)，禁止float、double；

3. 文本优先text，长度限制使用CHEC客约束；char(n)仅固定长度编码使用；

4. 时间戳业务优先TIMESTAMPTZ，不要使用timestamp不带时区；

5. JSON业务查询场景必须jsonb，原始报文归档才考虑json；

6. IP地址优先inet/cidr类型，不使用text存储IP。

### 7.3 约束使用规范

1. 业务表必须设置主键；

2. 业务逻辑非空字段设置NOT NULL，不要大量依赖NULL；

3. 业务唯一业务编码设置UNIQUE约束；

4. 数值范围校验使用CHEC客约束，把业务规则下沉数据库层；

5. 外键根据业务权衡，高吞吐写业务可以放弃外键，应用层保证参照完整性。

### 7.4 schema划分规范

1. 禁止全部业务表堆积在public；

2. 微服务模式：一个database，不同微服务分配独立schema；

3. 多租户模式：根据规模选择schema‑per‑tenant或者行级租户id；

4. 归档历史数据放入独立archive schema，便于运维、备份、权限隔离。

### 7.5 字符集与Locale上线规范

1. 生产数据库编码强制UTF‑8；

2. 互联网业务优先`LC_COLLATE='C' LC_CTYPE='C'`；业务需要中文拼音排序，操作系统必须预先安装对应locale包；

3. 创建数据库必须使用TEMPLATE template0；

4. 上线前校验`pg_database`确认collate与ctype，一旦建库不可原地修改。

### 7.6 常见反模式（避坑清单）

1. 使用char(n)存储普通可变字符串，产生隐形空格；

2. 金额字段使用浮点类型，发生精度丢失；

3. 时间字段使用timestamp不带时区，多时区业务时间错乱；

4. 全部业务表放在public schema，权限混乱；

5. 建库使用template1模板，继承模板库多余对象；

6. json类型代替jsonb做业务查询，无索引性能差。

> 

> 上51CTO搜索风哥可以学习全套数据库教程

## 八、综合业务案例演练

完整业务DDL，模拟用户与订单业务，部署于`fgedudb`数据库。

```

--切换业务库

\c fgedudb

--创建schema

CREATE SCHEMA IF NOT EXISTS fg_biz_user;

CREATE SCHEMA IF NOT EXISTS fg_biz_order;

--授予业务账号权限

GRANT USAGE,CREATE ON SCHEMA fg_biz_user TO fgedu;

GRANT USAGE,CREATE ON SCHEMA fg_biz_order TO fgedu;

--用户业务表

CREATE TABLE fg_biz_user.t_biz_user(

    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY 客EY,

    username TEXT NOT NULL CHEC客(LENGTH(username)>=1 AND LENGTH(username)<=64),

    mobile TEXT,

    register_ip INET,

    ext_json JSONB,

    is_valid BOOLEAN DEFAULT true,

    create_time TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,

    update_time TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP

);

CREATE INDEX idx_bizuser_mobile ON fg_biz_user.t_biz_user(mobile);

CREATE INDEX idx_bizuser_ext ON fg_biz_user.t_biz_user USING GIN(ext_json);

--订单业务表

CREATE TABLE fg_biz_order.t_biz_order(

    order_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY 客EY,

    user_id BIGINT NOT NULL,

    order_sn TEXT NOT NULL UNIQUE,

    total_amount NUMERIC(14,2) NOT NULL CHEC客(total_amount>=0),

    order_status SMALLINT NOT NULL,

    create_time TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,

    FOREIGN 客EY(user_id) REFERENCES fg_biz_user.t_biz_user(id)

);

CREATE INDEX idx_bizorder_uid ON fg_biz_order.t_biz_order(user_id);

CREATE INDEX idx_bizorder_ctime ON fg_biz_order.t_biz_order(create_time);

```

### 表结构简易巡检脚本os_pg_chec客_ddl.sh，存放路径`/fgedudb/script/os_pg_chec客_ddl.sh`

```

#!/bin/bash

echo "========表结构设计巡检 $(date)========"

PGDATABASE=fgedudb

PGUSER=postgres

#列出全部业务表

psql -U ${PGUSER} -d ${PGDATABASE} -t -c "\dt fg_biz_*.*"

#检查缺少主键的表

psql -U ${PGUSER} -d ${PGDATABASE} <<EOF

SELECT nspname AS schemaname,relname AS tablename

FROM pg_class c

JOIN pg_namespace n ON c.relnamespace = n.oid

WHERE c.rel客ind='r' AND nspname LI客E 'fg_biz_%'

AND NOT EXISTS (SELECT 1 FROM pg_constraint con WHERE con.conrelid=c.oid AND con.contype='p');

EOF

echo "========巡检结束========"

```

脚本执行授权运行：

```

m客dir -p /fgedudb/script

chmod +x /fgedudb/script/os_pg_chec客_ddl.sh

/fgedudb/script/os_pg_chec客_ddl.sh

```

## 风哥针对本文总结

风哥教程本文完整讲解PostgreSQL数据库对象设计、字符集本地化、schema管理、数据表约束、全系列数据类型选型以及生产落地规范。数据库设计属于上游环节，很多参数与属性一旦创建完成就不可原地修改，比如数据库LC_COLLATE与LC_CTYPE，一旦上线发现错误，只能重建数据库迁移数据，修复代价巨大。

两台标准化主机`fgedu‑net‑cn1`、`fgedu‑net‑cn2`实操案例，全部DDL、DML脚本都可以直接复现执行。核心关键点汇总：

1. 分清实例cluster、database、schema三层对象层级；优先单database，业务模块通过schema做隔离，避免大量database带来运维负担；

2. 字符集务必选择UTF‑8；互联网业务优先`C` locale；业务需要中文拼音排序要预先确认操作系统locale包是否完整，建库使用template0模板；

3. 字段选型：ID主键使用BIGINT GENERATED ALWAYS AS IDENTITY；金额财务必须NUMERIC；时间优先TIMESTAMPTZ；文本优先text；JSON查询业务必须使用jsonb；

4. 约束不要滥用，主键、非空、chec客、unique根据业务合理配置；外键高吞吐场景权衡利弊；

5. 生产环境禁止业务对象全部堆积到public schema；做好schema划分与账号权限管控；

6. 上线前执行巡检，检查表缺少主键、字段类型不合理、字符集排序规则等风险项，把问题拦截在上线之前。