DWS jdbc 代码执行sql，连接中断，但是在业务端任务没有停，这种有没有客户端参数能控制超时停止？在连接串中加SocketTimeout参数测了没效果应该是不支持  

analyze莫名其妙变慢了咋办？将军莫虑，且看此贴~ 直接上干货，常见的analyze慢有这几种情况：    1 . 锁冲突有现场的情况，锁冲突可以用如下语句排查，若对端语句不重要，则可以将对端语句查杀。SELECT * FROM pgxc_lock_conflicts order by xactstart;查杀语句方法，按实际填写实例名和pid：execute direct on (cn_5001) 'select pg_terminate_backend(140026797549312)';通常，手动analyze会持有4级锁，若持锁对端为非8级锁，821.2版本以上，则可以用light模式进行analyze，light的analyze只会持1级锁，这样就不会锁冲突了。analyze (light) 模式名.表名;    2 . 修改过analyze采样率默认情况下，analyze只会采样3万行，但因为对于大表而言，3w行的采样可能不够，导致存在计划跳变的风险，我们可能会调大其采样率，此种情况analyze变慢是预期内的。查询当前默认采样率，正数为default_statistics_target * 300，负数为百分比采样。show default_statistics_target;查询表级设置的采样率，表级采样率会依托于表的某一列上，但会全表生效。SELECT c.oid::regclass::TEXT AS table_name, a.attname, CASE WHEN a.attstattarget > 0 THEN (a.attstattarget * 300)::TEXT WHEN a.attstattarget IS NULL THEN NULL ELSE ((a.attstattarget + 1) * (-1))::TEXT || '%' END AS STATISTICS FROM pg_class c LEFT JOIN pg_attribute a ON c.oid = a.attrelid AND a.attstattarget NOT IN (0, -1) WHERE c.relname IN ('表名') ORDER BY 1, 2;表级还原默认采样率方法：ALTER TABLE 模式名.表名 ALTER 列名 SET STATISTICS 200;    3 . 使用临时表模式采样analyze执行时会分为内存模式和临时表模式，临时表模式会将表的每一列的采样数据插入临时表，并且通过内部生成的sql计算统计信息，临时表模式会比内存模式慢。临时表模式采样日志中会打印：Delete object ， calc stats in sample table 关键字通常有三种情况会导致使用临时表模式：① 参数analyze_stats_mode强制指定了sample_table模式show analyze_stats_mode;② 采样率高，且表较大，导致预估内存超过maintenance_work_mem，则会采用临时表模式。如果表大小和采样率都是预期内的，则慢也是预期内的。③ 使用了多列统计信息，对于表中多个列有相关性且查询中有同时基于这些列的条件或分组操作的情况，可尝试收集多列统计信息。但如果收集多列统计信息，analyze会强制走临时表模式。如果业务上没有收集多列统计信息的需求，可以考虑删除。查询多列统计信息：select * from PG_EXT_STATS where schemaname = '模式名' and tablename = '表名';根据查询到的结果删除多列统计信息：ALTER TABLE tablename DELETE STATISTICS ((column_1, column_2));    4 . 环境因素影响集群的cpu和io状况等环境因素，也会影响analyze性能，可以排查当时的性能监控。 参考文献：一文读懂analyze使用【这次高斯不是数学家】更新统计信息 

具身智能技术未来发展趋势如何？

使用关键词进行查询过滤cid:link_0使用语句归一化特征值进行查询过滤cid:link_5异常熔断应用cid:link_1拦截记录cid:link_6查询过滤器cid:link_7查询过滤规则元数据管理cid:link_8GB18030编码cid:link_9数据库创建最佳实践cid:link_10WeTune产品的项目背景cid:link_11WeTune改写规则的自动挖掘实现cid:link_2WeTune 2.0在华为云GaussDB的落地cid:link_3如何解决引入大量规则之后产生的性能问题cid:link_12WeTune在数据库产业的价值及未来前景cid:link_4增量计算的背景cid:link_13数据库服务API揭秘与实践探索https://bbs.huaweicloud.com/forum/thread-0293202571662365157-1-1.html 

API，即应用程序接口，可以看作是一组编程语言的函数和方法，它定义了软件系统中组件之间的交互方式，允许不同的软件之间进行数据通信和功能交互。那么，在什么场景下适合使用API接口，能实现什么效果？ 通过API允许用户调用华为云的能力，将华为云的数据和功能集成到用户的数据库管理系统中。 例如，用户在采用华为云数据库服务的同时，亦拥有自建的本地IT管理中心。他们既可利用云上资源，又掌握本地机房设施。在此背景下，用户可通过调用数据库实例查询接口，将数据库资源整合至自身的IT资源管理系统中，从而在一个集成看板上实现对多地IT资源的统一管理。 在快速入门数据库API接口之前，需要了解API接口的组成部分，如请求URL、请求方法、请求消息头和请求消息体；数据库服务API支持两种权限认证方式，分别是Token认证和AK/SK认证；API返回结果则包含状态码、响应消息头和消息体。 数据库服务的API提供了丰富的功能，在功能完备度上与华为云控制台是相同的。这也就意味着，在华为云页面上可以操作的功能，用户通过编程的方式都可以实现自动化控制。我们为每一个API提供了详细的说明，涵盖了鉴权方式、接口约束、请求体样例，响应体样例、错误码详解等，功能包括实例管理、备份管理、日志管理、任务管理等多个模块。

随着数智化时代的到来，数据量不断增长，为了充分挖掘数据价值，实时获取数据动态，GaussDB(DWS)通过与流引擎Flink结合，优化ETL Pipeline，从而数据分析时效实现T+0。 Flink是一款开源的流处理框架，它能够实时处理大规模数据流，并具有高可靠性和高性能的特点。Flink支持流式数据处理、批处理和图形处理等多种计算模式，并提供了丰富的API和工具，可以方便地进行数据处理和分析。GaussDB(DWS)与Flink结合构建下一代Stream Warehouse，实现增量计算，可以为用户提供更加全面、高效的数据处理和分析能力。 为什么需要增量计算能力？增量计算能力解决了哪些场景的痛点问题？ 高性能场景 一些需要高性能的典型场景如下： (1) 增量数据的实时ETL并更新物化视图，秒级更新； (2) 数据在仓湖之间实时流动能力； (3) 实时流数据不落盘，直达实时大屏。 数据入库场景 ：Kafka的数据直接入湖。

在数据库测试过程中，对于SQL的优化引擎，可以使用差分测试。差分测试是一种很经典的数据库测试方式，验证重写规则可以使用，验证SQL优化引擎过程中也适用。WeTune等价性验证器可以去枚举语义等价但形式完全不同的两条SQL，这样可以确保在测试对比过程中，程序运行是不一样的路径，可以更高效或覆盖面更广地完成数据库引擎的测试任务。 WeTune不仅减轻了数据库开发者或者DBA的负担，目前在教育领域里有一定的应用，WeTune等价性验证帮助国内外很多高校助教批改学生的数据库作业，减轻数据库教育工作者的工作压力。 华为与高校的深度合作将持续推进，融合双方的技术优势和科研力量，共同探索数据库领域的前沿技术，培养更多高水平的数据库人才。未来，华为和上海交通大学研究团队将携手，共同突破数据库查询重写技术的瓶颈，通过持续的创新和优化，进一步提升GaussDB的查询性能和效率。我们期待更多的技术合作和探索，推动数据库技术向智能化、自动化方向发展，为广大企业和用户带来更多价值。

从客户角度来讲，很多业务其实是相对比较固定的，而且上线之前也提前会做系统测试。若系统里面SQL优化度很高，那么就不必改写规则和暴力枚举，这样就可以降低优化成本。 在实际环境中，大家希望数据库有成千上万条的改写规则可以给用户去用，可以生成改写的SQL语句。但是，改写规则非常多的时候，会导致改写和规则匹配的时间非常长，导致资源的极大浪费，也会影响用户体验。那如何在性能上做加速呢？ 目前来讲，主要通过两方面来去解决： 一方面是从通用的匹配算法入手。当改写规则非常多的时候，匹配算法能够帮助性能有数量级的提升； 另一方面，从应用的场景或从SQL产生的源头来进行分类。不同应用场景下、不同业务目的、不同的框架需要的改写规则不一样，WeTune 2.0可以对于不同场景和需求来去做定制化的规则探索。WeTune是多个技术合起来形成了一个规则挖掘。从学术角度来讲，SQL等价性验证可以往数据库测试这个方向再迈一步。

WeTune和现有数据库应用落地过程中，不同的架构会面临不同挑战。WeTune 2.0在华为云GaussDB的落地，从技术角度来讲，GaussDB数据库是System-R架构，它的重写规则是耦合在代码里面，增加或卸载一个规则需要改写查询引擎。把WeTune应用在System-R架构上面涉及到理论、技术、工程层面的一些问题。不过，上海交通大学和华为的积极交流和深入探讨，也为彼此提供了不同的视角。 在数据库开发过程中，改写规则非常依赖人工经验。随着客户场景越来越多，很多规则已经超出了现有的承载能力。从产品开发流程层面上讲，想要在GaussDB里面添加一个新的重写规则，论证重写规则是否等价是非常困难的。但是有了WeTune以后，开发者只要按照形式化语言去描述重写规则，然后WeTune拿去做验证，证明该规则在约束下是等价的，就可以放心地将该重写规则添加到GaussDB中，节约验证时间，对GaussDB的开发等流程非常有帮助。 WeTune从框架上去解决了这两个重写规则是否等价的问题，这是WeTune非常突出的贡献点。对于客户来说，在使用GaussDB进行SQL优化时，只管放心用，优化交给GaussDB；对于开发者来说，只需要关心SQL语义，性能交给GaussDB。 GaussDB引入WeTune2.0以后，自然会产生非常多的规则，帮助用户优化SQL的同时，也引入了另外一个成本，即会产生了SQL优化代价。

WeTune 2.0在SQL等价性验证、枚举的能力和范围、规则的表达上都进行了精心设计，对GaussDB使用体验有极大提升。 第一，WeTune有验证规则的能力。对于开发流程来讲，验证规则是很重要的一步。 第二，WeTune有自动发现规则的能力。重写规则依赖人工、偏场景化会导致发现规则比较缓慢。WeTune可以帮助做优化，提高发现规则的效率。 第三，WeTune有自动枚举的能力。等价验证加上自动枚举，自动挖掘一次能够发现成千上万条规则，相当于把查询重写整个模块开发流程做了一个加速。对于一个商业的数据库来讲， WeTune自动挖掘可以减少开发人员冗余的规则添加，提高开发效率，降低人力成本。 第四，WeTune定义新的查询重写语言。WeTune应用在GaussDB数据库里，进行查询重写规则扩充的时候，其实定义了一种新的查询重写的语言。以前要写很多行的代码，才能给一套规则注入到引擎里面。现在不用写代码，只需要两三行的语言描述，通过规则验证后，直接放在数据库引擎里面，完成一个规则的实现。对开发者来说，体验非常好，对验证流程和开发流程帮助极大。

查询改写是数据库SQL优化过程中非常重要的部分，在语义不变的情况下，它可以把一条普通的或者性能不好的SQL语句优化成一条性能更好的SQL语句，实现查询效率的提升。改写规则作为查询改写中最关键的一个组件，想要在数据库里面添加改写规则，往往依赖于数据库专家经验的积累。如今，SQL语句的生成对象不再受限于程序员，外部框架和大模型也能够自动生成，随着生成源的增加，原来的SQL改写规则不再适用。自动挖掘的前提是暴力枚举，枚举之后检验语义是否正确，通过等价性验证去把最后一道关，所以，WeTune的等价性验证能力决定了它能够枚举哪些规则。下面是WeTune的改写规则的自动发掘方式： 方式一，尝试暴力枚举所有在语法上合法的改写规则； 方式二，用形式化验证的方式去验证枚举的规则是否正确（输入、输出的SQL是否在语义上等价）； 方式三，借鉴数据库cost estimation技术检验改写规则是否有效，SQL优化性能是否更好。 在实际运用中，以上改写规则的三种自动发掘方式也面临着一些现实层面的挑战。

LC_COLLATE：指定数据库使用的字符集。例如，gbk编码通过lc_collate=‘zh_CN.gbk’，utf8通过lc_collate=‘en_us.utf8’，gb18030/gb18030-2022通过lc_collate=‘zh_CN.GB18030’。该参数的使用会影响到对字符串的排序顺序，可以通过查pg_collate表找到对应编码的lc_collate。LC_CTYPE：指定新数据库使用的字符分类。例如，通过lc_ctype = 'zh_CN.gbk’设定该参数。该参数的使用会影响到字符的分类，如大写、小写和数字。默认是使用模板数据库的字符分类。ENCODING：指定数据库字符集DBCOMPATIBILITY：兼容Teradata语法 

解决gbk字符集的因为字符范围不足导致生僻字和少数民族文字无法识别满足《信息技术产品国家通用语言文字使用管理规定》强制要求多字节编码体系GB18030采用1/2/4字节变长编码结构：字节数编码范围字符类型1字节0x00-0x7FASCII兼容字符2字节0x81-0xFE 0x40-0x7E/0x80-0xFE基本汉字区(20902字)4字节0x81-0xFE 0x30-0x39 0x81-0xFE 0x30-0x39扩展区(70,000+汉字)各版本核心差异特性GB18030-2000GB18030-2005GB18030-2022汉字数量27,53370,24487,887支持Unicode版本3.04.011.0新增字符CJK扩展ACJK扩展BCJK扩展C-G少数民族文字基本支持增强支持完整支持部首支持无无228部首

查询过滤规则，可以通过DDL进行新增、删除或者修改，其语法如下：其中，block_name： 过滤规则的名称user_name： 规则应用的对象用户host： 是规则应用的客户端IPFOR： 语句类型，支持对UPDATE/SELECT/INSERT/DELETE/MEGE INTO五种类型语句进行限制FILTER BY： 过滤方法，包含两种形式SQL： 根据关键词对语句进行正则匹配，例如表名，其长度不能超过1024，建议尽量精简TEMPLATE：sql_hash：归一化的哈希值（md5），一般不会重复，相较unique_sql_id更推荐使用。unique_sql_id：归一化的64位哈希值，重复概率较sql_hash大一些。with_parameter： 查询过滤规则选项参数，可以附加多个条件，满足其一便会匹配过滤。application_name： 客户端名称query_band： 负载标识table_num： 包含的基表个数partition_num： 扫描分区的数量estimate_row： 基表输出行数resource_pool： 切换的目标资源池，仅适用于9.1.0.200及以上max_active_num： 可并发执行的语句个数，仅适用于9.1.0.200及以上is_warning： 改变拦截行为为告警，而非默认的报错，仅适用于9.1.0.200及以上

查询过滤器在9.1.0.100之前就具备提供查询过滤功能的能力，但仅支持自动隔离反复查询被终止的查询，防止烂SQL再次执行。老版本主要面向异常熔断机制和紧急拦截场景，前者可以与异常规则联动，自动将触发异常规则的语句添加到黑名单中，后者是需要手动找到core或者引发hang的语句进行屏蔽。9.1.0.100及9.1.0.200版本对查询过滤器做了功能的改进，可以通过多维度进行烂SQL识别，功能更丰富，配置更灵活。在业务开发过程中，要想禁止对2张以上的表进行关联查询，此时可以使用DDL语句创建过滤规则：table_num指的是一个语句中出现的表的个数，此时所有查询语句不能包含有两张表以上的查询。整体逻辑就非常清楚了。用户可以提前识别烂SQL的特征，然后抽象出来，用DDL语句创建规则，后续会对查询的语句进行过滤，被规则筛选出来的便是烂SQL，执行前会报错，反之则可以正常执行。