非频繁更新实时表，主要做数据导入与查询业务，可以根据客户业务设置合理的TTL时间。比如客户业务会频繁访问最近半天的数据，则可以设置TTL时间为0.5天。频繁更新实时表，upsert业务比较频繁，可以根据需要做upsert的时间范围给表增加TTL时间，提升upsert操作的性能。设置过期时间时也根据客户具体的业务确定，如果主要对近两天导入的数据进行upsert，可将过期时间设置为2天。为什么我通过du、ls命令看到的 disk cache 目录占用的空间远大于我实际的数据量？disk cache 的磁盘占用空间代表的是历史上的最高水位，和当前实际缓存的数据量并没有关系，假设导入了100G的数据，之后进行了upsert等业务，数据量变成了200G，然后之后进行了vacuum，数据量变成了100G，那么 disk cache 的磁盘占用空间仍然会保持在最高水位200G，但是 disk cache 内部的实际缓存数据量会是100G。失效数据的去清理需要将整个disk cache用满后触发LRU淘汰策略。

cache policy选项可以在执⾏create table或者alter table语句时设置成NONE，之后获取表中的数据，所有数据都会被冷缓存。cache policy选项可以在执⾏create table或者alter table语句时设置成ALL，之后获取表中的数据，所有数据都会被热缓存。在建表时，设置相应的表级参数，即可将该表的数据使用 TTL 策略进行缓存。disk_cache_ttl：新导入的数据期望在缓存中保留的时间，参数的类型为interval，最小值为"1 second"、最大值为 “100 years”。备注：修改后的 TTL 值不会对已经在缓存中的数据生效，仅对后续进入缓存的数据有效。如果在建表时没有设置 TTL，用户同样可以通过执行 ALTER 语句来修改表的 TTL 属性。     3.维度表，数据量较小、变动不大，但是访问频繁，可以设置较长的TTL时间，例如1年，避免查询大表数据时被替换出缓存，以确保其数据在一年内都能被快速访问。  

HPN(HOT PARTITION NUMBER)cache policy选项可以在执⾏create table或者alter table语句时设置成HPN : N，⽤户需要提供⼀个数字N(N >= -1600 && N <= 1600)，之后获取表中的数据，更晚创建的N个分区中的数据会被热缓存，其余分区会被冷缓存。当N等于0时，所有分区中的数据都会被冷缓存。HPN只对V3表中的range分区表和list分区表生效。HPL(HOT PARTITION LIST)cache policy选项可以在执⾏create table或者alter table语句时设置成HPL : , , …，⽤户需要提供意图指定成热分区的分区名，之后获取表中的数据，热分区中的 数据会被热缓存，⽽其余分区中的数据则会被冷缓存。HPL只对V3表中的range分区表和list分区表⽣效。HPL只对V3表中的range分区表和list分区表生效。 

在存算分离模式下，GaussDB(DWS)支持搭建跨VW集群，各VW间共享数据但不共享缓存。新的VW创建时，其缓存为空，可能影响查询性能。为此，GaussDB(DWS) 提供缓存预热功能，允许用户从远端存储主动拉取数据至本地缓存。该功能支持以下两种模式：表数据预热：预热指定表 A 的数据。warmup信息解读：Read Cache Size : 从磁盘缓存中读取的数据sizeWrite Cache Size : 从OBS读到本地缓存的数据sizeAvg Write Cache time : OBS请求的平均执行时间对于3.0表，由于数据的实际存储位置位于OBS，增强了sql语句级别的对OBS读写请求统计信息的监控，辅助定位特定sql慢。可以通过topsql以及explain performance 查看特定语句的obs读写统计信息。当前云上的集群的磁盘缓存默认是打开的，即对所有v3表的访问都会使用到磁盘缓存。可以通过以下方式检查当前集群的磁盘缓存是否打开：DN上执行"show enable_aio_scheduler; show obs_worker_pool_size"；确保enable_aio_scheduler=on, obs_worker_pool_size >=4;CN上执行"show enable_disk_cache"，确保enable_disk_cache=on上述两点必须同时满足。

对于云上环境，对不同云盘的访问会走不同的网卡，因此不同云盘的带宽是可以叠加的。在有多块云盘（EVS）的情况下，GaussDB(DWS)支持设置多块盘作为缓存的路径，尽可能将 cache 文件分散在不同云盘上以提升缓存访问的性能。为了提升集群正常时主DN的性能并充分利用节点上的磁盘空间，目前会默认使用主备两块硬盘作为当前节点上主DN缓存介质，通过查询以下参数查看相关信息：通过 disk_cache_base_paths 参数查看和增减缓存硬盘路径，举例某个节点上的目录配置，实例名为h10dn1：主DN多盘缓存路径默认如下：路径1：/DWS/data1/h10dn1/primary0/disk_cache路径2：/DWS/data2/h9dn1/primary0_disk_cache备DN多盘缓存路径默认如下：路径：/DWS/data2/h9dn1/secondry/disk_cache备机的多盘缓存路径与当前节点上主DN的缓存路径2在同一块盘上，因此限制备机升主后的磁盘缓存空间最大为1GB，性能对比切换前会有较大劣化，需要尽快修复集群至均衡状态。

A0队列可使用的缓存空间固定为1GB， TTL 队列和LRU - 2Q队列共同使用由GUC参数 disk_cache_max_size 设置的缓存空间，初始状态时缓存空间都给LRU - 2Q使用，在后续访问到设置TTL属性的数据或者TTL中有大量数据过期时，会动态调整TTL队列与LRU - 2Q队列的比例关系，以充分利用缓存空间，TTL所使用缓存空间的最大比例不超过 disk_cache_ttl_max_ratio。TTL过期淘汰当有新的数据进入TTL队列时，会将部分已经过期的数据淘汰至LRU - 2Q队列。后台线程会定期清理TTL中已过期的数据，并淘汰至LRU - 2Q队列。TTL自身LRU淘汰当TTL空间使用达到上限，且没有过期的数据时，会触发自身的LRU淘汰策略，被淘汰出去的数据会进入LRU - 2Q队列。TTL主动淘汰当用户删除设置了过期时间的表数据时，后台线程会定期清理TTL中无效的数据。当有新的数据插入且当前LRU空间使用达到上限，会触发自身的LRU淘汰策略，被淘汰出去的数据会被清除缓存。当TTL队列空间不足，但未到达上限，会抢占LRU - 2Q队列的空间。如果LRU - 2Q的空间已满，也会触发自身的LRU淘汰。LRU - 2Q主动淘汰当用户删除设置了过期时间的表数据时，后台线程会定期清理LRU - 2Q中无效的数据。

TTL 策略确保新导入的数据在缓存中保留一段时间不被淘汰。在这段时间内，数据具有最高优先级，且所有 TTL 数据之间地位平等，不会因为某些数据即将过期而被提前淘汰。当TTL缓存空间不足时，会尝试抢占LRU队列的空间，以确保 TTL 数据能够被写入，TTL队列最大可使用的空间由guc参数disk_cache_ttl_max_ratio 控制，默认值是0.5，即整个缓存空间的一半。当TTL队列的缓存空间到达上限后，如果仍然有新的数据要进入TTL队列，此时会触发TTL队列自身的LRU淘汰，被淘汰的数据将进入到LRU空间中。应用场景：TTL 策略特别适用于希望在本地持久化的小规模数据表。对于常驻表，可以设置较长的 TTL 值来保护其数据；对于实时表，可以根据热数据的活跃时间设定相应的 TTL 值。GaussDB(DWS) 采用基于 LRU 的多队列策略，根据 TTL 属性及冷热属性将数据分为三类，分别置于 TTL 队列、LRU - 2Q队列、A0 队列中。设置了 TTL 属性的热数据被放置到 TTL 队列，没有设置 TTL 属性的热数据被放置到 LRU - 2Q队列，冷数据都放置到A0队列中。在数据读取和写入过程中，GaussDB(DWS) 会地选择填充和读取的队列，以最大化缓存利用率。 

云计算时代下的存算分离架构将计算和存储解耦，存、算、元数据分离成为趋势，将大量用户数据存放在云端存储。在此背景下，需要频繁地同OBS云端存储进行读写交互，为了尽可能的提升云上数据的处理速度，GaussDB(DWS)通过利用本地硬盘上的缓存来加速数据访问，并采用了一种先进的多队列 LRU（Least Recently Used）策略来高效管理缓存空间。针对跨VW的应用场景，DWS 还提供了缓存预热功能，以便在弹性VW建立时，能够迅速加载特定数据（如表或分区）到缓存中，从而提升查询性能。LRU 通过维护一个数据访问队列来管理缓存。当数据被访问时，该数据会被移动到队列的前端。新加入缓存的数据同样会被置于队列前端，以防止其过早被淘汰。当缓存空间达到上限时，队列尾部的数据将优先被移除。GaussDB(DWS) 通过引入LRU-2Q算法，优化了LRU的缓存污染问题，确保了核心业务的热数据不会因为访问大量历史数据而被冲刷出缓存。

dws怎么获取分布式表结构呢

我们来看下字段随意定义导致的严重资源消耗问题。   一、存储空间差异实际存储：varchar仅存储实际字符长度+1/2字节长度标识，存储相同内容时两者占用空间相同。如存储10字符数据时，两者均占用11-12字节。潜在扩展影响‌：当数据接近定义长度上限时，varchar(2000)可能比varchar(50)多消耗约40倍存储空间（按最大长度计算）。 二、性能影响索引效率‌： 过长的varchar定义（如2000）会导致索引键值变大，降低B-tree索引的节点密度，增加IO操作次数。内存消耗‌：  排序操作（如ORDER BY）时会按定义长度分配内存，而非实际数据长度，varchar(2000)比varchar(50)实际多消耗40倍内存。查询优化器‌：优化器可能因字段长度定义过大而错误估算内存需求，影响执行计划选择。 我们有时候不清楚资源消耗在哪里，为什么这么小的表，消耗内存会这么大，分析系统中  ORDER BY ,  GROUP BY 是家常便饭，定义region_name 为100 和 定义它为 2000,  内存消耗就相差 20 倍， 也许是为了后续不用更改长度，一劳永逸，也许就是全字段皆 2000 ，懒得设计，敏捷的不能再敏捷   。 但上线后， 运行态并发一来，各种排队或资源不足  。 不止ORDER BY , GROUP BY存在这种问题，其他算子有些也存在类似问题。    三、设计规范问题数据完整性‌： 随意使用varchar(5000)会丧失字段长度的约束作用，可能导致存储非预期数据  。资源浪费‌：  定义远大于实际需求的长度会浪费内存池资源，尤其在MPP架构下会影响并行计算效率。      四、不建议随意定义varchar长度的原因行存储限制‌：DWS中单行数据总长度受页大小限制（默认8KB），多个varchar(5000)字段易触发行溢出。维护困难‌：    过大的长度定义会掩盖真实业务需求，增加后续schema优化的复杂度。 建议根据实际业务需求精确设定长度，通常预留20%-50%的扩展余量即可。对于不确定长度的字段，可先采用适中的长度（如varchar(255)），后续通过ALTER TABLE调整。记得Oracle时代，各种评审单位都会对生产上线的表定义，长度，合理性进行评审。   现在是敏捷了， 但是问题却从设计，开发逐步转移到了后端运维  。成本不会消失，只是转移 。  目前只能靠更多的机器堆砌扩容和持续的整改优化来弥补设计上的缺失  。稳定性左移貌似落地太慢 。转载--原作者王琦

一个字符串长度为30，给这个字段设置varchar(50) 和varchar(5000) 有区别吗？插入的时候，占用的空间一样吗？查询的时候，效率一样吗？

TopSQL注意事项cid:link_3记录函数入口语句cid:link_4JDBC执行的带占位符语句cid:link_5operator_realtime级别TopSQL运行监控cid:link_6query_plan原理cid:link_0算子级TopSQL监控cid:link_7TopSQL与其他视图交互cid:link_8TopSQL原理介绍cid:link_9sql_hsah信息cid:link_1数据库弹性扩缩容降本增效cid:link_10弹性资源池cid:link_11手动弹性cid:link_12手动弹性VW的使用方式cid:link_2DDL设置cid:link_13路由策略https://bbs.huaweicloud.com/forum/thread-0208194605946543211-1-1.html

我们支持的路由策略有三种：路由策略none：主VW作业不会卸载到弹性VW上；路由策略dedicated：主VW作业可以卸载专用弹性VW；路由策略elastic：主VW作业可以卸载到专用和公用弹性VW。我们仍然以数据中台团队为例，介绍比例路由方式的案例。数据中台业务用户user1绑定主VW matedata_group1，user2绑定主VW matedata_group2。两个用户提交的作业既包含ETL负载，也包括一些DML业务处理负载。在每日的凌晨12点到6点，ETL负载变高。团队通过在“集群详情”页面中执行“添加增删计划”，设置周期性增删计划。周期类型选择每星期，时间调度计划添加7项，每项对应一周的一天，并设置创建完成时间为凌晨12点，删除时间为凌晨6点。绑定主逻辑集群选项卡设置为matedata_group1，集群名称设置为compute_group1。matedata_group1的60%作业卸载到专用弹性VW compute_group1执行。后续团队发现，由于user1提交的作业负载太高，一个弹性VW仍然不能满足需求，而且，user2提交的作业负载也需要卸载一部分到弹性VW执行。但是出于经济成本考量，在额外新建2个弹性VW成本很高。最好的方式是新建一个弹性VW，新建的弹性VW能够处理user1和user2的作业。此时，团队可以选择elastic路由策略。

在凌晨12点到6点，这两个用户将会提交大量的数据导入负载，如果完全在主VW执行，将会花费大量时间，影响其他业务执行。数据中台团队可以在“集群详情”页面中执行“添加增删计划”，设置周期性增删计划。周期类型选择每星期，时间调度计划添加7项，每项对应一周的一天，并设置创建完成时间为凌晨12点，删除时间为凌晨6点。绑定用户选项卡设置user1，集群名称设置为compute_group1，设置完成后，在每日的凌晨12点到6点，user1提交的所有作业将会到新建立的弹性逻辑集群 compute_group1执行。而user2提交的作业仍然在原有的metadata_group执行。如果避免ETL业务影响其他业务执行，团队想将user2提交的作业也到弹性VW执行（即增加用户与已经创建出来的弹性VW的绑定关系），可以手动执行DDL，将多个用户绑定到同一个弹性VW上。无需绑定用户，手动弹性VW创建完成后，用户通过DDL设置主VW的作业路由策略和路由比例，内核自动会将作业按照比例分配到主VW和弹性VW上。

客户提交的作业具体到哪个VW执行，依赖于创建时的配置。具体来说：如果在创建时勾选了绑定具体的用户，则作业将会以用户绑定方式路由。如果在创建时勾选了绑定主逻辑集群，我们将这种配置创建出来的弹性VW称之为专用弹性VW。内核以比例路由方式将所绑定的主VW的作业路由到专用弹性VW，即专用弹性VW只会接受来自绑定的主VW的作业。如果在创建时绑定用户和绑定主逻辑集群均没有选择，我们将这种配置创建出来的弹性VW称之为公用弹性VW。内核以比例路由方式将主VW的作业路由到公用弹性VW，即公用弹性VW可以接受来自集群内所有主VW的作业。总结来说，手动弹性VW的作业路由方式主要分为两种：用户绑定方式和比例路由方式。公司的数据中台团队在每天的凌晨12点到6点执行ETL，完成大数据量的离线导入。团队使用不同的用户账户执行ETL，由于凌晨12点到6点的ETL负载变高，我们可以创建新的弹性VW消费突发的负载，并以用户绑定方式实现不同用户间的ETL负载隔离。具体来说，用户user1和user2，他们分别负载导入不同业务模块的数据。