PostgreSQL性能綜述.docxVIP

目录# 架构 #2# 性能 #2## 复杂查询场景 ##3## 性能特性 ##4# 多核扩展能力 #6# IO扩展能力 #6# count(*) #7# 事务系统 #7# 连接扩展能力和线程池 #8# benchmark #8# ACID实现承诺 #9# 特性 #9## 图形化管理工具 ##9## 简化使用或严格限制 ##9##?Insert Ignore / Replace ##10## 约束 ##10## 字段默认值 ##10## 存储过程 ##10## 触发器 ##11# 复制和高可用 #12# 数据类型 #15# 子查询 #17# JOIN #17# 高级索引 #17# 表分区 #19# CTE语法 #20# 分析函数 #22# 序列 #23# 诊断和性能管理 #23# 其他特性 #24# 许可 #25# 社区分支 #26# 支持服务 #26# 用户群体和流行度 #28# 与Oracle的兼容性 #29# 架构 #MySQL SQL层和数据存储层剥离，支持多种存储引擎。例如InnoDB, MyISAM, NDB。每种存储引擎适用于不同的场景，例如InnoDB支持行锁，支持ACID。而NDB则属于内存存储引擎的一种。用户可以根据自己的需求选择不同的存储引擎，但是请注意，每种存储引擎有各自的优缺点，务必了解清楚。在一个数据库中使用多种存储引擎也可能给事务一致性带来一定的问题。PostgreSQL 目前仅支持一种存储引擎，适合大多数的应用场景，如果需要用到某些特殊场景，可以使用FDW或者UDF来扩展PostgreSQL的存储引擎方面的能力，例如使用FDW可以将mongoDB,redis,MySQL等非常多的外部数据源作为本地表直接使用，使用UDF则可以满足在数据库中直接操纵外部数据源的目的。 参考?/wiki/Fdw?/digoal@126/blog/static/1638770402015622360849/# 性能 #性能的比较是最难说清的，应用场景的不同，优化水平的不同，环境的不同都是性能评测的干扰因素。wikivs中提到MySQL是为简单应用设计初衷，PostgreSQL是为功能和可靠性设计初衷。所以MySQL在简单查询场景比较快，PostgreSQL在复杂查询场景比较快。(i.e. MySQL fast in simple operations, PostgreSQL more reliable and faster in complex operations)，不过实际上PostgreSQL在简单查询场景并不慢，可以参考一下我之前写的一系列PostgreSQL和Oracle在简单查询中的性能测试文章。/digoal@126/blog/static/163877040201541104656600//digoal@126/blog/static/16387704020154431045764/## 复杂查询场景 ##MySQL 在复杂查询场景较弱，可能体现在SQL执行计划生成方面，以及对查询的支持方面，如PG支持HASH JOIN,MERGE JOIN,NESTLOOP JOIN，MySQL目前仅支持NESTLOOP。PostgreSQL 在复杂查询场景的处理能力较强，得益于良好的执行计划体系，CBO还是做得比较到位的，支持的因子：# - Planner Cost Constants -#seq_page_cost = 1.0 ? ? ? ? ? ? ? ? ? ?# measured on an arbitrary scale#random_page_cost = 4.0 ? ? ? ? ? ? ? ? # same scale as above#cpu_tuple_cost = 0.01 ? ? ? ? ? ? ? ? ?# same scale as above#cpu_index_tuple_cost = 0.005 ? ? ? ? ? # same scale as above#cpu_operator_cost = 0.0025 ? ? ? ? ? ? # same scale as aboveeffective_cache_size = 8GBIO处理能力的因子可以设置到表空间级别，对于多种IOPS能力不一的存储混合使用的场景该设置尤为有效。支持的优化手段：遗传算法，对于超出一定数量的JOIN表，有效避免穷举带来的生成计划的开销。# - Genetic Query Optimizer -#geqo = on#geqo_threshold = 12#geqo_effort = 5 ? ? ? ? ? ? ? ? ? ? ? ?# range 1-10#geqo_pool_size = 0 ? ? ? ?