在作业开发页面“合作方数据”一栏可查看此联盟合作方共享的数据集。数据集第一级是合作方名称，第二级是数据集名称。SQL语句中用“合作方名.数据集名”表示一张表。SQL语法支持关键词：select 、from 、where 、inner join/join/left outer join/right outer join、group by 、order by、limit、on 、as、union all；逻辑表达式： <、 >、 = 、<= 、>=、 <>、 between and、 in、 like、 exists；运算符：+、-、*、/ 和 case when；数据类型：字符串、 整型、 浮点型、 decimal、日期(date)、 时间(timestamp)；聚合函数：max、min、sum、avg、count；系统函数：包含时间日期函数、字符串函数、数学函数。使用介绍如表1所示。通配符：%；--与like配合使用；编写SQL语句时，您可以参考编辑器右侧的“系统函数”，在SQL语句中输入并使用系统函数。表1 系统函数介绍系统函数类型函数命令格式命令说明参数说明返回值说明数学函数ABSint abs(int <number>)计算number的绝对值。number：必填。参数类型支持INT、BIGINT、FLOAT、DOUBLE、DECIMAL、STRING。如果输入为STRING类型，则隐式转换为DECIMAL类型后参与运算。输入为INT、BIGINT、FLOAT、DOUBLE、DECIMAL、STRING，则返回对应输入参数的数据类型。当输入非INT、BIGINT、FLOAT、DOUBLE、DECIMAL、STRING六种类型，返回报错。LNdouble ln(number)计算number的自然对数。number：必填。参数类型支持INT、BIGINT、FLOAT、DOUBLE、DECIMAL、STRING。如果输入为STRING类型，则隐式转换为DECIMAL类型后参与运算。当number为INT、BIGINT、FLOAT、DOUBLE、DECIMAL、STRING类型时返回DOUBLE类型。当number为负数或0时，返回报错。RANDdouble rand(seed)返回随机数，返回值区间是0~1。seed：选填。参数类型支持INT、BIGINT、FLOAT、DOUBLE、DECIMAL、STRING。如果输入为STRING类型，则隐式转换为DECIMAL类型后参与运算。返回DOUBLE类型。字符串操作函数CHAR_LENGTHint char_length(string)计算字符串string的长度。string：必填。参数类型为STRING类型。如果输入为非STRING类型，则隐式转换为STRING类型后参与运算。返回INT类型。CHARACTER_LENGTHint character_length(string)计算字符串string的长度。同CHAR_LENGTH。string：必填。参数类型为STRING类型。如果输入为非STRING类型，则隐式转换为STRING类型后参与运算。返回INT类型。LOWERstring lower(string)将字符串string中的大写字符转换为对应的小写字符。string：必填。参数类型为STRING类型。如果输入为非STRING类型，则隐式转换为STRING类型后参与运算。返回STRING类型。UPPERstring upper(string)将字符串string中的小写字符转换为对应的大写字符。string：必填。参数类型为STRING类型。如果输入为非STRING类型，则隐式转换为STRING类型后参与运算。返回STRING类型。SUBSTRINGstring substring(string from start[ for length])返回字符串string从start开始，长度为length的子串。string：必填。参数类型为STRING类型。如果输入为非STRING类型，则隐式转换为STRING类型后参与运算。start: 必填。参数类型为INT类型。起始位置为1（起始位置0作1处理）。当start为负数时，表示开始位置是从字符串的尾部向前倒数。length：选填。参数类型为INT类型。表示子串的长度。值必须大于0。返回STRING类型。时间日期函数YEARint year(date)返回日期date的年。date：必填。DATE或TIMESTAMP类型，格式为yyyy-mm-dd或yyyy-MM-dd HH:mm:ss。返回INT类型。date为非DATE或TIMESTAMP类型，返回报错。MONTHint month(date)返回日期date的月。date：必填。DATE或TIMESTAMP类型，格式为yyyy-mm-dd或yyyy-MM-dd HH:mm:ss。返回INT类型。date为非DATE或TIMESTAMP类型，返回报错。WEEKint week(date)返回日期date位于当年的第几周。date：必填。DATE或TIMESTAMP类型，格式为yyyy-mm-dd或yyyy-MM-dd HH:mm:ss。返回INT类型。date为非DATE或TIMESTAMP类型，返回报错。HOURint hour(date)返回日期date的小时部分的值。date：必填。DATE或TIMESTAMP类型，格式为yyyy-mm-dd或yyyy-MM-dd HH:mm:ss。返回INT类型。date为非DATE或TIMESTAMP类型，返回报错。MINUTEint minute(date)返回日期date的分钟部分的值。date：必填。DATE或TIMESTAMP类型，格式为yyyy-mm-dd或yyyy-MM-dd HH:mm:ss。返回INT类型。date为非DATE或TIMESTAMP类型，返回报错。SECONDint second(date)返回日期date的秒数部分的值。date：必填。DATE或TIMESTAMP类型，格式为yyyy-mm-dd或yyyy-MM-dd HH:mm:ss。返回INT类型。date为非DATE或TIMESTAMP类型，返回报错。SQL语句示例：SELECTcolumn_A--字段名是租户别名.数据集名.字段名column_B as alias--支持别名SUM(column_C) AS alias--支持针对列名的聚合函数cloumn_A + column_B*2 as alias--支持select中加计算式FROMpartner1.dataset1 table_A---表名是租户别名.数据集名, 后面可以加一个表别名tableAJOIN--支持的JOIN类型详见语法支持。partner2.dataset2 table_BONtable_A.ID = table_B.IDWHEREtable_A.uid = ${uid}GROUP BYtable_A.IDORDER BYtable_A.IDLIMIT${limit_count}SQL语句开发完成， 可点击页面上方“格式化”来对排版进行美化，完成后单击“保存”。图3 编写SQL语句

>摘要：一般都是设计联合索引，很少用单个字段做索引，因为还是要尽可能让索引数量少，避免磁盘占用太多，影响增删改性能。本文分享自华为云社区《[联合索引查询原理及生效规则](https://bbs.huaweicloud.com/blogs/332783?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者：JavaEdge。 一般都是设计联合索引，很少用单个字段做索引，因为还是要尽可能让索引数量少，避免磁盘占用太多，影响增删改性能。 有个表存储学生成绩，id是自增主键，包含学生班级、学生姓名、科目名称、成绩分数四个字段，平时查询，可能比较多的就是查找某个班的某个学生的某个科目的成绩。 所以，我们可以针对【学生班级，学生姓名，科目名称】建立一个联合索引。 有两个数据页： - 第一个数据页里有三条数据，每条数据都包含联合索引的三个字段的值和主键值，数据页内部按序排：先按班级排序，若一样则按姓名排序，若再一样，则按科目名排序。所以数据页内部都是按照三个字段值排序，组成单链表。 - 数据页之间有序。第二个数据页里的三个字段的值一定都＞上一个数据页里三个字段的值，比较方法也是按班级名称、学生姓名、科目名依次比较，数据页间组成双向链表 索引页里就是两条数据，分别指向两个数据页，索引存放的是每个数据页里最小的那个数据的值，大家看到，索引页里指向两个数据页的索引项里都是存放了那个数据页里最小的值！ 索引页内部的数据页是组成单向链表有序的，如你有多个索引页，索引页之间也有序，组成双向链表。 假设搜索：1班+张小强+数学的成绩，你可能写 `select * from student_score where class_name='1班' and student_name='张小强' and subject_name='数学'` 涉及索引使用规则，where条件里的几个字段都是等值查询且where条件里的几个字段名称和顺序也跟你的联合索引一样！此时就是等值匹配规则，上面的SQL百分百可以用联合索引查询。 # 查询过程 首先到索引页找，索引页里有多个数据页的最小值记录，在索引页二分查找，先根据【班级名称】找6班对应数据页，定位到其所在数据页  在数据页内部本身也是单向链表，直接二分查找，先找6班，发现几条数据都是6班，此时就按张三姓名来二分查找，此时会发现多条数据都是张小强，接着就按科目名称数学二分查找。 定位到下图中的一条数据，6班的张三数学，其对应id=127：  然后就根据主键id=127到聚簇索引里按照一样的思路，从索引根节点开始二分查找迅速定位下个层级的页，再不停找，很快就可以找到id=127的那条数据，然后从里面提取所有字段，包括分数，就可以了。 # 总结 如上就是联合索引的查找过程以及全值匹配规则，假设你的SQL语句的where条件里用的几个字段的名称和顺序，都跟你的索引里的字段一样，同时你还是用等号在做等值匹配，那么直接就会按照上述过程来找。 联合索引就是依次按照各个字段来进行二分查找，先定位到第一个字段对应的值在哪个页里，然后如果第一个字段有多条数据值都一样，就根据第二个字段来找，以此类推，一定可以定位到某条或者某几条数据。 # 索引使用规则 有了联合索引后，SQL怎么写才能让他的查询使用索引？ ## 等值匹配规则 where语句中的几个字段名称和联合索引的字段完全一样，而且都是基于等号的等值匹配，那百分百会用上我们的索引。即使你where语句里写的字段的顺序和联合索引里的字段顺序不一致，也没关系，MySQL会自动优化为按联合索引的字段顺序去找。 ## 最左侧列匹配 假设我们联合索引是KEY(class_name, student_name, subject_name)，那不一定必须要在where语句里根据三个字段来查，其实只要根据最左侧的部分字段来查，也可以。 比如你可以写 `select * from student_score where class_name='' and student_name=''` 但是假设你写一个 `select * from student_score where subject_name=''` 就不行了，因为联合索引的B+树里，必先按class_name查，再按student_name查，不能跳过前面两个字段，直接按最后一个subject_name查。 若如下SQL： `select * from student_score where class_name='' and subject_name=''` 那么只有class_name的值可以在索引里搜索，剩下的subject_name是没法在索引里找的，道理同上。 所以在建立索引的过程中，你必须考虑好联合索引字段的顺序，以及你平时写SQL的时候要按哪几个字段来查。 ## 最左前缀匹配原则 如果你要用like语法来查，比如 `select * from student_score where class_name like '1%'` 查找所有1打头的班级的分数，那么也是可以用到索引的。 因为你的联合索引的B+树里，都是按照class_name排序的，所以你要是给出class_name的确定的最左前缀就是1，然后后面的给一个模糊匹配符号，那也是可以基于索引来查找的，这是没问题的。 但是你如果写class_name like ‘%班’，在左侧用一个模糊匹配符，那他就没法用索引了，因为不知道你最左前缀是什么，怎么去索引里找啊？ ## 范围查找规则 这个意思就是说，我们可以用select * from student_score where class_name>‘1 班’ and class_name'5班’这样的语句来范围查找某几个班级的分数。 这个时候也是会用到索引的，因为我们的索引的最下层的数据页都是按顺序组成双向链表的，所以完全可以先找到’1 班’对应的数据页，再找到’5班’对应的数据页，两个数据页中间的那些数据页，就全都是在你范围内的数据了！ 但 是 如 果 你 要 是 写 select * from student_score where class_name>‘1 班 ’ and class_name‘5 班 ’ and student_name>’’，这里只有class_name是可以基于索引来找的，student_name的范围查询是没法用到索引的！ 这也是一条规则，就是你的where语句里如果有范围查询，那只有对联合索引里最左侧的列进行范围查询才能用到索引！ ## 等值匹配+范围匹配的规则 如果你要是用 `select * from student_score where class_name='1班' and student_name>'' and subject_name''` 那么此时你首先可以用class_name在索引里精准定位到一波数据，接着这波数据里的student_name都是按照顺序排列的，所以student_name>’‘也会基于索引来查找，但是接下来的subject_name’'是不能用索引的。 综上，一般写SQL都是： - 用联合索引的最左侧的多个字段来进行等值匹配+范围搜索 - 或基于最左侧的部分字段来进行最左前缀模糊匹配 - 或基于最左侧字段来进行范围搜索

【功能模块】由于需要做数据统计的功能需要使用union的字段将两个表数据进行合并，采使用了union字段之前这个字段使用没有问题，现在使用这个字段控制台直接报错，在脚本里面执行union的sql不会报错但是select的数据是只有一个表的数据问一下这个字段能不能用啊，之前是可以用的，怎么现在不能用了【操作步骤&问题现象】1、2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

本讲分两部分，第一部分Sql进阶，详细讲解了GaussDB(DWS)的数据字典，数据类型，函数操作符，存储过程等，第二部分应用程序应用指南，从数据库驱动概念，基于ODBC/JDBC的应用程序开发。 

WAF（Web应用防火墙）通过对HTTP(S)请求进行检测，识别并阻断SQL注入、跨站脚本攻击、网页木马上传、命令/代码注入等攻击，所有请求流量经过WAF时，WAF会记录攻击和访问的日志，可实时决策分析、对设备进行运维管理以及业务趋势分析。前提条件购买并使用华为云WAF实例。限制条件仅云模式支持全量日志功能。支持全量日志功能的区域为：华北-北京一、华北-北京四、华东-上海一、华东-上海二、中国-香港、亚太-曼谷、亚太-莫斯科、华北-乌兰察布一 、华南-广州。设置步骤在WAF添加防护网站。登录管理控制台。在控制台左上角单击，选择区域和项目。在系统首页左上角单击，选择“安全与合规 > Web应用防火墙 WAF”，进入Web应用防火墙管理控制台。根据添加防护域名添加需要防护的网站，使网站流量切入WAF。开启全量日志功能，将WAF日志记录到LTS，详细操作请参见开启全量日志。在Web应用防火墙管理控制台，单击“防护事件”，选择“全量日志”页签。开启全量日志，选择已创建的日志组与日志流。如未创建日志组与日志流，请先创建日志组和创建日志流。单击“确定”，全量日志配置成功。         图1 配置全量日志        在日志流详情页面，单击左侧导航栏“配置中心”，选择“结构化配置”，进入日志结构化配置页面，选择“JSON”提取方式，根据业务需求选择日志，配置相关参数，具体操作请参见日志结构化。图2 配置JSON格式日志在日志流详情页面，单击“可视化”页签，进行SQL查询与分析，如需要多样化呈现查询结果，请参考日志结构化进行配置。统计1周内攻击次数，具体SQL查询分析语句如下所示：select count(*) as attack_times图3 攻击次数查询结果统计1天不同攻击类型的分布，具体SQL查询分析语句如下所示：select attack,count(*) as times group by attack查询结构有五种呈现形式依上而下分别为表格、柱状图、折线图、饼图、数字，如下图为饼图结果。图4 不同攻击类型的分布查询结果

使用ESCAPE定义转义符     在使用LIKE关键字进行模糊查询时，“%”、“_”和“[]”单独出现时，会被认为是通配符。为了在字符数据类型的列中查询是否存在百分号 （%）、下划线（_）或者方括号（[]）字符，就需要有一种方法告诉DBMS，将LIKE判式中的这些字符看作是实际值，而不是通配符。关键字 ESCAPE允许确定一个转义字符，告诉DBMS紧跟在转义字符之后的字符看作是实际值。如下面的表达式：LIKE '%M%' ESCAPE ‘M'使用ESCAPE关键字定义了转义字符“M”，告诉DBMS将搜索字符串“%M%”中的第二个百分符（%）作为实际值，而不是通配符。当然，第一个百分符（%）仍然被看作是通配符，因此满足该查询条件的字符串为所有以％结尾的字符串。类似地，下面的表达式：LIKE  'AB&_%'   ESCAPE  ‘&'此时，定义了转义字符“&”，搜索字符串中紧跟“&”之后的字符，即“_”看作是实际字符值，而不是通配符。而表达式中的“%”，仍然作 为通配符进行处理。该表达式的查询条件为以“AB_”开始的所有字符串。通过此文希望能帮助到大家，谢谢大家对本站的支持！转载自https://www.jb51.net/article/93208.htm

需要实现：12345if not exists(select * from ErrorConfig where Type='RetryWaitSeconds')begin  insert into ErrorConfig(Type,Value1)  values('RetryWaitSeconds','3')end只能用：123insert into ErrorConfig(Type,Value1)select 'RetryWaitSeconds','3'where not exists(select * from ErrorConfig where Type='RetryWaitSeconds')因为 SQLite 中不支持SP补充：sqlite3中NOT IN 不好用的问题在用sqlite3熟悉SQL的时候遇到了一个百思不得其解的问题，也没有在google上找到答案。虽然最后用“迂回”的方式碰巧解决了这个问题，但暂时不清楚原理是什么，目前精力有限，所以暂时记录下来，有待继续研究。数据库是这样的：1234567891011121314151617181920212223CREATE TABLE book ( id integer primary key, title text, unique(title));CREATE TABLE checkout_item ( member_id integer, book_id integer, movie_id integer, unique(member_id, book_id, movie_id) on conflict replace, unique(book_id), unique(movie_id));CREATE TABLE member ( id integer primary key, name text, unique(name));CREATE TABLE movie ( id integer primary key, title text, unique(title));该数据库包含了4个表:book, movie, member, checkout_item。其中，checkout_item用于保存member对book和movie的借阅记录，属于关系表。问一：哪些member还没有借阅记录？SQL语句（SQL1)如下：1SELECT * FROM member WHERE id NOT IN(SELECT member_id FROM checkout_item);得到了想要的结果。问二：哪些book没有被借出？这看起来与上一个是类似的，于是我理所当然地运行了如下的SQL语句(SQL2)：1SELECT * FROM book WHERE id NOT IN(SELECT book_id FROM checkout_item);可是——运行结果没有找到任何记录！ 我看不出SQL2与SQL1这两条语句有什么差别，难道是book表的问题？于是把NOT去掉，运行了如下查询语句：1SELECT * FROM book WHERE id IN(SELECT book_id FROM checkout_item);正确返回了被借出的book，其数量小于book表里的总行数，也就是说确实是有book没有借出的。接着google（此处省略没有营养的字），没找到解决方案。可是，为什么member可以，book就不可以呢？它们之前有什么不同？仔细观察，发现checkout_item里的book_id和movie_id都加了一个unique，而member_id则没有。也许是这个原因？不用id了，换title试试：1234SELECT * FROM book WHERE title NOT IN(  SELECT title FROM book WHERE id IN( SELECT book_id FROM checkout_item));确实很迂回，但至少work了。。。问题原因：当NOT碰上NULL事实是，我自己的解决方案只不过是碰巧work，这个问题产生跟unique没有关系。邱俊涛的解释是，“SELECT book_id FROM checkout_item”的结果中含有null值，导致NOT也返回null。当一个member只借了movie而没有借book时，产生的checkout_item中book_id就是空的。解决方案是，在选择checkout_item里的book_id时，把值为null的book_id去掉：1SELECT * FROM book WHERE id NOT IN(SELECT book_id FROM checkout_item WHERE book_id IS NOT NULL);总结我在解决这个问题的时候方向是不对的，应该像调试程序一样，去检查中间结果。比如，运行如下语句，结果会包含空行：1SELECT book_id FROM checkout_item而运行下列语句，结果不会包含空行：1SELECT member_id FROM checkout_item这才是SQL1与SQL2两条语句执行过程中的差别。根据这个差别去google，更容易找到答案。当然了，没有NULL概念也是我“百思不得其解”的原因。转载自https://www.jb51.net/article/203321.htm

GaussDB(DWS)项目实践--实践系列文章汇总，请大家阅读鉴赏，欢迎在评论区交流探讨~序号主题分类标题链接1实践系列windows下使用ODBC连接DWS查询大数据量结果后报out of memory while reading tupleshttps://bbs.huaweicloud.com/forum/thread-176933-1-1.html2实践系列 GaussDB(DWS)实践系列-低效业务脚本检测指导https://bbs.huaweicloud.com/forum/thread-151360-1-1.html3实践系列GaussDB(DWS)实践系列-函数实现JSON类型解析https://bbs.huaweicloud.com/forum/thread-151349-1-1.html4实践系列GaussDB(DWS)实践系列-RoaringBitmap替换方案https://bbs.huaweicloud.com/forum/thread-151119-1-1.html5实践系列GaussDB(DWS)实践系列-List行转列函数实现https://bbs.huaweicloud.com/forum/thread-148308-1-1.html6实践系列GaussDB(DWS)实践系列-分区表TTL管理实现https://bbs.huaweicloud.com/forum/thread-147907-1-1.html7实践系列GaussDB(DWS)实践系列-ClickHouse-&gt;GaussDB(DWS)迁移https://bbs.huaweicloud.com/forum/thread-146686-1-1.html8实践系列GaussDB(DWS)实践系列-日常硬件巡检指导https://bbs.huaweicloud.com/forum/thread-146654-1-1.html9实践系列GaussDB DWS中的内存资源配置实践https://bbs.huaweicloud.com/forum/thread-144730-1-1.html10实践系列DWS性能点赞https://bbs.huaweicloud.com/forum/thread-134124-1-1.html11实践系列通过sql查询获取表字段详细信息https://bbs.huaweicloud.com/forum/thread-133428-1-1.html12实践系列通过sql查询快速获取分区表的的分区键https://bbs.huaweicloud.com/forum/thread-133424-1-1.html13实践系列处理执行sql文件时，某个sql语句报错，需要继续执行其余sql，直至所有sql执行完毕。https://bbs.huaweicloud.com/forum/thread-132498-1-1.html14实践系列GaussDB(DWS) 【低效SQL分析案例】https://bbs.huaweicloud.com/forum/thread-131969-1-1.html15实践系列GaussDB(DWS) 【查询包含某个字段的所有表清单方法】https://bbs.huaweicloud.com/forum/thread-131778-1-1.html16实践系列GaussDB(DWS) 【多值列场景的处理方法】https://bbs.huaweicloud.com/forum/thread-131777-1-1.html17实践系列GaussDB(DWS) 【并发测试脚本】https://bbs.huaweicloud.com/forum/thread-131776-1-1.html18实践系列GaussDB(DWS) 【常用对象赋权方法】https://bbs.huaweicloud.com/forum/thread-131775-1-1.html19实践系列GaussDB(DWS) 【角色权限相关视图使用方法】https://bbs.huaweicloud.com/forum/thread-131774-1-1.html20实践系列GaussDB(DWS) 【查询对象所有权限属性的两种方法】https://bbs.huaweicloud.com/forum/thread-131772-1-1.html21实践系列GaussDB(DWS)【用SQL方式查询所有带主键的表的主键字段方法】https://bbs.huaweicloud.com/forum/thread-131771-1-1.html22实践系列GaussDB(DWS)【通过SQL方式查询分区表的的分区字段方法】https://bbs.huaweicloud.com/forum/thread-131770-1-1.html23实践系列GaussDB(DWS)【查找视图依赖的表对象方法】https://bbs.huaweicloud.com/forum/thread-131377-1-1.html24实践系列GaussDB(DWS)实践系列-两级用户权限管理实践https://bbs.huaweicloud.com/forum/thread-131122-1-1.html25实践系列华为DWS数仓配置教程及初体验https://bbs.huaweicloud.com/forum/thread-130907-1-1.html26实践系列GaussDB(DWS)实践系列-GaussDB(DWS)如何查询对象(表)的创建时间？https://bbs.huaweicloud.com/forum/thread-130767-1-1.html27实践系列GaussDB(DWS)实践系列-行级访问策略优化实践https://bbs.huaweicloud.com/forum/thread-130766-1-1.html28实践系列DWS VARCHAR存放字符即VARCHAR(1)存放1个汉字https://bbs.huaweicloud.com/forum/thread-129571-1-1.html29实践系列GaussDB(DWS)--基于用户的空间管理方法https://bbs.huaweicloud.com/forum/thread-128924-1-1.html30实践系列GaussDB(DWS)实践系列-工作负载管理交付指南（线上版本）https://bbs.huaweicloud.com/forum/thread-128276-1-1.html31实践系列GaussDB(DWS)实践系列-工作负载管理交付指南（线下版本）https://bbs.huaweicloud.com/forum/thread-128274-1-1.html32实践系列GaussDB(DWS)倾斜表查询实践https://bbs.huaweicloud.com/forum/thread-127754-1-1.html33实践系列GaussDB(DWS)集群运维巡检保障指导书https://bbs.huaweicloud.com/forum/thread-127747-1-1.html34实践系列GaussDB(DWS)数据库审计方案https://bbs.huaweicloud.com/forum/thread-127727-1-1.html35实践系列GaussDB(DWS)数据库安全方案https://bbs.huaweicloud.com/forum/thread-127724-1-1.html36实践系列DWS对接DLI Flink实现实时数据接入https://bbs.huaweicloud.com/forum/thread-124688-1-1.html37实践系列【实践系列】GaussDB(DWS)存储过程中实现作业执行过程日志记录方法https://bbs.huaweicloud.com/forum/thread-124684-1-1.html38实践系列DWS开发技术规范https://bbs.huaweicloud.com/forum/thread-122979-1-1.html39实践系列GaussDB(DWS)实践系列-常用命令FAQhttps://bbs.huaweicloud.com/forum/thread-122916-1-1.html40实践系列逻辑集群中的用户权限https://bbs.huaweicloud.com/forum/thread-121664-1-1.html41实践系列GaussDB(DWS)记录数据表操纵日志--系统日志提取方案https://bbs.huaweicloud.com/forum/thread-120445-1-1.html42实践系列数据仓库服务（DWS）事件管理记录为空的问题解决方案https://bbs.huaweicloud.com/forum/thread-119839-1-1.html43实践系列GaussDB(DWS) &amp;TD;分区表设计原理和使用对比https://bbs.huaweicloud.com/forum/thread-119610-1-1.html44实践系列DWS 多表关联创建PCK提升性能https://bbs.huaweicloud.com/forum/thread-119538-1-1.html45实践系列MPP架构下数据倾斜率分析https://bbs.huaweicloud.com/forum/thread-119460-1-1.html46实践系列GaussDB(DWS)实践系列-由两个问题引发的对GaussDB(DWS)负载均衡的思考https://bbs.huaweicloud.com/forum/thread-119451-1-1.html47实践系列数据仓库双集群系统方案探讨https://bbs.huaweicloud.com/forum/thread-119450-1-1.html48实践系列GaussDB(DWS)实践系列--常见的三种公共模式https://bbs.huaweicloud.com/forum/thread-119445-1-1.html49实践系列GaussDB(DWS)集群安装过程及部分问题解决方案https://bbs.huaweicloud.com/forum/thread-119438-1-1.html50实践系列GaussDB(DWS)审计日志转储实践https://bbs.huaweicloud.com/forum/thread-119436-1-1.html51实践系列GaussDB(DWS)实践系列-数据仓库日常巡检策略总结https://bbs.huaweicloud.com/forum/thread-118246-1-1.html52实践系列GaussDB(DWS)实践系列-业务表拆分显示策略分享https://bbs.huaweicloud.com/forum/thread-118244-1-1.html53实践系列GaussDB(DWS)实践系列-SQL语句上线验收操作指导https://bbs.huaweicloud.com/forum/thread-118242-1-1.html54实践系列GaussDB(DWS)实践系列-性能优化最佳实践https://bbs.huaweicloud.com/forum/thread-118241-1-1.html55实践系列GaussDB(DWS)实践系列-资源管控方案技术实战分享https://bbs.huaweicloud.com/forum/thread-118238-1-1.html56实践系列GaussDB(DWS)实践系列—关于释放磁盘异常占用空间的经验总结https://bbs.huaweicloud.com/forum/thread-118236-1-1.html57实践系列Gauss DB（DWS）迁移系列-TD迁移DDL差异-字段标题属性设置Titlehttps://bbs.huaweicloud.com/forum/thread-117986-1-1.html58实践系列GaussDB(DWS)通过GDS导出的文件竟然无法重新导入到源表https://bbs.huaweicloud.com/forum/thread-117975-1-1.html59实践系列GaussDB(DWS)对被视图引用的表进行DDL操作步骤https://bbs.huaweicloud.com/forum/thread-117973-1-1.html60实践系列Gauss DB（DWS）迁移系列-含右空格的varchar字符型”=与&lt;&gt;”等值比较https://bbs.huaweicloud.com/forum/thread-117943-1-1.html61实践系列【GaussDB（DWS）实践系列】 SQL下盘导致磁盘IO高问题分析https://bbs.huaweicloud.com/forum/thread-117932-1-1.html62实践系列【GaussDB(DWS)实践系列】华为商城（Vmall）背后的黑科技https://bbs.huaweicloud.com/forum/thread-117931-1-1.html63实践系列配置SQL ON OBS桶策略，实现DWS访问分离https://bbs.huaweicloud.com/forum/thread-117771-1-1.html64实践系列GaussDB(DWS)中GTM组件对sequence管理https://bbs.huaweicloud.com/forum/thread-117769-1-1.html65实践系列【GaussDB(DWS)实践系列】数据倾斜检查与修改方法https://bbs.huaweicloud.com/forum/thread-117767-1-1.html66实践系列SQL执行流程图https://bbs.huaweicloud.com/forum/thread-117765-1-1.html67实践系列Gauss DB（DWS）迁移系列-char类型差异性说明https://bbs.huaweicloud.com/forum/thread-117662-1-1.html68实践系列Gauss DB（DWS）迁移系列-TD幂运算替代https://bbs.huaweicloud.com/forum/thread-117657-1-1.html69实践系列【易运维】快速提取锁等待SQL语句 lock waithttps://bbs.huaweicloud.com/forum/thread-116218-1-1.html70实践系列【易运维】自定义视图快速了解个人用户登陆信息https://bbs.huaweicloud.com/forum/thread-116124-1-1.html71实践系列视图依赖层级快速获取实践https://bbs.huaweicloud.com/forum/thread-116037-1-1.html72实践系列GaussDB(DWS) 【对接数据可视化工具Grafana】https://bbs.huaweicloud.com/forum/thread-114960-1-1.html73实践系列GaussDB(DWS)字符集浅谈https://bbs.huaweicloud.com/forum/thread-114882-1-1.html74实践系列DWS  SQL 查询的几点建议https://bbs.huaweicloud.com/forum/thread-112506-1-1.html75实践系列DWS 分区表简介https://bbs.huaweicloud.com/forum/thread-112487-1-1.html76实践系列DWS 局部聚簇（Partial Cluster Key）选取规则https://bbs.huaweicloud.com/forum/thread-112478-1-1.html77实践系列DWS 开发过程中SQL编写建议https://bbs.huaweicloud.com/forum/thread-112471-1-1.html78实践系列DWS coordinator部署规划推荐规则https://bbs.huaweicloud.com/forum/thread-112461-1-1.html79实践系列【GaussDB（DWS）实践系列】低效SQL的排查和清理https://bbs.huaweicloud.com/forum/thread-111522-1-1.html80实践系列【GaussDB(DWS)实践系列】数据倾斜检查与修改方法https://bbs.huaweicloud.com/forum/thread-111395-1-1.html81实践系列DWS 泰山服务器未做配置加固影响性能的问题https://bbs.huaweicloud.com/forum/thread-110780-1-1.html82实践系列DWS 参数设置不合理导致作业下盘影响性能的问题https://bbs.huaweicloud.com/forum/thread-110776-1-1.html83实践系列DWS 统计信息不准触发nestloop导致查询语句执行缓慢https://bbs.huaweicloud.com/forum/thread-110543-1-1.html84实践系列DWS SQL语句中in常量优化https://bbs.huaweicloud.com/forum/thread-110535-1-1.html85实践系列DWS 语句中not in触发NestLoop导致SQL执行慢的问题https://bbs.huaweicloud.com/forum/thread-110506-1-1.html86实践系列DWS语句不下推问题分析https://bbs.huaweicloud.com/forum/thread-110436-1-1.html87实践系列DWS 集群出现很多dn报内存不可用问题定位https://bbs.huaweicloud.com/forum/thread-109095-1-1.html88实践系列DWS 以TPCH Q7为例，简单介绍Hang问题基本定位过程https://bbs.huaweicloud.com/forum/thread-109083-1-1.html89实践系列DWS INSERT语句疑似HANG住问题https://bbs.huaweicloud.com/forum/thread-109080-1-1.html90实践系列DWS DDL HANG问题，长时间无法返回！https://bbs.huaweicloud.com/forum/thread-109062-1-1.html91实践系列为何时间戳数据写入和查询的值相差8小时https://bbs.huaweicloud.com/forum/thread-109028-1-1.html92实践系列DWS系统性能问题集锦https://bbs.huaweicloud.com/forum/thread-105345-1-1.html93实践系列&quot;最大并发数&quot; 真的能控制住并发   ？https://bbs.huaweicloud.com/forum/thread-105251-1-1.html94实践系列GaussDB的递归https://bbs.huaweicloud.com/forum/thread-101514-1-1.html95实践系列解决表过多导致的 PGXC_GET_STAT_ALL_TABLES 查询慢问题https://bbs.huaweicloud.com/forum/thread-101196-1-1.html96实践系列行转列的一个函数https://bbs.huaweicloud.com/forum/thread-100204-1-1.html97实践系列DWS内存参数调优https://bbs.huaweicloud.com/forum/thread-99652-1-1.html98实践系列DWS 硬件瓶颈点分析https://bbs.huaweicloud.com/forum/thread-99630-1-1.html99实践系列【程序猿的世界没有单身汪，数仓界达芬奇带您手动设计心仪对象】-12.22直播相关答疑FAQhttps://bbs.huaweicloud.com/forum/thread-98119-1-1.html100实践系列常用的日期操作https://bbs.huaweicloud.com/forum/thread-92120-1-1.html101实践系列如何快速识别被阻塞的SQL语句是不是被其他语句持有锁导致的？https://bbs.huaweicloud.com/forum/thread-90184-1-1.html102实践系列查看表及索引大小https://bbs.huaweicloud.com/forum/thread-87142-1-1.html103实践系列DWS 服务器选型很重要！！！！！！！！！！！！！！！https://bbs.huaweicloud.com/forum/thread-86286-1-1.html104实践系列DWS分页排序https://bbs.huaweicloud.com/forum/thread-81754-1-1.html105实践系列一种获取表结构的方法https://bbs.huaweicloud.com/forum/thread-81612-1-1.html106实践系列表空间提取 - schema维度提取表大小及倾斜率https://bbs.huaweicloud.com/forum/thread-81495-1-1.html107实践系列终止运行时间过长的sql session的方法https://bbs.huaweicloud.com/forum/thread-81492-1-1.html108实践系列记一次单表查询慢的定位过程https://bbs.huaweicloud.com/forum/thread-81113-1-1.html109实践系列行存表和Btree索引的应用实现语句的秒级返回https://bbs.huaweicloud.com/forum/thread-76279-1-1.html110实践系列DataStudio工具如何设置保存登录密码？https://bbs.huaweicloud.com/forum/thread-76084-1-1.html111实践系列数据库开发技巧之数据库表长度限制https://bbs.huaweicloud.com/forum/thread-76019-1-1.html112实践系列WITH 中用多个CTEhttps://bbs.huaweicloud.com/forum/thread-75517-1-1.html113实践系列GaussDB(DWS)角色赋予角色后关系字典查询https://bbs.huaweicloud.com/forum/thread-75276-1-1.html114实践系列GaussDB(DWS) 【生成随机字符串的方法】https://bbs.huaweicloud.com/forum/thread-74944-1-1.html115实践系列DWS for GaussDB 生成随机字符串的方法https://bbs.huaweicloud.com/forum/thread-74942-1-1.html116实践系列GaussDB(DWS) 【in 与join 在遇到重复数据时的区别】https://bbs.huaweicloud.com/forum/thread-74913-1-1.html117实践系列upsert语句怎么改写？https://bbs.huaweicloud.com/forum/thread-73699-1-1.html118实践系列GaussDB多值入参场景实现方法https://bbs.huaweicloud.com/forum/thread-71314-1-1.html119实践系列GaussDB(DWS)多行转一行(列转行)聚合函数listagghttps://bbs.huaweicloud.com/forum/thread-71153-1-1.html120实践系列使用latin1存储了汉字，怎么按照汉字做匹配运算？https://bbs.huaweicloud.com/forum/thread-70943-1-1.html121实践系列存储过程中获取当前schemahttps://bbs.huaweicloud.com/forum/thread-70770-1-1.html122实践系列GaussDB(DWS) 【表脏页率查询方法】https://bbs.huaweicloud.com/forum/thread-66043-1-1.html123实践系列GaussDB(DWS) 【使用窗口函数去重方法】https://bbs.huaweicloud.com/forum/thread-65645-1-1.html124实践系列GaussDB(DWS) 【中找出那些表没有做过analyze】https://bbs.huaweicloud.com/forum/thread-64751-1-1.html125实践系列GaussDB(DWS) 【判断表是否做过update或者delete操作】https://bbs.huaweicloud.com/forum/thread-64426-1-1.html126实践系列GaussDB(DWS) 【TopSql 抓取方法】https://bbs.huaweicloud.com/forum/thread-64238-1-1.html127实践系列GaussDB(DWS)【维度表修改为复制表提升查询性能】https://bbs.huaweicloud.com/forum/thread-64061-1-1.html128实践系列GaussDB(DWS) 【视图依赖的表名发生rename后DWS与ORACLE的不同表现】https://bbs.huaweicloud.com/forum/thread-64055-1-1.html129实践系列GaussDB(DWS)实践系列- 数据仓库自动化清理功能实现https://bbs.huaweicloud.com/forum/thread-60626-1-1.html130实践系列GaussDB(DWS) 【子查询中包含不存在列时在DWS&amp;mysql;&amp;postgres;的表现】https://bbs.huaweicloud.com/forum/thread-59594-1-1.html131实践系列GaussDB(DWS) 【存储过程中查询一张表的结果（多个字段）分别附给多个变量的方法】https://bbs.huaweicloud.com/forum/thread-59402-1-1.html

>摘要：GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级问题的定位和分析。本文分享自华为云社区《[GaussDB(DWS)运维 -- 一键式锁等待和分布式死锁检测](https://bbs.huaweicloud.com/blogs/331625?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content)》，作者：譡里个檔。 锁是GaussDB(DWS)实现并发管理的关键要素，GaussDB(DWS)锁类别有表级锁、分区级锁(和表级锁一致)、事务锁、咨询锁等，当前业务最常用的是表级锁、分区级锁(和表级锁一致)、事务锁。不同的SQL语句执行时需要申请并持有对应的锁，当这些锁资源存在互斥时，对应的业务SQL就会产生等待；这种等待会产生下面几种后果： 1. 持锁的一方释放锁(一般对应的动作为持锁的事物提交)，等待锁的一方申请到锁，然后继续执行 2. 持锁的一方事物长时间未提交，等待锁的一方因为锁等待超时导致作业报错 3. A实例上持锁事物和申请锁的事物在B实例上角色互换，产生分布式死锁(具体见下文介绍)。这种场景下需要首先达到锁等待超时的事物报错回滚时释放锁资源，然后另外一个事物申请到才能正常进行 从上述的描述可以看到，锁等待特别是分布式死锁对业务影响很大，轻则产生等待导致业务性能抖动和下降，甚至业务报错。GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级定位和分析。 # 1）锁等待检测视图pgxc_lock_conflicts 【功能】查询当前库里面不同节点上的锁等待信息  【解析】执行如下查询结果 postgres=# SELECT * FROM pgxc_lock_conflicts ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | username | gxid | xactstart | queryid | query | pid | mode | granted -----------+----------+----------+---------+-----------------------+----------+------+-------+---------------+-----------+----------+-------------------------------+--------------------+----------------------------------------------------------+-----------------+---------------------+--------- partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 104145741383084190 | alter table table_partition_num_3 truncate partition p1; | 140160505136896 | AccessExclusiveLock | f partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 0 | alter table table_partition_num_3 truncate partition p1; | 140160568055552 | AccessExclusiveLock | t relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 175921860444402398 | truncate xxx; | 140418767369984 | AccessShareLock | f relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 0 | truncate xxx; | 140420489144064 | AccessExclusiveLock | t (4 rows) 如上的SQL显示 - 在节点cn_5001的postgres里面的表public.table_partition_num_3的分区p1上存在分区级别(partition)的锁冲突。在当前的锁冲突中线程140160568055552持有锁(mode = true)，锁级别是AccessExclusiveLock，执行语句为alter table table_partition_num_3 truncate partition p1。线程140160568055552在等待(mode = false)AccessExclusiveLock锁，等待锁的语句也是alter table table_partition_num_3 truncate partition p1。 - 在节点cn_5002的postgres里面的表http://public.xxx上存在表级别(relation)的锁冲突。线程140420489144064持有锁AccessExclusiveLock(mode = true)，线程140418767369984在等待(mode = false)AccessShareLock锁 # 2）分布式锁等待检测视图pgxc_deadlock 【功能】查询当前库里面不同节点上的分布式死锁信息  【解析】执行如下查询结果 postgres=# SELECT * FROM pgxc_deadlock ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | waitusername | waitgxid | waitxactstart | waitqueryid | waitquery | waitpid | waitmode | holdusername | holdgxid | holdxactstart | holdqueryid | holdquery | holdpid | holdmode ----------+----------+----------+---------+---------+----------+------+-------+---------------+--------------+----------+-------------------------------+--------------------+-----------------------------------------------------+-----------------+-----------------+--------------+----------+-------------------------------+-------------+--------------+-----------------+--------------------- relation | cn_5001 | postgres | public | t2 | | | | | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 104145741383110084 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t2'; | 140160505136896 | AccessShareLock | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 0 | TRUNCATE t2; | 140160421234432 | AccessExclusiveLock relation | cn_5002 | postgres | public | t1 | | | | | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 175921860444446866 | EXECUTE DIRECT ON(dn_6001_6002) 'SELECT * FROM t1'; | 140418784151296 | AccessShareLock | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 0 | TRUNCATE t1; | 140421763163904 | AccessExclusiveLock (2 rows) 如上的SQL显示，在postgres库里面 - 节点cn_5001上 事务24112465通过线程140160421234432持有表public.t2的AccessExclusiveLock锁 事务24112406通过线程140160505136896在等待申请表public.t2的AccessShareLock锁 - 节点cn_5002上 事务24112465通过线程140418784151296在等待申请表public.t1的AccessShareLock锁 事物24112406通过线程140421763163904持有表public.t1的AccessExclusiveLock锁 如果我们把资源的持有情况按照持有到申请定义一个防线的话，可以形成如下表格  从上述可以看出，事务24112465在节点cn_5001持有表public.t2的AccessExclusiveLock锁，等待申请申请表public.t1的AccessShareLock锁；事务24112406在节点cn_5002上持有表public.t1的AccessExclusiveLock锁，等待申请申请表public.t2的AccessShareLock锁；事务24112406和事务24112465只有等待彼此提交才能申请到锁资源，让自己继续执行，这种在多个实例上的分布式等待关系形成了一个环状，我们称这种现象为分布式死锁。 # 3) 锁等待和分布式死锁的区别 对于分布式死锁，只能一个事务因为锁等待（参数lockwait_timeout）超时回滚的时候，另外一个事务才能进行下去；或者人工干预kill或者cancel其中一个事务，让另外一个事务进行下去。 对于没有分布式死锁的锁等待，这种一般不需要人工干涉，等待持锁事务正常执行完成之后另外一个事务就可以正常执行；但是如果事务持锁时间超过锁等待超时参数（参数lockwait_timeout），等待锁的事务会因为锁等待超时失败。

原文链接：https://blog.csdn.net/wangyuxiang946/article/details/122996953一、数值型注入前台页面输入的参数是「数字」。比如下面这个根据ID查询用户的功能。后台对应的SQL如下，字段类型是数值型，这种就是数值型注入。select * from user where id = 1;二、字符型注入前台页面输入的参数是「字符串」。比如下面这个登录功能，输入的用户名和密码是字符串。后台对应的SQL如下，字段类型是字符型，这种就是字符型注入。select * from user where username = 'zhangsan' and password = '123abc';字符可以使用单引号包裹，也可以使用双引号包裹，根据包裹字符串的「引号」不同，字符型注入可以分为：「单引号字符型」注入和「双引号字符型」注入。1）单引号字符型注入参数使用「单引号」包裹时，叫做单引号字符型注入，比如下面这个SQL，就是单引号字符型注入。select * from user where username = 'zhangsan';2）双引号字符型注入参数使用「双引号」包裹时，叫做双引号字符型注入，比如下面这个SQL，就是双引号字符型注入。select * from user where username = "zhangsan";3）带有括号的注入理论上来说，只有数值型和字符型两种注入类型。SQL的语法，支持使用一个或多个「括号」包裹参数，使得这两个基础的注入类型存在一些变种。a. 数值型+括号的注入使用括号包裹数值型参数，比如下面这种SQL。select * from user where id = (1);select * from user where id = ((1));包裹多个括号……b. 单引号字符串+括号的注入使用括号和单引号包裹参数，比如下面这种SQL。select * from user where username = ('zhangsan');select * from user where username = (('zhangsan'));包裹多个括号……c. 双引号字符串+括号的注入使用括号和双引号包裹参数，比如下面这种SQLselect * from user where username = ("zhangsan");select * from user where username = (("zhangsan"));包裹多个括号……三、其他类型除了根据参数的分类以外，还有其他分类方式。根据数据的「提交方式」分类：GET注入：使用get请求提交数据，比如 xxx.php?id=1.POST注入：使用post请求提交数据，比如表单。Cookie注入：使用Cookie的某个字段提交数据，比如在Cookie中保存用户信息。HTTP Header注入：使用请求头提交数据，比如检测HTTP中的源地址、主机IP等。根据页面「是否回显」分类：显注：前端页面可以回显用户信息，比如 联合注入、报错注入。盲注：前端页面不能回显用户信息，比如 布尔盲注、时间盲注。感谢你的点赞、收藏、评论，我是三日、祝你幸福。

锁是GaussDB(DWS)实现并发管理的关键要素，GaussDB(DWS)锁类别有表级锁、分区级锁(和表级锁一致)、事务锁、咨询锁等，当前业务最常用的是表级锁、分区级锁(和表级锁一致)、事务锁。不同的SQL语句执行时需要申请并持有对应的锁，当这些锁资源存在互斥时，对应的业务SQL就会产生等待；这种等待会产生下面几种后果持锁的一方释放锁(一般对应的动作为持锁的事物提交)，等待锁的一方申请到锁，然后继续执行持锁的一方事物长时间未提交，等待锁的一方因为锁等待超时导致作业报错A实例上持锁事物和申请锁的事物在B实例上角色互换，产生分布式死锁(具体见下文介绍)。这种场景下需要首先达到锁等待超时的事物报错回滚时释放锁资源，然后另外一个事物申请到才能正常进行从上述的描述可以看到，锁等待特别是分布式死锁对业务影响很大，轻则产生等待导致业务性能抖动和下降，甚至业务报错。GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级问题的定位和分析1）锁等待检测视图pgxc_lock_conflicts【功能】查询当前库里面不同节点上的锁等待信息字段名称数据类型字段描述locktypetext被锁定对象的类型，当前支持relation、partition、transactionid三种类型的锁类型nodenamename被锁定对象的节点的名称dbnamename被锁定对象的数据库的名称。如果被锁定对象是事务，则为NULLnspnamename被锁定对象的命名空间的名称relnamename被锁定对象对应的relation的名称。如果被锁定对象既不是relation，也不是relation的一部分，则为NULLpartnamename被锁定对象对应的分区的名称。如果被锁定对象不是分区，则为NULLpageinteger被锁定对象对应的页面的编号。如果被锁定对象既不是页面，也不是元组，则为NULLtuplesmallint被锁定对象对应的元组的编号。如果被锁定对象不是元组，则为NULLtransactionidxid被锁定对象对应的事务的ID。如果被锁定对象不是事务，则为NULLusernamename当前线程所处session的用户名，一般也是当前线程执行语句的用户名称gxidxid当前线程所处事物的事物IDxactstarttimestamptz当前线程所处事务的事物开始时间queryidbigint申请锁的线程的最新查询的queryidquerytext申请锁的线程的最新查询语句pidbigint申请锁的线程的IDmodetext锁的级别grantedbooleanTRUE表示当前线程持有上述指定的锁FALSE表示当前线程正在申请锁，但是没有申请上，处在等待锁的状态【解析】执行如下查询结果postgres=# SELECT * FROM pgxc_lock_conflicts ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | username | gxid | xactstart | queryid | query | pid | mode | granted -----------+----------+----------+---------+-----------------------+----------+------+-------+---------------+-----------+----------+-------------------------------+--------------------+----------------------------------------------------------+-----------------+---------------------+--------- partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 104145741383084190 | alter table table_partition_num_3 truncate partition p1; | 140160505136896 | AccessExclusiveLock | f partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 0 | alter table table_partition_num_3 truncate partition p1; | 140160568055552 | AccessExclusiveLock | t relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 175921860444402398 | truncate xxx; | 140418767369984 | AccessShareLock | f relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 0 | truncate xxx; | 140420489144064 | AccessExclusiveLock | t (4 rows)如上的SQL显示在节点cn_5001的postgres里面的表public.table_partition_num_3的分区p1上存在分区级别(partition)的锁冲突。在当前的锁冲突中线程140160568055552持有锁(mode = true)，锁级别是AccessExclusiveLock，执行语句为alter table table_partition_num_3 truncate partition p1。线程140160568055552在等待(mode = false)AccessExclusiveLock锁，等待锁的语句也是alter table table_partition_num_3 truncate partition p1。在节点cn_5002的postgres里面的表public.xxx上存在表级别(relation)的锁冲突。线程140420489144064持有锁AccessExclusiveLock(mode = true)，线程140418767369984在等待(mode = false)AccessShareLock锁2）分布式锁等待检测视图pgxc_deadlock【功能】查询当前库里面不同节点上的分布式死锁信息字段名称数据类型字段描述locktypetext被锁定对象的类型，当前支持relation、partition、transactionid三种类型的锁类型nodenamename被锁定对象的节点的名称dbnamename被锁定对象的数据库的名称。如果被锁定对象是事务，则为NULLnspnamename被锁定对象的命名空间的名称relnamename被锁定对象对应的关系的名称。如果被锁定对象既不是关系，也不是关系的一部分，则为NULLpartnamename被锁定对象对应的分区的名称。如果被锁定对象不是分区，则为NULLpageinteger被锁定对象对应的页面的编号。如果被锁定对象既不是页面，也不是元组，则为NULLtuplesmallint被锁定对象对应的元组的编号。如果被锁定对象不是元组，则为NULLtransactionidxid被锁定对象对应的事务的ID。如果被锁定对象不是事务，则为NULLwaitusernamename等待锁的用户的名称waitgxidxid等待锁的事务的IDwaitxactstarttimestamptz等待锁的事务的开始时间waitqueryidbigint等待锁的线程的最新查询IDwaitquerytext等待锁的线程的最新查询语句waitpidbigint等待锁的线程的IDwaitmodetext等待的锁的级别holdusernamename持有锁的用户的名称holdgxidxid持有锁的事务的IDholdxactstarttimestamptz持有锁的事务的开始时间holdqueryidbigint持有锁的线程的最新查询IDholdquerytext持有锁的线程的最新查询语句holdpidbigint持有锁的线程的IDholdmodetext持有的锁的级别【解析】执行如下查询结果postgres=# SELECT * FROM pgxc_deadlock ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | waitusername | waitgxid | waitxactstart | waitqueryid | waitquery | waitpid | waitmode | holdusername | holdgxid | holdxactstart | holdqueryid | holdquery | holdpid | holdmode ----------+----------+----------+---------+---------+----------+------+-------+---------------+--------------+----------+-------------------------------+--------------------+-----------------------------------------------------+-----------------+-----------------+--------------+----------+-------------------------------+-------------+--------------+-----------------+--------------------- relation | cn_5001 | postgres | public | t2 | | | | | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 104145741383110084 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t2'; | 140160505136896 | AccessShareLock | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 0 | TRUNCATE t2; | 140160421234432 | AccessExclusiveLock relation | cn_5002 | postgres | public | t1 | | | | | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 175921860444446866 | EXECUTE DIRECT ON(dn_6001_6002) 'SELECT * FROM t1'; | 140418784151296 | AccessShareLock | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 0 | TRUNCATE t1; | 140421763163904 | AccessExclusiveLock (2 rows)如上的SQL显示，在postgres库里面节点cn_5001上        事务24112465通过线程140160421234432持有表public.t2的AccessExclusiveLock锁        事务24112406通过线程140160505136896在等待申请表public.t2的AccessShareLock锁节点cn_5002上        事务24112465通过线程140418784151296在等待申请表public.t1的AccessShareLock锁        事物24112406通过线程140421763163904持有表public.t1的AccessExclusiveLock锁如果我们把资源的持有情况按照持有到申请定义一个防线的话，可以形成如下表格节点事务24112465方向事务24112406cn_5001持有表public.t2的AccessExclusiveLock锁→申请表public.t2的AccessShareLock锁cn_5002申请表public.t1的AccessShareLock锁←持有表public.t1的AccessExclusiveLock锁从上述可以看出，事务24112465在节点cn_5001持有表public.t2的AccessExclusiveLock锁，等待申请申请表public.t1的AccessShareLock锁；事务24112406在节点cn_5002上持有表public.t1的AccessExclusiveLock锁，等待申请申请表public.t2的AccessShareLock锁；事务24112406和事务24112465只有等待彼此提交才能申请到锁资源，让自己继续执行，这种在多个实例上的分布式等待关系形成了一个环状，我们称这种现象为分布式死锁。3) 锁等待和分布式死锁的区别对于分布式死锁，只能一个事务因为锁等待（参数lockwait_timeout）超时回滚的时候，另外一个事务才能进行下去；或者人工干预kill或者cancel其中一个事务，让另外一个事务进行下去。对于没有分布式死锁的锁等待，这种一般不需要人工干涉，等待持锁事务正常执行完成之后另外一个事务就可以正常执行；但是如果事务持锁时间超过锁等待超时参数（参数lockwait_timeout），等待锁的事务会因为锁等待超时失败。

锁是GaussDB(DWS)实现并发管理的关键要素，GaussDB(DWS)锁类别有表级锁、分区级锁(和表级锁一致)、事务锁、咨询锁等，当前业务最常用的是表级锁、分区级锁(和表级锁一致)、事务锁。不同的SQL语句执行时需要申请并持有对应的锁，当这些锁资源存在互斥时，对应的业务SQL就会产生等待；这种等待会产生下面几种后果持锁的一方释放锁(一般对应的动作为持锁的事物提交)，等待锁的一方申请到锁，然后继续执行持锁的一方事物长时间未提交，等待锁的一方因为锁等待超时导致作业报错A实例上持锁事物和申请锁的事物在B实例上角色互换，产生分布式死锁(具体见下文介绍)。这种场景下需要首先达到锁等待超时的事物报错回滚时释放锁资源，然后另外一个事物申请到才能正常进行从上述的描述可以看到，锁等待特别是分布式死锁对业务影响很大，轻则产生等待导致业务性能抖动和下降，甚至业务报错。GaussDB(DWS)提供了两个集群级别的视图快速识别和查询锁等待和分布式死锁信息，可实现此类问题的秒级问题的定位和分析1）锁等待检测视图pgxc_lock_conflicts【功能】查询当前库里面不同节点上的锁等待信息字段名称数据类型字段描述locktypetext被锁定对象的类型，当前支持relation、partition、transactionid三种类型的锁类型nodenamename被锁定对象的节点的名称dbnamename被锁定对象的数据库的名称。如果被锁定对象是事务，则为NULLnspnamename被锁定对象的命名空间的名称relnamename被锁定对象对应的relation的名称。如果被锁定对象既不是relation，也不是relation的一部分，则为NULLpartnamename被锁定对象对应的分区的名称。如果被锁定对象不是分区，则为NULLpageinteger被锁定对象对应的页面的编号。如果被锁定对象既不是页面，也不是元组，则为NULLtuplesmallint被锁定对象对应的元组的编号。如果被锁定对象不是元组，则为NULLtransactionidxid被锁定对象对应的事务的ID。如果被锁定对象不是事务，则为NULLusernamename当前线程所处session的用户名，一般也是当前线程执行语句的用户名称gxidxid当前线程所处事物的事物IDxactstarttimestamptz当前线程所处事务的事物开始时间queryidbigint申请锁的线程的最新查询的queryidquerytext申请锁的线程的最新查询语句pidbigint申请锁的线程的IDmodetext锁的级别grantedbooleanTRUE表示当前线程持有上述指定的锁FALSE表示当前线程正在申请锁，但是没有申请上，处在等待锁的状态【解析】执行如下查询结果postgres=# SELECT * FROM pgxc_lock_conflicts ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | username | gxid | xactstart | queryid | query | pid | mode | granted -----------+----------+----------+---------+-----------------------+----------+------+-------+---------------+-----------+----------+-------------------------------+--------------------+----------------------------------------------------------+-----------------+---------------------+--------- partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 104145741383084190 | alter table table_partition_num_3 truncate partition p1; | 140160505136896 | AccessExclusiveLock | f partition | cn_5001 | postgres | public | table_partition_num_3 | p1 | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 0 | alter table table_partition_num_3 truncate partition p1; | 140160568055552 | AccessExclusiveLock | t relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24102679 | 2022-02-17 18:41:36.580348+08 | 175921860444402398 | truncate xxx; | 140418767369984 | AccessShareLock | f relation | cn_5002 | postgres | public | xxx | | | | | dfm | 24097147 | 2022-02-17 17:56:03.113194+08 | 0 | truncate xxx; | 140420489144064 | AccessExclusiveLock | t (4 rows)如上的SQL显示在节点cn_5001的postgres里面的表public.table_partition_num_3的分区p1上存在分区级别(partition)的锁冲突。在当前的锁冲突中线程140160568055552持有锁(mode = true)，锁级别是AccessExclusiveLock，执行语句为alter table table_partition_num_3 truncate partition p1。线程140160568055552在等待(mode = false)AccessExclusiveLock锁，等待锁的语句也是alter table table_partition_num_3 truncate partition p1。在节点cn_5002的postgres里面的表public.xxx上存在表级别(relation)的锁冲突。线程140420489144064持有锁AccessExclusiveLock(mode = true)，线程140418767369984在等待(mode = false)AccessShareLock锁2）分布式锁等待检测视图pgxc_deadlock【功能】查询当前库里面不同节点上的分布式死锁信息字段名称数据类型字段描述locktypetext被锁定对象的类型，当前支持relation、partition、transactionid三种类型的锁类型nodenamename被锁定对象的节点的名称dbnamename被锁定对象的数据库的名称。如果被锁定对象是事务，则为NULLnspnamename被锁定对象的命名空间的名称relnamename被锁定对象对应的关系的名称。如果被锁定对象既不是关系，也不是关系的一部分，则为NULLpartnamename被锁定对象对应的分区的名称。如果被锁定对象不是分区，则为NULLpageinteger被锁定对象对应的页面的编号。如果被锁定对象既不是页面，也不是元组，则为NULLtuplesmallint被锁定对象对应的元组的编号。如果被锁定对象不是元组，则为NULLtransactionidxid被锁定对象对应的事务的ID。如果被锁定对象不是事务，则为NULLwaitusernamename等待锁的用户的名称waitgxidxid等待锁的事务的IDwaitxactstarttimestamptz等待锁的事务的开始时间waitqueryidbigint等待锁的线程的最新查询IDwaitquerytext等待锁的线程的最新查询语句waitpidbigint等待锁的线程的IDwaitmodetext等待的锁的级别holdusernamename持有锁的用户的名称holdgxidxid持有锁的事务的IDholdxactstarttimestamptz持有锁的事务的开始时间holdqueryidbigint持有锁的线程的最新查询IDholdquerytext持有锁的线程的最新查询语句holdpidbigint持有锁的线程的IDholdmodetext持有的锁的级别【解析】执行如下查询结果postgres=# SELECT * FROM pgxc_deadlock ORDER BY nodename,dbname,locktype,nspname,relname,partname; locktype | nodename | dbname | nspname | relname | partname | page | tuple | transactionid | waitusername | waitgxid | waitxactstart | waitqueryid | waitquery | waitpid | waitmode | holdusername | holdgxid | holdxactstart | holdqueryid | holdquery | holdpid | holdmode ----------+----------+----------+---------+---------+----------+------+-------+---------------+--------------+----------+-------------------------------+--------------------+-----------------------------------------------------+-----------------+-----------------+--------------+----------+-------------------------------+-------------+--------------+-----------------+--------------------- relation | cn_5001 | postgres | public | t2 | | | | | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 104145741383110084 | EXECUTE DIRECT ON(dn_6003_6004) 'SELECT * FROM t2'; | 140160505136896 | AccessShareLock | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 0 | TRUNCATE t2; | 140160421234432 | AccessExclusiveLock relation | cn_5002 | postgres | public | t1 | | | | | j00565968 | 24112465 | 2022-02-17 20:02:24.220656+08 | 175921860444446866 | EXECUTE DIRECT ON(dn_6001_6002) 'SELECT * FROM t1'; | 140418784151296 | AccessShareLock | j00565968 | 24112406 | 2022-02-17 20:01:57.421532+08 | 0 | TRUNCATE t1; | 140421763163904 | AccessExclusiveLock (2 rows)如上的SQL显示，在postgres库里面节点cn_5001上        事务24112465通过线程140160421234432持有表public.t2的AccessExclusiveLock锁        事务24112406通过线程140160505136896在等待申请表public.t2的AccessShareLock锁节点cn_5002上        事务24112465通过线程140418784151296在等待申请表public.t1的AccessShareLock锁        事物24112406通过线程140421763163904持有表public.t1的AccessExclusiveLock锁如果我们把资源的持有情况按照持有到申请定义一个防线的话，可以形成如下表格节点事务24112465方向事务24112406cn_5001持有表public.t2的AccessExclusiveLock锁→申请表public.t2的AccessShareLock锁cn_5002申请表public.t1的AccessShareLock锁←持有表public.t1的AccessExclusiveLock锁从上述可以看出，事务24112465在节点cn_5001持有表public.t2的AccessExclusiveLock锁，等待申请申请表public.t1的AccessShareLock锁；事务24112406在节点cn_5002上持有表public.t1的AccessExclusiveLock锁，等待申请申请表public.t2的AccessShareLock锁；事务24112406和事务24112465只有等待彼此提交才能申请到锁资源，让自己继续执行，这种在多个实例上的分布式等待关系形成了一个环状，我们称这种现象为分布式死锁。3) 锁等待和分布式死锁的区别对于分布式死锁，只能一个事务因为锁等待（参数lockwait_timeout）超时回滚的时候，另外一个事务才能进行下去；或者人工干预kill或者cancel其中一个事务，让另外一个事务进行下去。对于没有分布式死锁的锁等待，这种一般不需要人工干涉，等待持锁事务正常执行完成之后另外一个事务就可以正常执行；但是如果事务持锁时间超过锁等待超时参数（参数lockwait_timeout），等待锁的事务会因为锁等待超时失败。

【功能模块】 //消防类系统        let sql = "select count(distinct(a.id)) sum,a.ConnectStatus ConnectStatus from DE_Devices a,DE_DeviceDef b,DE_DeviceDefCategory c where a.DeviceDef=b.id and c.id=b.DeviceDefCategory and c.name ='PSS-FS' group by a.ConnectStatus";        console.log(sql);        let value = se.execute(sql);在脚本中执行会报错0218 15:40:28.466|error|vm[2044]>>> syntax error: unexpected $unk@useObject(['DE_Devices', 'DE_DeviceDef', 'DE_DeviceDefCategory'])    @action.method({ input: "Input", output: "Output", description: "do a operation" })    run(input: Input): Output {        let output = new Output();        let se = db.sql();        //消防类系统        let sql = "select count(distinct(a.id)) sum,a.ConnectStatus ConnectStatus from DE_Devices a,DE_DeviceDef b,DE_DeviceDefCategory c where a.DeviceDef=b.id and c.id=b.DeviceDefCategory and c.name ='PSS-FS' group by a.ConnectStatus";        console.log(sql);        let value = se.execute(sql);        // let value = se.execute("select * from DE_DeviceDefCategory");        let list = value.Rds;        console.log(list);        return output;    }但是在控制台中执行就没有问题，请问是后台脚本不支持哪些查询么？【操作步骤&问题现象】1、2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

查询历史ql的执行时长，以及执行计划，只能通过历史TopSQL查询吗?还有没有别的方式?

【摘要】 MySQL在实际工作时候的两种数据读写机制：对redo log、binlog这种日志进行的磁盘顺序读写对表空间的磁盘文件里的数据页进行的磁盘随机读写 1 磁盘随机读MySQL执行增删改操作时，先从表空间的磁盘文件里读数据页出来， 这就是磁盘随机读。如下图有个磁盘文件，里面有很多数据页，可能需要在一个随机位置读取一个数据页到缓存，这就是磁盘随机读因你要读取的这个数据页，可能在磁盘的任一位置，所...本文分享自华为云社区《MySQL日志顺序读写及数据文件随机读写原理》，作者：JavaEdge 。MySQL在实际工作时候的两种数据读写机制：对redo log、binlog这种日志进行的磁盘顺序读写对表空间的磁盘文件里的数据页进行的磁盘随机读写1 磁盘随机读MySQL执行增删改操作时，先从表空间的磁盘文件里读数据页出来， 这就是磁盘随机读。如下图有个磁盘文件，里面有很多数据页，可能需要在一个随机位置读取一个数据页到缓存，这就是磁盘随机读因你要读取的这个数据页，可能在磁盘的任一位置，所以你在读取磁盘里的数据页时，只能用随机读。磁盘随机读性能极差，所以不可能每次更新数据都磁盘随机读，而是读取一个数据页之后，放到BP的缓存，下次要更新时，直接更新BP里的缓存页。磁盘随机读的性能指标IOPS底层的存储系统可执行多少次磁盘读写操作/s。压测时可以观察一下。对数据库的crud操作的QPS影响非常大，某种程度上几乎决定了你每秒能执行多少个SQL语句，底层存储的IOPS越高，你的数据库的并发能力就越高。磁盘随机读写操作的响应延迟也是对数据库的性能有很大的影响。假设你的底层磁盘支持你执行200个随机读写操作/s，但每个操作是耗费10ms，还是耗费1ms，也有很大影响， 决定你对数据库执行的单个crud SQL语句的性能。包括你磁盘日志文件的顺序读写的响应延迟，也决定DB性能，因为你写redo log日志文件越快，那你的SQL性能越高。比如你一个SQL语句发过去，磁盘要执行随机读操作加载多个数据页，此时每个磁盘随机读响应时间50ms，可能SQL语句要执行几百ms，但若每个磁盘随机读仅耗10ms，可能你的SQL就执行100ms即可。所以核心业务的数据库的生产环境机器推荐SSD，其随机读写并发能力和响应延迟要比机械硬盘好太多，可大幅提升数据库的QPS和性能。2 磁盘顺序读写当你在BP的缓存页里更新数据后，必须要写条redo log日志，它就是顺序写：在一个磁盘日志文件里，一直在末尾追加日志写redo log时，不停的在一个日志文件末尾追加日志的，这就是磁盘顺序写。磁盘顺序写的性能很高，几乎和内存随机读写的性能差不多，尤其是在DB里也用了os cache机制，就是redo log顺序写入磁盘之前，先是进入os cache，即os管理的内存缓存。对写磁盘日志文件，最关注磁盘每s读写数据量的吞吐量指标即每s可写入多少redo log日志，整体决定DB的并发能力和性能。每s可写入磁盘100M数据和每s可写入磁盘200M数据，对数据库的并发能力影响也大。因为数据库的每次更新SQL，都涉及：多个 磁盘随机读取数据页操作一条redo log日志文件顺序写操作