GaussDB怎么实现分页查询？关键字或者函数是什么？

GaussDB支持私有化部署吗？

GaussDB(DWS)分布式数据库的优势，就是利用多DN的资源进行并行计算，提高吞吐量。但有些SQL在这些方面不够注意，导致执行过程中由于全局性操作仅能在一个DN或CN上执行，造成了性能瓶颈。不能下推即属于这一类型问题。GaussDB(DWS)之数据类型转换------转载https://bbs.huaweicloud.com/forum/thread-02107148982213965024-1-1.htmlGaussDB(DWS)之全局性操作------转载https://bbs.huaweicloud.com/forum/thread-02107148983052764025-1-1.htmlGaussDB(DWS)之相关子查询场景------转载https://bbs.huaweicloud.com/forum/thread-0289148983569888018-1-1.htmlGaussDB(DWS)之冗余操作------转载https://bbs.huaweicloud.com/forum/thread-0289148984118868019-1-1.htmlGaussDB(DWS)资源管控方案技术场景分析------转载https://bbs.huaweicloud.com/forum/thread-0205149001764078024-1-1.htmlGaussDB(DWS)资源管控方案规划------转载https://bbs.huaweicloud.com/forum/thread-02107149001853949027-1-1.htmlGaussDB(DWS)资源管控测试验证------转载https://bbs.huaweicloud.com/forum/thread-0229149001940280026-1-1.html双集群系统方案探讨------转载https://bbs.huaweicloud.com/forum/thread-0289149005207821021-1-1.html双ETL模式讲解------转载https://bbs.huaweicloud.com/forum/thread-0208149005370763024-1-1.html数据仓库双活模式-----转载https://bbs.huaweicloud.com/forum/thread-02120149005501809020-1-1.html数据仓库适用场景讲解------转载https://bbs.huaweicloud.com/forum/thread-0208149005593039025-1-1.html【华为云数仓GaussDB(DWS)】SQL语句上线验收操作指导------转载https://bbs.huaweicloud.com/forum/thread-0229149005672975027-1-1.htmlDWS数据库用户权限设计------转载https://bbs.huaweicloud.com/forum/thread-0289149005995152023-1-1.htmlDWS提供的各种权限------转载https://bbs.huaweicloud.com/forum/thread-0205149006113829027-1-1.html基于角色的权限管理模型------转载https://bbs.huaweicloud.com/forum/thread-02107149006249884029-1-1.html

系统中的权限：     系统权限：系统规定用户使用数据库的权限     对象权限：在表、序列、函数等数据库对象上执行特殊动作的权限。借助角色机制：    当给一组权限相同的用户授权时，不需对这些用户逐一授权。    通过将角色付给一个用户可是的该用户拥有这个角色中的所有权限。    一个用户可以属于不同的角色，拥有不同角色的权限。普通模式下：数据库管理员和业务用户（只读用户、只写用户、读写用户）◇ 在角色机制下，角色被视为一个数据库用户或者一组数据库用户。◇  数据库用户主要用途是连接数据库、访问数据库对象和执行SQL语句。◇  通常使用ROLE来组织权限，使用用户进行实际用户操作。◇  角色之间的权限可以继承，用户组的所有用户自动继承角色的权限。角色是权限的集合，权限限制了用户的行为通过为用户分配角色，限定用户的权利范围使用角色管理权限，更加有效使用角色管理其所有用户权限，更加统一角色可以被派生（开启资源管控，层级两层）角色的对象权限集合可以被继承，系统权限无法继承数据库（DATABASE）、用户（USER）、模式（SCHEMA）、表（TABLE）、函数（FUNCTION）、表空间（TABLESPACE）、类型（TYPE）、角色（ROLE）通过系统表字段查看对象权限变化：1、用户mytbl1为用户along1所拥有的表，且表along2对mytbl1有select(r)查询权限。#select relname,relacl from pg_class where relname = 'mytbl1'; relname |                 relacl                 ---------+----------------------------------------- mytbl1  | {along1=arwdDxt/along1,along2=r/along1}2、将mytbl1的插入权限赋给along2。# grant insert on along1.mytbl1 to along2;3、查看到用户along2已经拥有了对mytbl1的insert(a)权限。# select relname,relacl from pg_class where relname = 'mytbl1'; relname |                  relacl                 ---------+------------------------------------------ mytbl1  | {along1=arwdDxt/along1,along2=ar/along1

角色（ROLE）本质上是一组权限的集合，通常情况下使用ROLE来组织权限，使用用户进行权限的管理和业务操作。角色之间的权限可以继承，用户组的所有用户可自动继承对应角色的权限。数据库中USER与ROLE的关系为，USER的权限来自于ROLE。用户组包含了具有相同权限的用户集合。用户可以看作是具有登录权限的角色。角色可以看作是没有登录权限的用户。根据不同业务场景需要，管理员使用 “管控面”创建并管理不同用户组。用户组通过绑定角色获取操作权限，用户加入用户组后，可获得用户组具有的操作权限。用户组同时可以达到对用户进行分类并统一管理多个用户。最大支持5000个用户组（包括系统内置用户组）。DWS提供的权限包括“管控面”和各组件的操作维护权限，在实际应用时需根据业务场景为各用户分别配置不同权限。为了提升权限管理的易用性，“管控面”引入角色的功能，通过选取指定的权限并统一授予角色，以权限集合的形式实现了权限集中查看和管理。这样一方面对普通用户屏蔽了内部的权限管理细节，另一方面对管理员简化了权限管理的操作方法，提升了权限管理的易用性和用户体验。集中权限管理中权限、角色和用户的关系例如图1所示。图1 权限管理与用户关联示意图DWS提供多种权限，根据业务场景实际需要选择指定的权限授予不同角色，可能是一个或者多个权限对应一个角色。角色A：授予操作权限A和B，用户A和用户B通过分配角色A取得对应的权限。角色B：授予操作权限C，用户C通过分配角色B取得对应的权限。角色C：授予操作权限D和F，用户C通过分配角色C取得对应的权限。通过GRANT把角色授予用户后，用户即具有了角色的所有权限。推荐使用角色进行高效权限分配。只对自己的表有所有权限，对其他用户放在属于各自模式下的表无权限。

集群：集群是由一组服务器和其它资源组成的一个单独的系统，可以实现高可用性。有的情况下，可以实现负载均衡及并行处理。数据库：数据库是存储在一起的相关数据的集合，这些数据可以被访问，管理以及更新。一套集群包含一个或多个已命名数据库。用户和角色：用户和角色在整个集群范围内是共享的，但是其数据并不共享。即用户可以连接任何数据库，但当连接成功后，任何用户都只能访问连接请求里声明的那个数据库。模式：数据库对象集，包括逻辑结构，例如表、视图、序、存储过程、同义名、索引、集群及数据库链接。表：表是由行与列组合成的。每一列被当作是一个字段。每个字段中的值代表一种类型的数据。它们之间的关系如下： ​集群中可以创建多个库，库与库之间物理隔离，集群中的用户和角色是唯一并且全局共用的，访问库的权限通过用户进行控制，同一个库中，schema是唯一的，不同schema下可以创建同名表，表与表之间通过schema进行区分，不同用户之间的数据访问通过权限控制进行隔离，不同用户间表的访问权限通过用户进行维护，通过角色进行权限统一管理，一个用户下可创建不同schema区别不同的业务模块，通过不同用户提供给不同业务使用。使用CREATE USER和ALTER USER可以创建和管理数据库用户。数据库集群包含一个或多个已命名数据库。用户和角色在整个集群范围内是共享的，但是其数据并不共享。即用户可以连接任何数据库，但当连接成功后，任何用户都只能访问连接请求里声明的那个数据库。非三权分立下，DWS用户帐户只能由系统管理员或拥有CREATEROLE属性的安全管理员创建和删除。三权分立时，用户帐户只能由初始用户员和安全管理员创建。在用户登录DWS时会对其进行身份验证。用户可以拥有数据库和数据库对象（例如表），并且可以向用户和角色授予对这些对象的权限以控制谁可以访问哪个对象。除系统管理员外，具有CREATEDB属性的用户可以创建数据库并授予对这些数据库的权限。角色是一组用户的集合。通过GRANT把角色授予用户后，用户即具有了角色的所有权限。推荐使用角色进行高效权限分配。例如，可以为设计、开发和维护人员创建不同的角色，将角色GRANT给用户后，再向每个角色中的用户授予其工作所需数据的差异权限。在角色级别授予或撤消权限时，这些更改将作用到角色下的所有成员。Schema又称作模式。通过管理Schema，允许多个用户使用同一数据库而不相互干扰，可以将数据库对象组织成易于管理的逻辑组，同时便于将第三方应用添加到相应的Schema下而不引起冲突。每个数据库包含一个或多个Schema。数据库中的每个Schema包含表和其他类型的对象。数据库创建初始，默认具有一个名为public的Schema，且所有用户都拥有此Schema的权限。可以通过Schema分组数据库对象。Schema类似于操作系统目录，但Schema不能嵌套。相同的数据库对象名称可以应用在同一数据库的不同Schema中，而没有冲突。例如，a_schema和b_schema都可以包含名为mytable的表。具有所需权限的用户可以访问数据库的多个Schema中的对象。

应用开发人员自检工作主要分为两个阶段，包括开发阶段和验收阶段：开发阶段：开发人员严格按照设计规范进行代码开发，并通过验收checklist中的排查方法和标准对所负责模块的SQL进行自检。验收阶段：业务人员进行系统全流程点击，根据第四章【附件3】的方法抓取TOP SQL，按照checklist排查方法验证是否符合验收标准，并汇总输出验收表，详细验收checklist如下所示：DML（Data Manipulation Language数据操作语言），用于对数据库表中的数据进行操作。如：插入、更新、查询、删除，此处的DML语句还包括视图定义、存储过程中的SQL语句。标准1：执行下推&没有stream分布式数据库架构下需最大限度的降低查询时节点之间的数据流动，以提升查询效率，因此SQL语句执行要实现stream算子为0。可通过第四章【附件1】方式查看SQL语句执行计划，从而判断执行计划是否下推，以及是否含有stream算子。（一）判断执行计划是否下推 数据库后台根据第四章【附件3】的方法统计TOP SQL，如果TOP SQL中bxt_count列均为0，表示优化后没有不下推的SQL，验收通过。详细说明：如果执行计划中有Data Node Scan节点，那么此执行计划为不可下推的执行计划；如果执行计划中有Streaming节点，那么计划是可以下推的。下图执行计划信息(红色方框部分)可看出此SQL语句不能下推，这种场景需要分析并消除不下推的因素，具体可查看客户端连接的coordinator实例的日志信息辅助定位分析，并进行优化整改。（二）判断执行计划是否含有stream算子数据库后台根据第四章【附件3】的方法抓取TOP SQL，如果TOP SQL中stream_count列均为0，表示优化后SQL不含有stream算子，验收通过。详细说明：执行计划中含有Streaming(type: Gather)，如果Streaming(type: Gather)下面的计划信息中存在Streaming字符串信息，那么执行计划含有stream算子，否则不含stream算子。（1）如下是含有stream算子的计划(下面的红色方框部分含有Streaming字符串信息)，需要进行SQL改写消除Stream算子。标准2：没有关联子查询数据库后台根据第四章【附件3】的方法抓取TOP SQL，如果TOP SQL中subplan_count列均为0，表示优化后没有关联子查询，验收通过。详细说明：当SQL语句存在不能提升的关联子查询时，执行计划中会显示SubPlan关键字。对于这种场景需要将关联子查询提升为跟父表的关联，消除SubPlan。标准3：有效使用索引关于索引，经常遇到的问题是缺乏索引、索引过滤效果不佳，这两类问题场景可通过第四章【附件2】方式查看SQL语句执行信息进行识别。（一）缺乏索引扫描命中率小于10%的SQL需要添加索引。如下执行信息中，从红色椭圆框可以看到表boss_t_fb_datasourceinfo过滤条件province = '610000' AND type = 'SELECT' AND year = 2019过滤掉2342条记录，最终输出0条记录，这种就是典型的缺乏索引的场景。（二）索引过滤效果不佳如下执行信息中，从红色椭圆框可以看到表epay_t_voucherreceive_log 经过索引index_pki_epay_voucherreceive_log_vouno扫描之后，还需要经过条件vtcode = '5106' AND voucherstatus = 1过滤掉118682个元组，最终输出393条元组，这种就是典型的索引过滤效果不明显的场景，需要进行索引优化。转载：https://mp.weixin.qq.com/s/4u6JVGnJoy5Nboa_GmUAcQ

a） “数据同步模式” – 日志同步技术适用数据变化量小、数据传输压力小的数据场景，通常只适用于小型数据仓库平台；对于规模小的平台，RPO、RTO可以接近0；b） “数据同步模式” – 备份增量同步技术适合大数据量同步场景，实现方式容易被用户理解；往往需要数据库备份工具具备增量备份恢复能力；同时考验备份工具消除相关硬件限制条件，让该技术方案更加灵活；双集群的初始化同步往往采用全备全恢的逻辑实现，可以最大化、最快拉平存量数据；对于规模大的平台，RPO往往需要小时级别，RTO最好水准也在分钟、10分钟以上；同时主集群需要保障一定资源量供数据同步使用，对主集群开销大；c） “数据同步模式” – 逻辑数据同步技术适用灵活同步场景，往往数据同步量不会太大，或同步时间可容忍场景；此场景往往适合于用户对其数据仓库ETL过程元数据信息清晰、完整，依赖客户开发能力，相关同步数据存在清晰ETL算法，结合调度作业运行进度，动态发起相关数据表增、全量同步；对于中等规模的平台，RPO可以做到分钟、半小时，RTO可以维持在分钟级；d） “双ETL模式”需要两套ETL调度环境，整体成本翻倍，但调度逻辑清晰、易于理解和维护；较容易匹配不同规模的数据仓库平台采纳；较难实现数据实时比对，以及数据发生不一致之后的控制逻辑（若需要实现，对于调度逻辑侵入性大）；ETL调度批量中途，较难实现两套调度链路协调重跑；同时数据不一致，依赖于”数据同步模式”技术辅助实施；由于主备调度进行不一致，无法做到主备统一视图展现；若双集群硬件相当，RPO、RTO均可以维持在分钟级别；e） ”双活模式“需要独立中间件、且严重依赖数据库自身厂商，中间件实现难度大；中间件的高可用（稳定性）成为它落地的最大障碍；“双ETL模式”的升级版，能适应各类数据仓库双集群场景；绝大部分场景下，RPO、RTO均可以接近0，特别是双活同时在线能力，不存在双集群的主备切换，RTO可以做到0；同时存在统一视图，不会因为其中一个集群故障，造成前后同一个查询返回结果不一致场景；

b） 双活功能点i.      访问路由能力客户端直接将中间件作为数据库登陆，保持原来登陆逻辑不变；中间件根据登陆用户及附加参数实现拒绝登陆、双系统登陆、或单系统登陆，实现写登陆、读登陆，实现受控方式登陆、或非受控方式登陆；即实现受控和非受控方式的系统读写；同时兼顾考虑异常路由选择或同步路由选择，满足最大化异常执行及少部分同步需求场景；ii.      SQL分发能力经中间件发送的SQL指令，正常发送到相应数据库，并接受数据库响应信息；iii.     批量导入、导出能力针对数据大批量的导入，需要考虑采用更加高效的加载协议进行数据加载，并考虑经中间件复制数据块，异步分发两个数据库；数据导出，需要考虑高效数据导出协议，从其中一套数据库正确导出数据；iv.     更新类SQL校验能力Delete、Update、Insert、Merge等更新类DML SQL进行SQL影响记录数校验；DDL/DCL执行返回码验证一致性能力；v.      对象注册功能通过路由及创建对象的DDL语句，实现对象动态注册；通过命令行指令实现对象注册；适当增加对象索引、约束索引的注册信息，用于扩展细粒度对象锁能力，提高数据仓库ETL SQL并发能力；*数据仓库环境下，只需要考虑到表级双活的能力，不建议实施字段级、记录级双活；vi.     对象锁能力根据SQL指令给相应对象动态加锁、释放锁；同时根据数据库自带的锁特征，至少区分读、写锁控制，以及部分数据库的脏读功能锁；vii.     对象状态控制能力进行管理的多套数据库在线状态控制；进行对象状态控制功能，包含不限于在线、离线、只读、只写、主动中断缓存中、被动中断缓存中、不可用等状态；viii.     缓存能力进行SQL指令流缓存能力，以及缓存恢复执行的能力；进行SQL与加载数据结合缓存、以及缓存恢复执行的能力；ix.      SQL异常控制能力考虑用户体验，始终由返回响应正确的SQL指令返回客户端；两个数据库返回均成功，但返回的影响记录数不一致，则响应慢的数据库对应SQL及涉及对象被设置成不可用状态；若两套数据库其中一套执行成功，另一套执行失败，则执行失败的数据库SQL和涉及对象被设置为被动中断缓存中，同时缓存SQL，定时重试SQL；若两套数据库返回均报错，才通知客户端报错；若SQL涉及对象已处理非在线状态，则新提交的SQL被缓存，新提交SQL相应对象被设置为被动中断缓存中。针对中间件和数据库之间，存在数据库已执行完、但中间件未收到信号场景，需考虑闪环该场景（如增加事务锁等）；ü  主要通过Unity实现多集群SQL、数据分发与管理；ü  Data Mover实现集群间数据同步；ü  Eocsystem Manager实现数据批后自动校验及不一致重同步事件触发；ü  Viewpoint实现系统平台透视图展现与维护，并对接用户告警平台；d） 中间件高可用考虑由于引入了中间件（前置）服务，即该服务的稳定、可靠对双活模式至关重要。数据库单套系统本身已经具备极高的可用性，引入中间件后，由于所有数据库访问行为均通过该中间件，中间件任何异常均同时影响两套数据库访问能力。除了中间件本身所有相关服务需要满足高可用之外，还需考虑极端场景下bypass能力，此项能力在于极端异常条件下，可以保障系统持续服务的能力。高可用场景中，存在控制节点脑裂与自动升主场景，需借鉴仲裁机制减少脑残裂发生；e） 数据重同步考虑即利用“数据同步模式”相关同步技术，实现两套数据库数据重同步能力；f） 不确定值的SQL函数考虑最佳方案，是采用“数据同步模式”的数据日志重同步技术，直接将第一套数据库SQL执行结果的日志信息同步到第二套数据库中，消除返回结果不一致；部分简单的系统时间函数，直接通过中间件改写，保障SQL执行结果一致性；另外，则通过SQL改写，保证row_number函数进行主键或全字段排序，保证SQL执行结果一致性；g） 异常会话重放能力针对异常会话过程的SQL，可能需要从会话建立后，可视化选择，倒回前几个SQL重新执行，并指定过程SQL是否参与结果集校验，以及SQL回放结束的确认动作，让异常场景处理手段更加丰富。

为保证两套ETL调度加载数据源一致及数据复用，往往要求搭建一个数据交换平台。因为至少存在一个文件被两套调度读取，要求数据交换平台两倍过往吞吐能力；且禁止加载的数据文件被二次覆盖，导致两套系统加载不一致； d） 调度依赖顺序考虑 由于ETL作业调度关系没有配置完备，即存在A作业使用B作业的数据，但不配置依赖关系（绝大部分的情况是A作业可容忍B数据的时效，是否最新数据均可以使用，故为时效，业务上不配置依赖关系；当然也存在物理时间上，通常B远远早于A执行），导致两套系统A作业生成数据不一致。该场景下，在一套调度平台无法发现此问题，但存在两套系统的校验比对，即发现数据不一致；该问题建议用户补全依赖关系，确认执行顺序一致性；当然若希望灵活使用依赖关系，则需二次开发，控制两套调度当日时序一致性；e） ETL代码服务器考虑 为了避免两套ETL调度代码维护不一致，需考虑统一维护渠道，包含不限于同一个代码存储源、版本服务器，以及代码变更时机f） 存在不确定值的SQL函数返回 ETL代码中往往存在sample、random、row_number排序这种同一份数据产生不同结果集的函数，造成两套系统数据不一致；该问题建议用户使用替代函数、明确取值、唯一排序，确保最终数据一致性；同时，该设计逻辑正确情况下，哪份数据均可被业务采信，若该数据对下游影响少，可每日批后从主库同步备库，拉平数据；g） 报错修数逻辑考虑 其中一套系统的数据发生报错、修数行为，会涉及到另一套系统的维护行为；可选作法是保留操作逻辑，待另一套系统发生报错时重复执行一次；其它交给数据质量校验（DQC）、数据校验去复查；h） 干预重跑修数逻辑考虑 若批后重跑，两套系统重跑逻辑一致，涉及重复劳动（或支撑平台优化），相对简单；但涉及批量过程中发现部分数据需要重跑，由于两套调度进度不一致，会导致i） 数据校验 i. 校验时机 批后校验，逻辑清晰，对调度依赖少，即根据整体调度进度，做到分层、分库或整体数据校验；准实时校验，即侵入调度环节，在每个作业完成时，均发起日志解析，提取每个SQL影响记录数，若相应作业SQL存在影响记录数不一致场景，即中止较晚完成的调度平台调度后续作业；ii. 校验手段 增全量校验，即针对不同加工逻辑的数据表，区分增、全量数据值，以最小代价覆盖所有业务表iii.   校验方法 通常作法有记录数、汇总值、checksum校验；汇总值校验，通过是数值型字段直接sum、字符型计算字符长度的sum、时间类型则转换成数值相加的比对；Checksum校验，针对全表或部分字段，进行md5或hash运算，完成两套系统一致性比对；对于关系型数据库，校验开销代价逐步递增（记录数 < 汇总值 < checksum校验）；往往是结合增量校验、结合重要指标，区分维度校验，日常增量逻辑校验，定期全量校验，在校验数据一致性和系统性能之间取得平衡点。j） 优化考量 i. 校验改进 即嵌入调度平台，提取ETL代码运行日志，通过执行SQL影响的记录值，实时进行两套系统完成作业日志比对，发现记录值影响，立即停止备库调度，采用人工或自动方式修复数据，继续后续批量。该作法最大好处是，即时发现数据异常，避免问题放大，保障备库更高可用性；ii.   引入统一维护平台 即减少人为双系统维护操作，代码变更平台化，修数逻辑平台化，由平台分别下发两套调度平台、两套数据库。

当前社会、企业运行当中，大数据分析、数据仓库平台已逐渐成为生产、生活的重要地位，不再是一个附属的可有可无的分析系统，外部监控要求、企业内部服务，涌现大批要求7*24小时在线的应用，逐步出现不同等级要求的双集群系统。 数据仓库主流数据库平台均已存在多重高可靠保障措施设计，如硬盘冗余的raid设计、数据表冗余、节点备用冗余、机柜备用数据交叉等，以及加上服务进程高可用冗余设计，其最大化程度满足数据仓库服务持续在线。 但现实场景，如数据库软件缺陷、定期加固补丁、产品迭代、硬件升级这些产品现实因素，以及来自机房、数据中心、地域、网络的外部灾难故障因素，均在降低数据仓库可用性服务水平。 鉴于数据仓库存在大量数据吞吐，针对不同数据库、不同可用性要求，若需要设计双集群冗余设计，可选技术手段分别有数据同步模式、双ETL模式、双活模式，具体探讨如下： 由于数据库IO能力有限、且两个数据库间带宽有限，除了首次全量同步之后，后续通常考虑增量同步技术，即如何准确、高效获取“变化数据”，一般存在日志同步技术、备份增量同步技术、逻辑数据同步； b)日志同步技术 日志同步技术，有业内最著名Oracle Golden Gate，大部分厂家也有自己的实现方式，像Teradata近年来推出Unity CDM（变化数据广播）技术，而我司GaussDB for DWS可采用xlog及page进行变化数据同步。 优势：直接同步变化数据增量，数据量少，要求带宽低，但目前市面技术大都只适合数据每日变化量较少的数据仓库环境；劣势：现实的技术门槛高，应对各类异常场景适应能力差，对主数据库侵入性能要求高，一旦主库繁忙，同步时效低；面对全删全插等变化数据量大场景，同步吃力；c) 备份增量同步技术 主要利用各数据库平台备份恢复能力，进行数据增、全量备份、恢复；通常源库备份数据压缩之后，经网络传输后，解压恢复到目标库；对应GaussDB for DWS可采用roach备份恢复工具实现； 优势：利用同一技术实现增、全量数据同步，逻辑清晰，各场景容错能力强；劣势：要求数据库支持增备能力，且往往锁等待严重；d) 逻辑数据同步 该项主要涉及较高的业务侵入性，即充分获取ETL调度数据流元数据，对应数据库当日数据稳定之后，发起数据表导出-导入操作，针对数据表加工特性，选择增全量同步规则，进行数据准实时同步。 优势：较上述同步技术，可以实现多样选择性同步，同步过程由实施项目本身控制，做到表级数据同步，不需要全系统同步，即可实现部分业务双集群；劣势：客户化同步逻辑，操作前置依赖多，实施投入人力多，较难推广。

(一) 测试SQL样例select count(1) from p#fasp_t_glctrl122299 a,p#fasp_t_glctrl122299   b;打印执行计划如下，cost值大于1000，已按方案设置资源管控的并发控制阈值cost为1000：(二) 交易用户并发验证使用交易用户budget_config_user使用测试SQL样例（cost值大于1000）启动100并发测试使用budget_config_user进行100并发样例SQL验证，当并发数达到50时管控，超过50并发后剩余SQL在管道内排队等待执行(三)报表用户并发验证使用报表用户report_user使用测试SQL样例（cost值大于1000）启动100并发测试使用report_user进行100并发样例SQL验证，当并发数达到20时管控，超过20并发后剩余SQL在管道内排队，等待执行。(四) 报表用户和交易用户同时并发验证分别使用交易用户budget_config_user和报表用户report_user使用测试SQL样例（cost值大于1000）分别启动100并发测试使用budget_config_user和report_user分别进行100并发样例SQL验证，交易用户并发50受控，报表用户并发20受控。(五)报表用户限额CPU验证使用报表用户report_user使用测试SQL样例（cost值大于1000）启动100并发测试CPU限额设置20%，使用report_user进行100并发样例SQL验证，CPU使用达到20%时进行资源管控。(六)交易用户配额CPU验证使用交易用户budget_config_user使用测试SQL样例（cost值大于1000）启动100并发测试在配额60%CPU的情况下，CPU使用可以超过60%，不进行CPU强制限制（这点与限额不同），业务高峰时可以根据业务情况弹性扩展。转载：https://mp.weixin.qq.com/s/VlT9u3JFYN4hwDnUofvH_A

(一) 静态资源池规划静态资源池可以控制数据库能使用服务器资源的上限，由于服务器操作系统运行也需要消耗一定的资源，因此预留一定的服务器资源来保障操作系统的正常运行。推荐静态资源池配置：数据库分配93% CPU资源和70% 内存资源。这样可以保证服务器能够正常响应系统请求。静态资源池分配93% CPU资源和70% 内存资源。(二)交易用户和报表用户分离报表分析类业务的优先级和实时性相对较低，但是复杂度更高，为有效进行资源管控，将报表分析和核心交易业务进行数据库用户分离，例如核心交易业务使用数据库用户budget_config_user，报表分析业务使用数据库用户report_user。针对交易用户和报表用户分别进行CPU资源和并发数控制以保障数据库稳定运行。   结合报表分析业务的负载调研、日常监控和测试验证，20并发以内的复杂报表SQL不会引起服务器资源争抢，不会引起业务系统卡慢，因此配置报表用户最多使用20%的CPU资源。   结合核心交易业务的的负载调研、日常监控和测试验证，50并发以内的复杂SQL不会对系统造成持续压力，整体CPU负载小于60%。交易用户分配60%的CPU配额和50并发。报表用户分配20%的CPU限额和20并发。其中CPU配额是指占用CPU时间片的百分比。若分配给某个用户的CPU配额资源未使用，系统会自动将这些资源共享给其他用户。CPU限额是指用户可以使用的CPU核数的百分比。系统会将百分比换算成具体的核数供用户使用，且用户可使用的CPU限额资源不超过通过百分比换算的核数范围。(三)  并发管控阈值设置   资源管控的并发控制是基于SQL的cost值（SQL执行代价）来评估，结合客户场景、硬件配置和SQL测试分析，当SQL的cost值小于1000时，SQL并发对服务器不构成持续压力，短时间内可执行完成，不会造成业务堆积。当SQL的cost值大于1000时，大量并发会导致服务器资源争抢，引起系统卡慢。因此将受控SQL的cost的临界值设置为1000。当SQL的cost值大于1000时受资源管控的并发度控制，当SQL的cost值小于1000时不受资源管控的并发度控制。区分SQL复杂和简单的cost值设置为1000

项目交付中可能会遇到同时包含核心交易（OLTP）和报表分析（OLAP）的混合业务场景，其中报表分析类业务复杂度高，消耗大量系统资源，但实时性要求较低，而核心交易类业务并发较大，多为简单事务处理，对实时性要求高。当系统处于业务高峰时，报表分析类业务并发操作会加剧系统负载，且长时间占用资源无法释放，最终可能导致整体性能裂化，实时性要求较高的核心交易类业务因资源争抢而无法得到响应，从而影响客户整体体验。资源管控的目的是基于业务场景和可用资源，进行合理的资源与并发度管控，以保障数据库可以在高负载场景下正常运行，不会因为资源争抢和耗尽出现系统卡死，提升系统整体吞吐量。业务场景主要分为核心交易（OLTP）和报表分析（OLAP）两大类，其中报表服务的优先级相对较低，在合理的情况下优先保障业务系统的正常运行。业务系统中运行的SQL分为简单SQL和复杂SQL，大量复杂SQL的并发执行会导致数据库服务器资源争抢，简单SQL的大量并发对服务器不构成持续压力，短时间内可执行完成，不会造成业务堆积。其中报表服务中运行的SQL以复杂SQL居多，整体业务逻辑相对复杂，在数据库层面需要分别对核心交易和报表服务进行合理的资源管控，以保障业务系统正常运行。

通常情况下，会生成基表扫描的查询计划，即对于customer表的每一条，需要检查c_customer_sk列是否会和IN list中的某个值匹配，匹配即返回该条元组。当IN list中的条件比较多时，匹配近似于NestLoop的操作。针对这种场景，GaussDB(DWS)实现了In list to Join的查询优化规则，根据代价估算，针对In list中的值较多的场景，生成Hash Join的计划，极大提升性能，如下图所示：但代价估算存在估算不准的情况，对于列存表有min/max过滤，有时转成Join并不一定性能最好，因此我们增加了GUC参数：qrw_inlist2join_optmode，用户可以手动设置该参数的值进行调优，其值说明如下：a)   cost_base，即根据代价估算，默认值。b)   rule_base，强制使用转换成Join的优化规则。c)   不小于2的整数，表示当In list中的常量个数不小于N时，使用转换成Join的优化规则。在GaussDB(DWS)场景中，经常会遇到一类SQL，其中存在大量的冗余操作，导致执行时进行了大量无效计算。这类语句的场景很多，需要根据performance数据详细分析，以下举几个例子简单看一下。（1）语句中存在大量冗余case when语句的场景例如如下语句，语句中有大量case when语句，大多数条件都是一样的，只是default值存在不同，但执行时，每个分支的case when均需要执行，导致时间成倍增加。这种情况下需要对语句进行深入分析，根据语义进行等价改写。通常我们可以把case when加到过滤条件，分成多个子查询分别求值，或提取公共部分进行改写。经过优化后，消除了case when，性能得到了提升，修改后的语句如下所示。我们发现对所有的数据进行了排序，然后返回了前10条数据，数据量较大时，所有数据量全排将大量耗费时间。这种情况下，我们可以在子查询中加入limit语句，这样排序变为top N排序，减少了排序的时间，修改后的语句为：select a from (select a, row_number() over (order by a desc) rid from t1 limit <end>-<start>+1 offset <start>-1) where rid between 1 and 10;在GaussDB(DWS)场景中，通常为分析类应用，最终均需要进行聚集操作。通常聚集都是在语句最后进行，起到去重统计的效果。但是，如果去重前的重复值较多，但会显著影响关联的性能，如SQL语句：select t1.c1, count(*) from t1 join t2 on t1.c1=t2.c1 group by t1.c1;我们称这个改写规则为Eager Agg，相反，如果改写后的语句，在子查询中的Agg去重效果不明显，但耗时较长，则可以做反向改写，去除冗余的Agg操作，我们称之为Lazy Agg。转载：https://mp.weixin.qq.com/s/Jy27HVRIIuEXddrifXFlFw