一旦删除就不能恢复了，除非你备份了聊天记录，不然的话没有办法。所以我们可以把聊天记录备份到电脑，就不怕删除后不能恢复了。关于如何备份聊天记录，我分享一下方法。
手机端软件版本是：8028。电脑端软件版本是：36018。
具体的步骤如下：
1先让电脑和手机连接同一个网络；接着打开电脑微信，点击左下角的三条横。
2在右边会出现个列表，点击迁移与备份。
3会d出个小窗口，接着点击备份与恢复。
4然后点击备份聊天记录至电脑上方的图标。
5接着打开手机微信会出现的个页面，点击开始就可以备份了。
将数据划分为页，以页为作为交互的数据单元，基本大小为16KB。
InnoDB为了不同的⽬的⽽设计了 许多种不同类型的⻚，⽐如存放表空间头部信息的⻚，存放Insert Buffer信息的⻚，存放INODE信息的⻚，存放undo⽇志信息的⻚等等等等。
SELECT FROM record_compact WHERE C1=3;
最笨的办法：从Infimum记录（最⼩记录）开始，沿着链表⼀直往 后找，这种暴力查找当然是不可取的，为此InnoDB设计一种目录索引。制作过程如下：
步骤一：将所有的记录（最大最小记录， 不包括已标记删除的记录）分组
步骤二：将每组中的最后一条记录（也就是组内最大的记录那条）的头信息的n_owned属性表示为改组拥有的记录条数
步骤三：将每组的最后一条记录的地址偏移量（槽）单独拿出来放在靠近页尾部的地方即page_directory页目录。所以这个⻚⾯⽬录就是由槽组成的。
我们平时以记录为单元向表中插入数据，这些记录在磁盘上的存储方式称为行格式或者记录格式。目前设计了4中行格式：Compact、Redundant、 dynamic、Compressed
行格式的语法：
CREATE TABLE 表名 （列信息） ROW_FOMAT=行格式名称
ALTER TABLE 表名 ROW_FORMAT=行格式名称
------------------------------------------------------------------------------------
例如：->USE dabao；
->CREATE TABLE record_format(c1 VARCHAR(10),c2 VARCHAR(10),c3 CHAR(10),c4 VARCHAR(10) NOT NULL) CHARSET=ascii ROW_FORMAT=COMPACT;
INSERT INTO record_format(c1,c2,c3,c4)VALUES('AAA','BBBB','CCCC','DDDD'),('EEE','DDDD','DADA'NULL);
然后我们就开始解开每个行格式下的存储方式的神秘面纱。
compact分为记录的额外信息和记录的真实数据。
（1）变长字段长度列表
MySQL支持一些变长的数据类型，变长字段占用的存储空间分为两部分：真正的数据内容和占用的字节数。
把真正的数据内容占据的字节长度放在记录的开头，从而形成一个变字长的字段长度列表，各字段占用的字节数按照列的顺序 逆序 存放。根据每条记录中的列数据中的字符串大小，来判断具体使用1字节还是2个字节存储真实数据，InnoDB有自己的一套规则。M：选用的字符集类型中一个字符所占用的大小；W：变长类型的最大存储字符数；L：实际存储的字节大小。
if W＊M＜255 则采用1个字符存储真正字符串占用的字节数
else if W＊M＞255 ＆＆ L＜127 则采用1个字符存储真正字符串占用的字节数else 则采用2个字符存储真正字符串占用的字节数
变长字段长度列表只存储值为非NULL，
（2）NULL值 列表
不让把所有的null值都存储到真实数据中，所以compact列格式把null的列集中管理，存储到null值列表中，处理过程：
1．统计表中允许存储null的列表，如果表中没有可以null的列，则null值列表也不存在。否则每个允许null值的列占用一个位，并且逆序排列，二进制值为1时，该列的值为null。否则不为空。
2MySQL中规定所有的null列必须存储在整个字节的位中，位数不足则最高位补零。
（3）记录头信息
5个固定字节数。记录当前记录条数，当前堆位置，下一条记录位置等信息。
(1) User Record
（2）记录头信息的秘密
1delete_mask 这个属性表示当前记录是否被删除 占用一个位 值为1则已经删除。需要注意的是，这里的删除记录，并不是立即从磁盘中清除，是因为如果每次记录删除立即磁盘清除的话，就需要将其他记录在磁盘上重新排序需要消耗性能，所以只是打个标记，将所有的删除记录组成一个垃圾链表，标记的垃圾链表的空间则变为可重用空间，新来的记录就会覆盖标记删除的记录。
！！！删除记录位为1时与该记录假如垃圾链表其实是两个阶段。跟事务的删除 *** 作有关。
2min_rec_mask B+树的每层非叶子节点的最小记录都会添加该标记。索引的时候会用到。
3n_owned
4heap_no 表示当前记录在页中的位置，有趣的是InnoDB会在每页上默认添加最大最小伪纪录作为补充称一条完整记录。
图中可以看出 最⼩记录和最⼤记录的heap_no值分 别是0和1，也就是说它们的位置最靠前。
5record_type 表示当前记录类型，0：普通记录；1：非叶子节点记录，索引 2：最小记录；3 最大记录
6next_record 表示从当前记录的真实数据到下⼀条记录的真实数据的 地址偏移量下⼀条记录指得并不是按照我们插⼊顺序的下⼀条记录， ⽽是按照 主键值 由⼩到⼤的顺序的下⼀条记录
删除一个记录时
MySQL中除了存储c1,c2,c3,c4用户自定义列数据外，MySQL会自动为每条记录添加三个隐藏列：ROW_id(主键，唯一标识一条记录，6个字节)、 transaction_id（ 事务ID 6个字节 ）ROLL_id（回滚指针，7个字节）
对于第2条记录中c3和c4列的值都为NULL，它们被存储在了前边的NULL值列表处，在记录的真实数据处就不再冗余存储，从⽽节省存储空间。
最终的compact列格式：
如果想要c3列也变为可变字段长度，则将定长字符集改为可变字符集。
ALTER TABLE record_format MODIFY COLUMN c3 CHAR(10) CHARACTER SET = utf8 ;
对于Compact和Reduntant⾏格式来说，如果 某⼀列中的数据⾮常多的话，在本记录的真实数据处只会存储该列的前768个字节的数据和20个字节存储指向这些⻚的地址，然后把剩下的数据存放到其他⻚中，这个过程也叫做⾏溢出，存储超出768字节的那些⻚⾯也被称为溢出⻚。
MySQL中规定⼀个⻚中⾄少存放两⾏记录，溢出条件：
（1）每个⻚除了存放我们的记录以外，也需要存储⼀些额外的信 息，乱七⼋糟的额外信息加起来需要136个字节的空间。
（2）每个记录需要的额外信息是27字节。
假设⼀个列中存储的数据字节数为n，那么发⽣⾏溢出现象时需要满
⾜这个式⼦：136 + 2×(27 + n) > 16384（页大小16K） 求解这个式⼦得出的解是：n > 8098。
MySQL版本是57，它的默认⾏格式就是Dynamic，这俩⾏格式和Compact⾏格式挺像，只不过在处理⾏溢出数据时有点⼉分歧，它们不会在记录的真实数据处存储字段真实数据的前768个字节，⽽是把所有的字节都存储到其他⻚⾯中，只在记录的真实数据处存储其他⻚⾯的地址。
1 ⻚是MySQL中磁盘和内存交互的基本单位，也是MySQL是管理存储空间的基本单位。
2 指定和修改⾏格式的语法如下：
CREATE TABLE 表名 (列的信息) ROW_FORMAT=⾏格式名称
ALTER TABLE 表名 ROW_FORMAT=⾏格式名称
3 InnoDB⽬前定义了4种⾏格式
COMPACT⾏格式
REDUNDANT
DYNAMIC
COMPRESSED
1 InnoDB为了不同的⽬的⽽设计了不同类型的⻚，我们把⽤于存放记录的⻚叫做数据⻚。
2 ⼀个数据⻚可以被⼤致划分为7个部分，分别是
File Header，表示⻚的⼀些通⽤信息，占固定的38字节。
Page Header，表示数据⻚专有的⼀些信息，占固定的56个字节。
Infimum + Supremum，两个虚拟的伪记录，分别表示⻚中的最⼩和最⼤记录，占固定的26个字节。
User Records：真实存储我们插⼊的记录的部分，⼤⼩不固定。
Free Space：⻚中尚未使⽤的部分，⼤⼩不确定。
Page Directory：⻚中的某些记录相对位置，也就是各个槽在⻚⾯中的地址偏移量，⼤⼩不固定，插⼊的记录越多，这个部分占⽤的空间越多。
File Trailer：⽤于检验⻚是否完整的部分，占⽤固定的8个字节。
3 每个记录的头信息中都有⼀个next_record属性，从⽽使⻚中的所有记录串联成⼀个单链表
4 InnoDB会为把⻚中的记录划分为若⼲个组，每个组的最后⼀个记录的地址偏移量作为⼀个槽，存放在Page Directory中，所以在⼀个⻚中根据主键查找记录是⾮常快的，分为两步：
通过⼆分法确定该记录所在的槽。
通过记录的next_record属性遍历该槽所在的组中的各个记录。
5 每个数据⻚的File Header部分都有上⼀个和下⼀个⻚的编号，所以所有的数据⻚会组成⼀个双链表。
6 为保证从内存中同步到磁盘的⻚的完整性，在⻚的⾸部和尾部都会存储⻚中数据的校验和和⻚⾯最后修改时对应的LSN值，如果⾸部和尾部的校验和和LSN值校验不成功的话，就说明同步过程出现了问题。VMware虚拟机时间总是异常？简单两步彻底解决此问题
系统时间问题看似很⼩，但是对于⼀些时效性要求较⾼的业务系统，例如：考试系统、实时监
控系统等，时间问题影响甚⼤。我们在实际⽣产中也遇到⼀台虚拟机安装的Windows Server系
统（ *** 作系统时间同步NTP，未配置同步主机）由于系统时间异常导致应⽤服务出现问题。
*** 作系统时间同步
Windows：Windows *** 作系统直接把CMOS时间认定为当前显⽰时间，不根据时区转换。这样
每调整⼀次系统时区，系统会根据调整的时区来计算当前时间，确定后，也就同时修改了
CMOS内的时间。
Linux：Linux和苹果 *** 作系统以当前主板CMOS内时间做为格林威治标准时间，再根据系统设置
的时区来最终确定当前系统时间。
为什么虚拟机会有波动？
计时器中断
虚拟机与主机 *** 作系统共享底层硬件，正在运⾏的虚拟机，有时也会延迟交付虚拟计时器中
断。虚拟机只在某些特定的时刻检查挂起的虚拟计时器中断，⽐如底层硬件接收到物理计时器
中断时，让虚拟机在精确指定的时间内，去请求物理计时器中断。
因为客户 *** 作系统通过计算中断来保持时间，所以当存在计时器中断积压时，由客户 *** 作系统
测量的时间就会落后于实时时间。
VMware虚拟机如何处理计时器中断？
VMware虚拟机通过跟踪当前计时器中断待办事项列表来处理这个问题，并在待办事项列表过⼤
时以更⾼的速度交付计时器中断，以便赶上进度。
如果虚拟机运⾏得太慢，可能是由于与主机上运⾏的其他虚拟机或进程争夺CPU时间的结果，
则不能为虚拟机提供⾜够的时间跟上进度。
发⽣这种情况后，如果客户 *** 作系统安装了VMware Tools并且时钟同步功能启⽤状态，VMware
Tools会在客户 *** 作系统未来的某个时候，通过同步客户 *** 作系统与主机的时钟校正时间。VMware vSphere虚拟化环境时间配置点
ESXi主机时间
主机时间配置分为两种：⼿动配置、同步NTP服务器
主机时间配置
虚拟机时间配置
虚拟机时间配置：同步主机时间（注：必须安装VMware Tools）
虚拟机时间配置-同步主机时间
虚拟机 *** 作系统时间
Windows和Linux时间配置同样分为：VMware Tools定期时钟同步、⼿动配置、同步⽹络时
间。⼀般是Microsoft W32Time for Windows和NTP for Linux，通常⽐ VMware Tools 周期性时
间同步更准确。
通常，在我们交付虚拟机时，最好⼀次只使⽤⼀个时钟同步服务，以确保避免多个服务对时钟
进⾏更改造成冲突的问题。
虚拟机时间在什么时候会发⽣变动？
初始化时间
VMware虚拟机提供了与物理机器类似的机制：⼀个虚拟电池⽀持的CMOS时钟和虚拟⽹卡，可以⽤来从⽹络时间服务器获取时间。另外还提供了⼀种机制:VMware Tools在启动时重置客户 *** 作系统的时钟，以匹配主机的时钟。客户机和主机之间的接⼝使⽤UTC(协调世界时，也称为格林威治标准时间或GMT)，因此客户机和主机不必在同⼀时区。
注：UTC的偏移量与虚拟机的CMOS⾮易失性内存的其他内容⼀起存储在虚拟机的nvram⽂件中的。
虚拟机管理 *** 作
当虚拟机停⽌⼀段时间并继续运⾏时，客户 *** 作系统的时钟通常会落后于实际时间——特别是在挂起并恢复、快照和还原为快照或VMotion *** 作之后。因此，如果在客户 *** 作系统中安装了VMware Tools, VMware Tools守护进程将在这些事件发⽣后，即时关闭了定期的时间同步也会纠正客户 *** 作系统时钟。
VMware Tools周期同步
执⾏时间同步之后，VMware Tools 会每分钟检查⼀次，以确定客户机和主机 *** 作系统上的时钟是否仍然匹配。如果不匹配，则将同步客户机 *** 作系统上的时钟以与主机上的时钟匹配。
如何禁⽤虚拟机时间同步？
即使未打开周期性时间同步，虚拟机有时也会与主机同步时间。若要完全禁⽤时间同步，必须编辑虚拟机的配置⽂件（vmx ⽂件），并将某些同步属性设置为 FALSE。
toolssyncTime = 'FALSE' 是否定期同步
timesynchronizecontinue = 'FALSE' 是否快照后同步
timesynchronizerestore = 'FALSE' 是否快照恢复后同步
timesynchronizeresumedisk = 'FALSE' 是否在从挂起恢复并使⽤VMware VMotion
特性迁移到新主机后同步。
timesynchronizeshrink = 'FALSE' 是否在整理虚拟磁盘碎⽚后同步
timesynchronizetoolsstartup = 'FALSE' 是否在⼯具守护进程启动时同步，通常在
客户 *** 作系统启动时同步。
*** 作系统内禁⽤时间同步
总结
有时候我们在虚拟机安装完 *** 作系统后，往往漏掉⼀些配置，例如：VMware Tools未安装、 *** 作系统时间是否同步⽹络NTP或者关闭时间⽹络同步⽽去同步主机时间等。我们需要根据实际情况，选择⼀种⽐较适合⾃⼰环境的时间同步⽅式，从⽽保证系统及应⽤程序的稳定运⾏。
￥
5
百度文库VIP限时优惠现在开通,立享6亿+VIP内容
立即获取
VMware虚拟机时间总是异常？简单两步彻底解决此问题
VMware虚拟机时间总是异常？简单两步彻底解决此问题
系统时间问题看似很⼩，但是对于⼀些时效性要求较⾼的业务系统，例如：考试系统、实时监
控系统等，时间问题影响甚⼤。我们在实际⽣产中也遇到⼀台虚拟机安装的Windows Server系
统（ *** 作系统时间同步NTP，未配置同步主机）由于系统时间异常导致应⽤服务出现问题。
第 1 页
*** 作系统时间同步
Windows：Windows *** 作系统直接把CMOS时间认定为当前显⽰时间，不根据时区转换。这样
每调整⼀次系统时区，系统会根据调整的时区来计算当前时间，确定后，也就同时修改了
CMOS内的时间。
Linux：Linux和苹果 *** 作系统以当前主板CMOS内时间做为格林威治标准时间，再根据系统设置
第 2 页
的时区来最终确定当前系统时间Kafka在⼀定数量的服务器上对主题分区进⾏复制。
当集群中的⼀个broker宕机后系统可以⾃动故障转移到其他可⽤的副本上，不会造成数据丢失。
--replication-factor 3 1leader+2follower
Follower分区像普通的Kafka消费者⼀样，消费来⾃Leader分区的消息，并将其持久化到⾃⼰的⽇志中。
允许Follower对⽇志条⽬拉取进⾏批处理。
同步节点定义：
下图中
分区P1的Leader是0，ISR是0和1
分区P2的Leader是2，ISR是1和2
分区P3的Leader是1，ISR是0，1，2。
⽣产者和消费者的请求都由Leader副本来处理。Follower副本只负责消费Leader副本的数据和Leader保持同步。
对于P1，如果0宕机会发⽣什么？
Leader副本和Follower副本之间的关系并不是固定不变的，在Leader所在的broker发⽣故障的时候，就需要进⾏
分区的Leader副本和Follower副本之间的切换，需要选举Leader副本。
如何选举？
如果某个分区所在的服务器除了问题，不可⽤，kafka会从该分区的其他的副本中选择⼀个作为新的Leader。之后
所有的读写就会转移到这个新的Leader上。现在的问题是应当选择哪个作为新的Leader。
只有那些跟Leader保持同步的Follower才应该被选作新的Leader。
Kafka会在Zookeeper上针对每个Topic维护⼀个称为ISR（in-sync replica，已同步的副本）的集合，该集合中是
⼀些分区的副本。
只有当这些副本都跟Leader中的副本同步了之后，kafka才会认为消息已提交，并反馈给消息的⽣产者。
如果这个集合有增减，kafka会更新zookeeper上的记录。
如果某个分区的Leader不可⽤，Kafka就会从ISR集合中选择⼀个副本作为新的Leader。
显然通过ISR，kafka需要的冗余度较低，可以容忍的失败数⽐较⾼。
假设某个topic有N+1个副本，kafka可以容忍N个服务器不可⽤。
为什么不⽤少数服从多数的⽅法
少数服从多数是⼀种⽐较常⻅的⼀致性算发和Leader选举法。
它的含义是只有超过半数的副本同步了，系统才会认为数据已同步；
选择Leader时也是从超过半数的同步的副本中选择。
这种算法需要较⾼的冗余度，跟Kafka⽐起来，浪费资源。
譬如只允许⼀台机器失败，需要有三个副本；⽽如果只容忍两台机器失败，则需要五个副本。
⽽kafka的ISR集合⽅法，分别只需要两个和三个副本。
如果所有的ISR副本都失败了怎么办？
此时有两种⽅法可选，
向已经部署好的Kafka集群⾥⾯添加机器，我们需要从已经部署好的Kafka节点中复制相应的配置⽂件，然后把⾥
⾯的broker id修改成全局唯⼀的，最后启动这个节点即可将它加⼊到现有Kafka集群中。
问题：新添加的Kafka节点并不会⾃动地分配数据，⽆法分担集群的负载，除⾮我们新建⼀个topic。
需要⼿动将部分分区移到新添加的Kafka节点上，Kafka内部提供了相关的⼯具来重新分布某个topic的分区。
在重新分布topic分区之前，我们先来看看现在topic的各个分区的分布位置：
在node11搭建Kafka：
拷⻉JDK并安装
此处不需要zookeeper，切记！！！
让配置⽣效：
/etc/profile
拷⻉node1上安装的Kafka
修改node11上Kafka的配置：
启动Kafka：
注意观察node11上节点启动的时候的ClusterId，看和zookeeper节点上的ClusterId是否⼀致，如果是，证明node11和node1在同⼀个集群中。
node11启动的Cluster ID：
zookeeper节点上的Cluster ID：
然后使⽤ kafka-reassign-partitionssh ⼯具⽣成reassign plan
Proposed partition reassignment configuration下⾯⽣成的就是将分区重新分布到broker 1上的结果。我们将这些内容保存到名为resultjson⽂件⾥⾯（⽂件名不重要，⽂件格式也不⼀定要以json为结尾，只要保证内容是json即可），然后执⾏这些reassign plan：
执⾏计划：
这样Kafka就在执⾏reassign plan，我们可以校验reassign plan是否执⾏完成：
查看主题的细节：
分区的分布的确和 *** 作之前不⼀样了，broker 1上已经有分区分布上去了。使⽤ kafka-reassign�partitionssh ⼯具⽣成的reassign plan只是⼀个建议，⽅便⼤家⽽已。其实我们⾃⼰完全可以编辑⼀个reassignplan，然后执⾏它，如下：
将上⾯的json数据⽂件保存到my-topics-to-executejson⽂件中，然后也是执⾏它：
等这个reassign plan执⾏完，我们再来看看分区的分布：
我们可以在新建主题的时候，⼿动指定主题各个Leader分区以及Follower分区的分配情况，即什么分区副本在哪
个broker节点上。
随着系统的运⾏，broker的宕机重启，会引发Leader分区和Follower分区的⻆⾊转换，最后可能Leader⼤部分都
集中在少数⼏台broker上，由于Leader负责客户端的读写 *** 作，此时集中Leader分区的少数⼏台服务器的⽹络I/O，
CPU，以及内存都会很紧张。
Leader和Follower的⻆⾊转换会引起Leader副本在集群中分布的不均衡，此时我们需要⼀种⼿段，让Leader的分
布重新恢复到⼀个均衡的状态。
执⾏脚本：
上述脚本执⾏的结果是：创建了主题tp_demo_03，有三个分区，每个分区两个副本，Leader副本在列表中第⼀个指定的brokerId上，Follower副本在随后指定的brokerId上。
然后模拟broker0宕机的情况：
是否有⼀种⽅式，可以让Kafka⾃动帮我们进⾏修改？改为初始的副本分配？
此时，⽤到了Kafka提供的⾃动再均衡脚本： kafka-preferred-replica-electionsh
先看介绍：
该⼯具会让每个分区的Leader副本分配在合适的位置，让Leader分区和Follower分区在服务器之间均衡分配。
如果该脚本仅指定zookeeper地址，则会对集群中所有的主题进⾏ *** 作，⾃动再平衡。
具体 *** 作：
执⾏ *** 作：
查看 *** 作的结果：
恢复到最初的分配情况。
之所以是这样的分配，是因为我们在创建主题的时候：
在逗号分割的每个数值对中排在前⾯的是Leader分区，后⾯的是副本分区。那么所谓的preferred replica，就是排在前⾯的数字就是Leader副本应该在的brokerId。
实际项目中，我们可能由于主题的副本因子设置的问题，需要重新设置副本因子。
或者由于集群的扩展，需要重新设置副本因子。
topic⼀旦使用又不能轻易删除重建，因此动态增加副本因子就成为最终的选择。
说明：kafka 10版本配置⽂件默认没有defaultreplicationfactor=x， 因此如果创建topic时，不指定–replication-factor 想， 默认副本因⼦为1 我们可以在⾃⼰的 serverproperties 中配置上常⽤的副本因⼦，省去⼿动调整。例如设置defaultreplicationfactor=3， 详细内容可参考官⽅⽂档 >gaussdb数据库参数说明版本和平台兼容性14
1 历史版本兼容性
数据库系统的向后兼容性能够为对旧版本的数据库应⽤提供⽀持。
array_nulls
参数说明：控制数组输⼊解析器是否将未⽤引⽤的 NULL 识别为数组的⼀个 NULL 元素。
取值范围：布尔型
on 表⽰允许向数组中输⼊空元素。但 PostgreSQL 82 之前的版本不⽀持这么做，因此将把 NULL 当作字符串 “NULL” 。
off 表⽰向下兼容旧式模式。仍然能够创建包含 NULL 值的数组。
默认值：on
backslash_quote
参数说明：控制字符串⽂本中的单引号是否能够⽤ \’ 表⽰。
符合 SQL 标准的写法是将其双写（’’），之前版本的 PostgreSQL 允许使⽤\’ 表⽰。但是使⽤ ’ 容易导致安全漏洞，因为存在某些多字节字符集中的最后⼀个字节与 \ 的 ASCII 值相等。服务器拒绝带有反斜杠转义的查询可以预防这种风险。
注意：
在字符串⽂本符合 SQL 标准的情况下，\ 没有任何其他含义。这个参数影响的是如何处理不符合标准的字符串⽂本，包括明确的字符串转义语法是（E’…’）。
取值范围：枚举类型
on 表⽰⼀直允许使⽤ \’ 表⽰。
off 表⽰拒绝使⽤ \’ 表⽰。
safe_encoding 表⽰仅在客户端字符集编码不会在多字节字符末尾包含 \ 的 ASCII 值时允许。
默认值：safe_encoding
default_with_oids
参数说明：在没有声明 WITH OIDS 和 WITHOUT OIDS 的情况下，这个选项控制在新创建的表中 CREATE TABLE 和 CREATE TABLE AS 是否包含⼀个 OID 字段。它还决定 SELECT INTO 创建的表⾥⾯是否包含 OID 。
不推荐在⽤户表中使⽤ OID ，故默认设置为 off。需要带有 OID 字段的表应该在创建时声明 WITH OIDS 。
取值范围：枚举类型
说明：
在 PostgreSQL 81 之后 default_with_oids 缺省为由 on 改为 off 。
默认值：off
escape_string_warning
参数说明：警告在普通字符串中直接使⽤反斜杠转义。
如果需要使⽤反斜杠作为转义，可以调整为使⽤转义字符串语法(E’…’)来做转义，因为在每个 SQL 标准中，普通字符串的默认⾏为现在将反斜杠作为⼀个普通字符。
这个变量可以帮助定位需要改变的代码。
取值范围：布尔型
默认值：on
lo_compat_privileges
参数说明：控制是否启动对⼤对象权限检查的向后兼容模式。
取值范围：布尔型
on 表⽰当读取或修改⼤对象时禁⽤权限检查，与PostgreSQL 90 以前的版本兼容。
默认值：off
quote_all_identifiers
参数说明：当数据库⽣成 SQL 时，此选项强制引⽤所有的标识符（包括⾮关键字）。这将影响到 EXPLAN 的输出及函数的结果，例如pg_get_viewdef。 详细说明请参见 gs_dump 的 --quote-all-identifiers 选项。
取值范围：布尔型
默认值：off
sql_inheritance
参数说明：控制继承语义。
取值范围：布尔型
off 表⽰各种命令不能访问⼦表，即默认使⽤ ONLY 关键字。这是为了兼容 71 之前版本⽽设置的。
默认值：on
standard_conforming_strings
参数说明：控制普通字符串⽂本（’…’）中是否按照 SQL 标准把反斜扛当普通⽂本。
应⽤程序通过检查这个参数可以判断字符串⽂本的处理⽅式。
建议明确使⽤转义字符串语法（E’…’）来转义字符。
取值范围：布尔型
说明：
从 PostgreSQL 91 版本开始，默认值改为由 off 改为 on。
默认值：on
synchronize_seqscans
参数说明：控制启动同步的顺序扫描。在⼤约相同的时间内并⾏扫描读取相同的数据块，共享 I/O 负载。
取值范围：布尔型
on 表⽰扫描可能从表的中间开始，然后选择"环绕"⽅式来覆盖所有的⾏，为了与已经在进⾏中的扫描活动同步。这可能会造成没有⽤ORDER BY ⼦句的查询得到⾏排序造成不可预测的后果。
off 表⽰确保 PostgreSQL 83 之前的版本的顺序扫描是从表头开始的。
默认值 ：on
2 平台和客户端兼容性
transform_null_equals
参数说明：控制表达式expr = NULL（或 NULL = expr）当做expr IS NULL处理。如果expr得出NULL值则返回真，否则返回假。
正确的SQL标准兼容的expr = NULL总是返回NULL（未知）。
Microsoft Access⾥的过滤表单⽣成的查询使⽤expr = NULL来测试空值。打开这个选项，可以使⽤该接⼝来访问数据库。
注意：
这个选项只影响 = NULL精确形式，不包括其他⽐较 *** 作符或者其他与⼀些涉及等号 *** 作符的表达式计算（⽐如 IN）。
取值范围：布尔型
默认值：off，新⽤户经常在涉及NULL的表达式上语义混淆，故默认值设为off。
is_equal_nullstring_and_nullvalues
参数说明：控制空字符串’'与空值NULL是否等价。
on表⽰SQL语句中的空字符串’'在语法分析阶段会被当做空值NULL来处理。
off表⽰空字符串’'不会被当做NULL来处理。
说明：
当sql_format=mysql时，空字符串’'也不会被当做NULL来处理。⼆者是"或"的关系，即只要满⾜前⾯任何⼀个条件，空字符串都与NULL不等价。
取值范围：布尔型
默认值：on，即空字符串与NULL是等价的。
sql_format
参数说明：控制数据库的SQL语法和语句⾏为同哪⼀个主流数据库兼容。
oracle表⽰同oracle兼容。
mysql表⽰同mysql兼容。
取值范围：枚举型
默认值：oracle
￥
59
百度文库VIP限时优惠现在开通,立享6亿+VIP内容
立即获取
gaussdb数据库参数说明版本和平台兼容性14
gaussdb数据库参数说明版本和平台兼容性14
1 历史版本兼容性
数据库系统的向后兼容性能够为对旧版本的数据库应⽤提供⽀持。
array_nulls
参数说明：控制数组输⼊解析器是否将未⽤引⽤的 NULL 识别为数组的⼀个 NULL 元素。
取值范围：布尔型
on 表⽰允许向数组中输⼊空元素。但 PostgreSQL 82 之前的版本不⽀持这么做，因此将把 NULL 当作字符串 “NULL” 。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）