ANBOB™

前2篇中对index only scan的测试能看出在 Oracle、MySQL(InnoDB)、PostgreSQL三类数据库中，对于OLTP高负载的场景中，oracle和mysql(innodb)都是块级别的MVCC是可以做到真正的index only scan, 而postgresql因为MVCC的可见性不存储在索引，在数据变更后会带来indexonlyscan with heap fetchesl回表,效率可能有所减退。通常在Oracle中如想做到index 覆盖到所有查询的列，会创建多列复合索引或function索引，避免索引查询回表，但在Postgresql或openGauss系中索引相对Oracle还有两种特殊情况

在上一篇中提到了indexonlyscan, 在它执行计划中可以看到有一行Heap Fetches，这篇主要记录一下它的含义。因为Postgresql系的MVCC实现原理，索引中不存在可见性映射(Visibility information)，在PostgreSQL中的indexonlyscan 也并不总是scan index only, 简而言之就是如果表(heap)的数据没有对应可见性映射文件(table’s visibility map.)或不是全部完全可见，indexonlyscan的执行计划还是要回表(heap)去检查数据，回表数据记录在heap fetches.

PostgreSQL系(openGASUSS)数据库中的所有索引都是二级索引, 数据表段（ heap）和索引段（index）分别存储，通常对于多列表的SQL只返回或where中仅少量的列时，希望可以只从索引中检索，而不用再从索引回表返回数据（本篇不考虑可见性）提高查询效率，像在oracle中有index full scan和index fast full scan的执行计划，在Postgresql中也支持Btree index的indexonlyscan， MySQL中同样支持，但发现PostGreSQL默认配置的SQL优化器通常判断索引的cost大于表扫描，导致仅查询索引列也未使用索引

SQL语言当今在数据查询分析这块地位至今无法撼动，曾经的NoSQL也开始疲软，口号从”no SQL”也变成了“not only SQL”或“no , SQL！”， 但SQL的开发能力参差不齐，有些是从ORACLE数据库转到postgreSQL的，相同SQL的结果不并相同，在性能上也并不是所有人都可以编写高效正确查询，这里简单列几个在PG中几个SQL注意事项。

openGauss/PostgreSQL中的预写式日志WAL（Write Ahead Log），又名Xlog或redo log,相当于oracle的online redo log, 不同的是oracle online redo log是提前创建几组滚动使用，但在opengauss中只需要本配置参数控制WAL日志的周期，数据库会一直的创建并自动清理，但存在一些情况WAL日志未清理导致目录空间耗尽，或目录空间紧张时手动删除wal日志时，比如如何确认在非归档模式下哪些WAL日志文件可以安全删除？

前一段时间发布了openGauss 5.0，做为激进派的我们生产环境立即安装一套，可以在使用MTK工具迁移库时提示”charset”语法错误，为关键字KeyWord，在关键字有一个限制，所以关键字越少那从其它库迁移时在SQL文本、对象名上限制改动就越少， 每个版本关键字数量也在变化，不过最新的Postgresql要比openGauss少约1/3， 之前这套库从oracle迁移到opengauss3.1不存在该问题， 如果有数据库迁移时使用该关键字当心。

有一个项目从oracle迁移到了opengauss（MogDB发行版）后，有部分应用在运行一段时间后会超时， 日志中一些Socket closed错误， 执行的是从数据库中unload一些查询数据离线存储，常见的问题有网络防火墙， 或有一些timeout配置，或网络闪断等，逐一排除，当然在出问题时，应用厂家可能出于责任原因并不会坦诚，变更的是DB，会把怀疑方向指向DB, 但最终确认是中间件配置问题， 这里简单记录一下.

在openGauss数据库后期维护中难免有数据迁移或复制， 比如从oracle异构数据迁移，或在同一个server中复制一个schema到另一schema， 或是从另一个server复制到本server， 有一些命令行工具可以高效率的处理这些需求，并且可以迁移数据不生成落地文件，提升迁移速度,这里简单记录三种需求。

Postgresql系为了避免像oracle ora-1555的问题，使用非undo的机制， 但需要周期性的做VACUUM，否则表上的dead tuples就没有办法复用或回收。 并且在PG或OG数据库Vacuum的最老位置是系统级的，如果有一个长事务存在，那长事务时间的其它表也没办法Vacuum，因为它不确认你是否会查其它表， 随时间推移，对于update,delete较多的表就会导致表膨胀较为明显，影响系统性能， 如果无法限制应用，此时可以定期的KILL一些长事务会话..

对于oracle DBA查看数据库实例参数可以在sqlplus中使用show prameter xxx 模糊匹配非隐藏参数或已修改隐藏参数，当然也可以查询v$ 的视图， 在openGauss或postgresql当前版本中需要匹配输入参数名，当然参数名我们不可能完全记的全名，模糊搜索需要手动创建个shell方法。

最近有项目从oracle迁移到openGuass后存在部分应用SQL提示语法不兼容问题， 后发现SQL中在原oracle执行中包含中文逗号”，”做为查询列的分隔符， 以我对oracle的认识oracle不太可能支持中文SQL语法， 找应用常用的plsql developer工具演示了一下，果然支持中文逗号，甚至还支持中文的括号，或一半中文一半英文如”（)”. 但是这种SQL在mysql, postgresql, openguass是都不支持的

创建索引是table优化访问的常用手段， 但是通常create index会影响对表上的其他DML执行(非online)， oracle和postgresql在该方面提供了online的方法，但是可能会增加索引的创建时间，对于表大小超过GB创建索引你可能希望如何加速创建索引

子曰：“君子谋道不谋食。耕也，馁在其中矣；学也，禄在其中矣。君子忧道不忧贫。” , 回顾我的DBA生涯，从2006接触管理SQL Server 2000到2009年开始管理Oracle, 只问耕耘，错过了一些跳跃机会，清晰记的2009年1次想跳槽面试的一次经历，当时就有这道笔试题，我写了3种答案

在数据库日常运维中难免会随着Table数据量f增加，原来的数据类型需要修改，在Oracle如是加长兼容的列类型可以直接修改元数据，而其它提示列上有数据不允许修改，在MySQL和PG,openGauss中修改列如从int 到bigint时会导致表数据reload, 在之前“alter table ” modify column in Oracle、MySQL、PostGreSQL(数据库比较系列十三) 笔记有记录这一现象，而如果表已经很大，该操作可能从空间与业务连续的影响时间上都比较大，前不久看到一种方法觉的不错简单记录一下。

范围分区是大型数据库中常用的Table类型， 如按时间维度划分方便后期的周期清理，在Oracle中range分区只需指定分区的上限(less than)，而在PostgreSQL中的分区比较另类，需要指定分区的上限和下限区间，而这种涉及就有可能存在一个问题，超出分区的范围除了表级最小和最大时间，在PostgreSQL中还有可能因为条件不连续存在分区之间的GAP，如以天为分区， 分区界限是2023/03/01, 2023/03/02, 2023/03/04, 缺失 2023/03/03分区

在关系型数据库中，索引是SQL查询性能优化的常用技术，mysql可能不会创建太大的数据库，但是pg和oracle表达到100G或TB以上时，慢查询可能会比较明显，需要考虑创建适当的索引，但随着时间的推移，索引可能需要一些维护来保持性能. 通常当涉及到表时更新时，Oracle管理UNDO的方式和PostgreSQL中的MVCC工作方式略有不同，然而索引仍然可能碎片化，因此需要重新构建。

通过扩展EXPLAIN添加值来描述postgresql数据库中SQL的执行计划每个操作读/写的数据,需要使用ANALYZE参数，从Postgres 13开始，它可以额外报告planner的缓冲区使用情况。默认情况下，BUFFERS是关闭的。在更多的情况下，使用BUFFERS将极大地帮助我们理解内部发生了什么

近年来国家xc的推广，现阶段国产或开源库迁移逐渐列上日程，目前看已大势所趋， 在选择部分国产(基于)或开源数据库里安全健康的开源协议需要考虑， PostgreSQL是功能强大最接近Oracle的并有全球客户经过长期磨炼过生态健全的关系型数据库，最近有一个项目在原有一套Oracle的应用数据迁移到PG后，在两个PG环境中双数据源双写数据时，其中一套PG的数据库入库存在问题

PostgreSQL 具有一组丰富的索引功能，人们开发数据库一段时间后，当需要对软件架构进行更改时，他们忘记了对以前的索引进行清理。这种方法会造成混乱，有时会因为索引过多而减慢数据库的速度。

在Github看到这个项目postgres_all_versions，是Greg Sabino Mullane 开发的一个Perl脚本，可以解析在线Postgresql的官方文档，从中把所有PostgreSQL的版本及新特性变化，生成一个大的html文件。