[TOC] > [中文文档14](http://postgres.cn/docs/14/index.html) ## 概述 一般的开发依赖为`Redis + MySQL + Greenplum/Hadoop + Kafuka/Flink + ElasticSearch` 组合,但是使用 pgsql 就可以一个搞定 * **OLTP**：事务处理是PostgreSQL的本行 * **OLAP**：citus分布式插件，ANSI SQL兼容，窗口函数，CTE，CUBE等高级分析功能，任意语言写UDF * **流处理**：PipelineDB扩展，Notify-Listen，物化视图，规则系统，灵活的存储过程与函数编写 * **时序数据**：timescaledb时序数据库插件，分区表，BRIN索引 * **空间数据**：PostGIS扩展（杀手锏），内建的几何类型支持，GiST索引。 * **搜索索引**：全文搜索索引足以应对简单场景；丰富的索引类型，支持函数索引，条件索引 * **NoSQL**：JSON，JSONB，XML，HStore原生支持，至NoSQL数据库的外部数据包装器 * **数据仓库**：能平滑迁移至同属Pg生态的GreenPlum，DeepGreen，HAWK等，使用FDW进行ETL * **图数据**：递归查询 * **缓存**：物化视图 **优点** DDL能放入事务中，删表，TRUNCATE，创建函数，索引，都可以放在事务里原子生效，或者回滚。这就能进行很多骚操作，比如在一个事务里通过RENAME，完成两张表的王车易位。能够并发地创建或删除索引（不锁表）；为表添加新的空字段不锁表，瞬间完成。这意味着可以随时在线上按需添加移除索引，添加字段，不影响业务。复制方式多样：段复制，流复制，触发器复制，逻辑复制，插件复制，多种复制方法。丰富的复制支持使得不停服务迁移数据变得无比容易。提交方式多样：异步提交，同步提交，法定人数同步提交。FDW的存在让ETL变得无比简单，一行SQL就能解决。系统视图非常完备，做监控系统相当简单。 ## Don't Do This > [Don't Do This](https://wiki.postgresql.org/wiki/Don%27t_Do_This) ### 不要在查询中使用 NOT IN **问题**：NOT IN 在处理大集合时，性能会迅速下降，尤其是当集合中包含 NULL 时，行为可能会不一致。 **解决方案**：使用 LEFT JOIN 或 NOT EXISTS 来替代 NOT IN，这样可以提高查询性能并避免潜在的逻辑问题。 ### 不要使用大写的表名或列名 PostgreSQL 将所有名称 - 表、列、函数和其他所有内容 - 折叠为小写，除非它们是 “双引号”。 ### 不要使用 BETWEEN（尤其是与时间戳一起使用） `BETWEEN`使用封闭区间比较：指定范围的两端的值都包含在结果中。 如 ``` SELECT * FROM blah WHERE timestampcol BETWEEN '2018-06-01' AND '2018-06-08' ``` 这将包括时间戳正好为 2018-06-08 00：00：00.000000 的结果，但不包括同一天晚些时候的时间戳。因此，查询似乎有效，但是一旦你在午夜收到一个条目，你最终就会重复计算它。 正确执行 ``` SELECT * FROM blah WHERE timestampcol >= '2018-06-01' AND timestampcol < '2018-06-08' ``` ### Text storage 文本存储 尽量直接使用 `TEXT` 类型，而不要过于纠结选择其他字符串类型（如 `CHAR` 或 `VARCHAR`）。这种建议主要基于 PostgreSQL 对字符串类型的实现方式和其灵活性 * **性能差异极小**： * PostgreSQL 对 `TEXT` 和 `VARCHAR(n)` 的实现是几乎一样的，性能上没有显著差异。 * 唯一的区别是 `VARCHAR(n)` 会额外检查长度限制，这可能会稍微增加开销。 * **灵活性**： * `TEXT` 没有长度限制，可以处理动态变化的数据需求，而 `VARCHAR(n)` 必须在设计时设定固定长度。 * 避免了将来因修改列定义（比如更改长度限制）而需要迁移数据的麻烦。 * **简化设计**： * 使用 `TEXT` 避免了对字段长度的预估错误（如 `VARCHAR(255)` 的限制过小或过大）。 * 提高代码和数据库设计的可维护性。 * **兼容性**： * 某些 ORM（对象关系映射工具）或框架默认将字符串映射为 `TEXT`，例如 Django 就推荐使用 `TEXT`。