过滤数据来源于过滤规则产生的候选集，单击“选择”获取过滤的任务别名和UUID。 在线过滤 【去重】物品属性 属性名从画像算子生成，如“product_color”，则对产品颜色相同的物品进行去重。 【去重】忽略长度 截断物品ID末尾指定长度后的字符串进行去重，如指定长度为2，则SKU_A1234和SKU_A1244只会保留其中一个。

查看更多 →

如果临时目录很大，可能存在慢SQL排序、去重等操作导致创建很大的临时表。临时表写入也会造成I/O增加。 您可以在实例监控指标页面查看临时表创建情况。 解决方案 在RDS控制台的慢日志页面，下载并查看执行缓慢的SQL，通过分析慢SQL的执行耗时等信息，从而优化SQL。 下载慢日志的操作，请参见查看或下载慢日志。

查看更多 →

再发送通知，避免产生告警风暴。 告警降噪功能分为分组、去重、抑制、静默四部分。 去重为内置策略，服务后台会自动检验告警内容是否一致实现去重的效果，用户无需手动创建规则。 分组、抑制、静默需手动创建规则，具体的创建方式请参见创建分组规则、创建抑制规则和创建静默规则。 图1 告警降噪流程图

查看更多 →

查询流水线分组树 功能介绍 查询流水线分组树 调用方法 请参见如何调用API。 URI GET /v5/{project_id}/api/pipeline-group/tree 表1 路径参数 参数 是否必选 参数类型 描述 project_id 是 String 项目ID 请求参数

查看更多 →

查询线路分组列表 功能介绍 查询线路分组列表。该接口部分区域未上线、如需使用请提交工单申请开通。 调用方法 请参见如何调用API。 URI GET /v2.1/linegroups 表1 Query参数 参数 是否必选 参数类型 描述 line_id 否 String 线路分组ID。

查看更多 →

:movie) return p limit 100：查询起点label为user，一跳终点为user，二跳终点为movie的路径，并返回前100条。 分组聚集、去重 match (n) return count(*) ：查询全图点的数目。 match (n:user) return

查看更多 →

status like '<表名>'； 查看表上空闲的空间，如果空闲空间过多，可以执行命令optimize table '<表名>' ；整理表空间。 临时表空间过大导致空间不足 原因及现象 半连接(Semi-join)、去重(distinct)、不走索引的排序等操作，会创建临时表，如果涉及的数据量过多，可能导致临时表空间过大。

查看更多 →

排序规则版本函数 pg_collation_actual_version (oid) 描述：返回当前安装在操作系统中的该排序规则对象的实际版本，目前仅对case_insensitive有效。 返回值类型：text 示例： 1 2 3 4 5 6 7 8 9 10

查看更多 →

排序规则版本函数 pg_collation_actual_version (oid) 描述：返回当前安装在操作系统中的该排序规则对象的实际版本，目前仅对case_insensitive有效。 返回值类型：text 示例： 1 2 3 4 5 6 7 8 9 10

查看更多 →

案例：使排序下推 现象描述 在做场景性能测试时，发现某场景大部分时间是CN端在做window agg，占到总执行时间95%以上，系统资源不能充分利用。研究发现该场景的特点是：将两列分别求sum作为一个子查询，外层对两列的和再求和后做trunc，然后排序。 表结构如下所示： 1 2

查看更多 →

容时关闭自动重分布功能，在扩容成功之后再手动使用重分布功能执行重分布任务，在这种分段模式下，扩容和重分布都可以做到失败重试。 当前重分布支持离线重分布和在线重分布两种模式，默认情况下，提交重分布任务时将选择离线重分布模式。 在重分布开始前或重分布暂停过程中，支持对未重分布的表按照schema、表维度设置重分布优先级。

查看更多 →

（可选）调整员工排序 管理员可调整部门人员的排序，置顶某个员工，方便查看关键人员的信息。 在员工管理界面，单击“调整排序”。 拖动员工信息列表到某个位置，进行排序。 在搜索框中，搜索某个员工，单击，可置顶该员工。 父主题： 通讯录

查看更多 →

additional_column_b" 聚合操作有： sum：求和 sum_distinct：去重后求和 avg：均值 avg_distinct：去重后求均值 min：最小值 max：最大值 count：计数 count_distinct：去重后计数 stddev_pop：标准差 stddev_samp：样本标准差

查看更多 →

。 用近似去重（uniqCombined、uniq）替代精确去重。 ClickHouse提供多种近似去重算法，通过count_distinct_implementation配置，支持将countDistinct语法转成所配置的近似算法。查询性能有数量级的提升。 近似算法的误差一般

查看更多 →

all则直接将两个结果集合并、不执行去重。执行去重会消耗大量的时间，因此，在一些实际应用场景中，如果通过业务逻辑已确认两个集合不存在重叠，可用union all替代union以便提升性能。 join列增加非空过滤条件 若join列上的NULL值较多，则可以加上is not null过滤条件，以实现数据的提前过滤，提高join效率。

查看更多 →

all则直接将两个结果集合并、不执行去重。执行去重会消耗大量的时间，因此，在一些实际应用场景中，如果通过业务逻辑已确认两个集合不存在重叠，可用union all替代union以便提升性能。 join列增加非空过滤条件 若join列上的NULL值较多，则可以加上is not null过滤条件，以实现数据的提前过滤，提高join效率。

查看更多 →

够提高SQL执行效率。如果遵守下列规则，常常能够大幅度提升业务查询效率。 使用union all代替union union在合并两个集合时会执行去重操作，而union all则直接将两个结果集合并、不执行去重。执行去重会消耗大量的时间，因此，在一些实际应用场景中，如果通过业务逻辑

查看更多 →

够提高SQL执行效率。如果遵守这些规则，常常能够大幅度提升业务查询效率。 使用union all代替union union在合并两个集合时会执行去重操作，而union all则直接将两个结果集合并、不执行去重。执行去重会消耗大量的时间，因此，在一些实际应用场景中，如果通过业务逻辑

查看更多 →

够提高SQL执行效率。如果遵守这些规则，常常能够大幅度提升业务查询效率。 使用union all代替union union在合并两个集合时会执行去重操作，而union all则直接将两个结果集合并、不执行去重。执行去重会消耗大量的时间，因此，在一些实际应用场景中，如果通过业务逻辑

查看更多 →

够提高SQL执行效率。如果遵守这些规则，常常能够大幅度提升业务查询效率。 使用union all代替union union在合并两个集合时会执行去重操作，而union all则直接将两个结果集合并、不执行去重。执行去重会消耗大量的时间，因此，在一些实际应用场景中，如果通过业务逻辑

查看更多 →

不可用。 避免在SELECT目标列中使用子查询，可能导致计划无法下推到DN执行，影响执行性能。 考虑使用UNION ALL，少使用UNION，注意考虑去重。 UNION ALL不去重，少了排序操作，速度相对UNION更快。 如果没有去重的需求，优先使用UNION ALL。 需要统

查看更多 →