首页 文章 精选 留言 我的

精选列表

搜索[智能扫码],共10007篇文章
优秀的个人博客,低调大师

老码农眼中的Agent Skill

如果你写的Skill没有被执行,从来不是因为没有指令,而是因为描述不当。这就是大多数人在经历一个小时的沮丧后才会想通的事情。你写了一个 Skill.md,把它放在正确的文件夹里,让Agent使用它,但什么也没发生。你重新写了文档,仍然什么也没发生。问题从来就不在于你在 Skill 内部写了什么,而是Agent用来决定是否要激活它的最上面两行。

优秀的个人博客,低调大师

中国码农的“35岁魔咒”

34 岁的老白在短视频应用快手的工作岌岌可危的第一个迹象,是其一位 35 岁同事被解雇。 “既震惊又焦虑,” 老白说,他使用昵称以免遭到前雇主的报复。这位开发人员距离 35 岁生日只有几个月,就被解雇了,成为公司内部称为“石灰石”的重组的又一个牺牲品。据五名前任和现任员工透露,快手正在推出 35 岁左右的初级员工。快手被告知,他的解雇是公司整体裁员计划的一部分。快手拒绝置评。 所谓“35 岁门槛”长期困扰着白领职业的工人,人们普遍认为年长的员工由于家庭责任而更不愿意加班。 随着中国科技行业因北京的监管整顿和经济放缓而陷入困境,过去几个月来数以万计的就业岗位被裁撤,中年员工被认为尤其脆弱。科技公司毫不掩饰地更青睐年轻和未婚的员工。 “科技行业中的年龄歧视是一个大问题,”总部位于北京的劳工律师杨宝泉说,“一种观点认为,年长的员工无法跟上最新的技术发展,他们没有精力继续努力工作,而且他们太贵了。” 虽然中国劳动法禁止雇主基于种族、性别和宗教等属性歧视员工,但并未明确提及年龄。但杨律师表示,一些人将该法律解释得更广泛,禁止歧视老年人,这意味着雇主不会明确引用年龄作为解雇理由。 中国科技公司的高管们长期以来公开表示他们更喜欢年轻员工。2019 年,腾讯总裁刘炽平宣布了一项重组公司 10% 管理人员的计划,称“他们的工作将由更年轻的人、可能更富有激情的新同事接替”。百度首席执行官李彦宏在 2019 年的一封内部信中 (也于当年公开) 宣布了公司“通过提拔更多 1980 年后和 1990 年后出生的员工变得更加年轻” 的计划。 这种想法在大多数科技公司根深蒂固。 “20 到 30 岁之间,大多数人精力充沛。你更愿意为公司勇往直前、牺牲自己。但是一旦你成为父母,身体开始老化,你将如何跟上 996 的工作日程?” 一名前美团销售经理说,他指的是中国科技行业臭名昭著的每周工作六天,早上 9 点到晚上 9 点的工作制度。 数据显示, 字节跳动和电子商务巨头拼多多是中国科技公司中最年轻的招聘公司之一。据职场社交网站脉脉 2020 年的最新数据,其员工的平均年龄为 27 岁。脉脉数据还显示,快手员工的平均年龄为 28 岁,滴滴出行员工的平均年龄为 33 岁。据中华全国总工会统计,中国劳动者的平均年龄为 38.3 岁。 随着科技行业一波又一波的裁员潮(由经济放缓和监管问题驱动),这种趋势变得更加根深蒂固。 快手自 2021 年在香港上市以来的股价已下跌 88%,根据其最新财报,其员工总数在 2021 年 12 月(当时拥有 2.8 万名员工)和 2023 年 6 月之间减少了 16%。 “科技行业在疫情之前扩张得太快,然后政府的监管整顿开始了。我们现在正在削减昂贵的中层管理人员,” 另一家互联网公司的一位经理说。 “35 岁门槛” 是科技工作者焦虑的主要来源。招聘平台拉勾找聘去年的一项调查发现,87% 的程序员“非常担心”在 35 岁之后被解雇或找不到新工作。 杨律师表示,35 岁以上的人失业后很难找到新工作。 中国许多公务部门的录用考试都将年龄限制在 35 岁以下。服务行业(包括餐馆和酒店)的招聘广告也更想要年轻的求职者。这使得 30 多岁的科技员工在更换职业或在职位之间寻找临时工作机会时几乎没有选择余地。 一位 38 岁的程序员最近从一家主要叫车集团被解雇,他说找新工作很困难。“就业市场非常糟糕,甚至比去年还要糟糕,尤其是对我这样的老工程师来说,”他说。 最终,老白觉得自己是幸运的少数人之一。 “我有两个孩子,我的妻子不再工作。当时另一家科技公司只招聘一个管理职位,我很幸运地得到了它。如果没有这个机会,我就会像许多前快手员工一样失业。” 本文转载自 煎蛋,译者:BALI 英文原文:FT

优秀的个人博客,低调大师

码农必备SQL调优(下)

目录 1. Plan Hint调优概述 2. Join顺序的Hint 3. Join方式的Hint 4. 行数的Hint 5. Scan方式的Hint 6. 子链接块名的hint 7. Hint的错误、冲突及告警 8. 优化器GUC参数的Hint 9. Custom Plan和Generic Plan选择的Hint 10. 指定子查询不展开的Hint 11. 指定不使用全局计划缓存的Hint 12. 同层参数化路径的Hint 1. Plan Hint调优概述 Plan Hint为用户提供了直接影响执行计划生成的手段,用户可以通过指定join顺序、join、scan方法、指定结果行数等多个手段来进行执行计划的调优,以提升查询的性能。 功能描述 Plan Hint支持在SELECT关键字后通过如下形式指定: /*+ <plan hint>*/ 可以同时指定多个hint,之间使用空格分隔。hint只能hint当前层的计划,对于子查询计划的hint,需要在子查询的select关键字后指定hint。 例如: select /*+ <plan_hint1> <plan_hint2> */ * from t1, (select /*+ <plan_hint3> */ from t2) where 1=1; 其中,为外层查询的hint,为内层子查询的hint。 须知: 如果在视图定义(CREATE VIEW)时指定hint,则在该视图每次被应用时会使用该hint。 当使用random plan功能(参数plan_mode_seed不为0)时,查询指定的plan hint不会被使用。 支持范围 当前版本Plan Hint支持的范围如下,后续版本会进行增强。 指定Join顺序的Hint - leading hint 指定Join方式的Hint,仅支持除semi/anti join、unique plan之外的常用hint。 指定结果集行数的Hint 指定Scan方式的Hint,仅支持常用的tablescan、indexscan和indexonlyscan的hint。 指定子链接块名的Hint 注意事项 不支持Agg、Sort、Setop和Subplan的hint。 示例 本章节使用同一个语句进行示例,便于Plan Hint支持的各方法作对比,示例语句及不带hint的原计划如下所示: create table store ( s_store_sk integer not null, s_store_id char(16) not null, s_rec_start_date date , s_rec_end_date date , s_closed_date_sk integer , s_store_name varchar(50) , s_number_employees integer , s_floor_space integer , s_hours char(20) , s_manager varchar(40) , s_market_id integer , s_geography_class varchar(100) , s_market_desc varchar(100) , s_market_manager varchar(40) , s_division_id integer , s_division_name varchar(50) , s_company_id integer , s_company_name varchar(50) , s_street_number varchar(10) , s_street_name varchar(60) , s_street_type char(15) , s_suite_number char(10) , s_city varchar(60) , s_county varchar(30) , s_state char(2) , s_zip char(10) , s_country varchar(20) , s_gmt_offset decimal(5,2) , s_tax_precentage decimal(5,2) , primary key (s_store_sk) ); create table store_sales ( ss_sold_date_sk integer , ss_sold_time_sk integer , ss_item_sk integer not null, ss_customer_sk integer , ss_cdemo_sk integer , ss_hdemo_sk integer , ss_addr_sk integer , ss_store_sk integer , ss_promo_sk integer , ss_ticket_number integer not null, ss_quantity integer , ss_wholesale_cost decimal(7,2) , ss_list_price decimal(7,2) , ss_sales_price decimal(7,2) , ss_ext_discount_amt decimal(7,2) , ss_ext_sales_price decimal(7,2) , ss_ext_wholesale_cost decimal(7,2) , ss_ext_list_price decimal(7,2) , ss_ext_tax decimal(7,2) , ss_coupon_amt decimal(7,2) , ss_net_paid decimal(7,2) , ss_net_paid_inc_tax decimal(7,2) , ss_net_profit decimal(7,2) , primary key (ss_item_sk, ss_ticket_number) ); create table store_returns ( sr_returned_date_sk integer , sr_return_time_sk integer , sr_item_sk integer not null, sr_customer_sk integer , sr_cdemo_sk integer , sr_hdemo_sk integer , sr_addr_sk integer , sr_store_sk integer , sr_reason_sk integer , sr_ticket_number integer not null, sr_return_quantity integer , sr_return_amt decimal(7,2) , sr_return_tax decimal(7,2) , sr_return_amt_inc_tax decimal(7,2) , sr_fee decimal(7,2) , sr_return_ship_cost decimal(7,2) , sr_refunded_cash decimal(7,2) , sr_reversed_charge decimal(7,2) , sr_store_credit decimal(7,2) , sr_net_loss decimal(7,2) , primary key (sr_item_sk, sr_ticket_number) ); create table customer ( c_customer_sk integer not null, c_customer_id char(16) not null, c_current_cdemo_sk integer , c_current_hdemo_sk integer , c_current_addr_sk integer , c_first_shipto_date_sk integer , c_first_sales_date_sk integer , c_salutation char(10) , c_first_name char(20) , c_last_name char(30) , c_preferred_cust_flag char(1) , c_birth_day integer , c_birth_month integer , c_birth_year integer , c_birth_country varchar(20) , c_login char(13) , c_email_address char(50) , c_last_review_date char(10) , primary key (c_customer_sk) ); create table promotion ( p_promo_sk integer not null, p_promo_id char(16) not null, p_start_date_sk integer , p_end_date_sk integer , p_item_sk integer , p_cost decimal(15,2) , p_response_target integer , p_promo_name char(50) , p_channel_dmail char(1) , p_channel_email char(1) , p_channel_catalog char(1) , p_channel_tv char(1) , p_channel_radio char(1) , p_channel_press char(1) , p_channel_event char(1) , p_channel_demo char(1) , p_channel_details varchar(100) , p_purpose char(15) , p_discount_active char(1) , primary key (p_promo_sk) ); create table customer_address ( ca_address_sk integer not null, ca_address_id char(16) not null, ca_street_number char(10) , ca_street_name varchar(60) , ca_street_type char(15) , ca_suite_number char(10) , ca_city varchar(60) , ca_county varchar(30) , ca_state char(2) , ca_zip char(10) , ca_country varchar(20) , ca_gmt_offset decimal(5,2) , ca_location_type char(20) , primary key (ca_address_sk) ); create table item ( i_item_sk integer not null, i_item_id char(16) not null, i_rec_start_date date , i_rec_end_date date , i_item_desc varchar(200) , i_current_price decimal(7,2) , i_wholesale_cost decimal(7,2) , i_brand_id integer , i_brand char(50) , i_class_id integer , i_class char(50) , i_category_id integer , i_category char(50) , i_manufact_id integer , i_manufact char(50) , i_size char(20) , i_formulation char(20) , i_color char(20) , i_units char(10) , i_container char(10) , i_manager_id integer , i_product_name char(50) , primary key (i_item_sk) ); explain select i_product_name product_name ,i_item_sk item_sk ,s_store_name store_name ,s_zip store_zip ,ad2.ca_street_number c_street_number ,ad2.ca_street_name c_street_name ,ad2.ca_city c_city ,ad2.ca_zip c_zip ,count(*) cnt ,sum(ss_wholesale_cost) s1 ,sum(ss_list_price) s2 ,sum(ss_coupon_amt) s3 FROM store_sales ,store_returns ,store ,customer ,promotion ,customer_address ad2 ,item WHERE ss_store_sk = s_store_sk AND ss_customer_sk = c_customer_sk AND ss_item_sk = i_item_sk and ss_item_sk = sr_item_sk and ss_ticket_number = sr_ticket_number and c_current_addr_sk = ad2.ca_address_sk and ss_promo_sk = p_promo_sk and i_color in ('maroon','burnished','dim','steel','navajo','chocolate') and i_current_price between 35 and 35 + 10 and i_current_price between 35 + 1 and 35 + 15 group by i_product_name ,i_item_sk ,s_store_name ,s_zip ,ad2.ca_street_number ,ad2.ca_street_name ,ad2.ca_city ,ad2.ca_zip ; 2. Join顺序的Hint 功能描述 指明join的顺序,包括内外表顺序。 语法格式 仅指定join顺序,不指定内外表顺序。 leading(join_table_list) 同时指定join顺序和内外表顺序,内外表顺序仅在最外层生效。 leading((join_table_list)) 参数说明 join_table_list为表示表join顺序的hint字符串,可以包含当前层的任意个表(别名),或对于子查询提升的场景,也可以包含子查询的hint别名,同时任意表可以使用括号指定优先级,表之间使用空格分隔。 须知: 表只能用单个字符串表示,不能带schema。 表如果存在别名,需要优先使用别名来表示该表。 join table list中指定的表需要满足以下要求,否则会报语义错误。 list中的表必须在当前层或提升的子查询中存在。 list中的表在当前层或提升的子查询中必须是唯一的。如果不唯一,需要使用不同的别名进行区分。 同一个表只能在list里出现一次。 如果表存在别名,则list中的表需要使用别名。 例如: leading(t1 t2 t3 t4 t5)表示:t1、t2、t3、t4、t5先join,五表join顺序及内外表不限。 leading((t1 t2 t3 t4 t5))表示:t1和t2先join,t2做内表;再和t3 join,t3做内表;再和t4 join,t4做内表;再和t5 join,t5做内表。 leading(t1 (t2 t3 t4) t5)表示:t2、t3、t4先join,内外表不限;再和t1、t5 join,内外表不限。 leading((t1 (t2 t3 t4) t5))表示:t2、t3、t4先join,内外表不限;在最外层,t1再和t2、t3、t4的join表join,t1为外表,再和t5 join,t5为内表。 leading((t1 (t2 t3) t4 t5)) leading((t3 t2))表示:t2、t3先join,t2做内表;然后再和t1 join,t2、t3的join表做内表;然后再依次跟t4、t5做join,t4、t5做内表。 示例 对sh示例对中原语句使用如下hint: explain select /*+ leading((((((store_sales store) promotion) item) customer) ad2) store_returns) leading((store store_sales))*/ i_product_name product_name ... 该hint表示:表之间的join关系是:store_sales和store先join,store_sales做内表,然后依次跟promotion, item, customer, ad2, store_returns做join。生成计划如下所示: 图中计划顶端warning的提示详见Hint的错误、冲突及告警的说明。 3. Join方式的Hint 功能描述 指明Join使用的方法,可以为Nested Loop、Hash Join和Merge Join。 语法格式 [no] nestloop|hashjoin|mergejoin(table_list) 参数说明 no表示hint的join方式不使用。 table_list为表示hint表集合的字符串,该字符串中的表与join_table_list相同,只是中间不允许出现括号指定join的优先级。 例如: no nestloop(t1 t2 t3)表示:生成t1、t2、t3三表连接计划时,不使用nestloop。三表连接计划可能是t2 t3先join,再跟t1 join,或t1 t2先join,再跟t3 join。此hint只hint最后一次join的join方式,对于两表连接的方法不hint。如果需要,可以单独指定,例如:任意表均不允许nestloop连接,且希望t2 t3先join,则增加hint:no nestloop(t2 t3)。 示例 对示例中原语句使用如下hint: explain select /*+ nestloop(store_sales store_returns item) */ i_product_name product_name ... 该hint表示:生成store_sales、store_returns和item三表的结果集时,最后的两表关联使用nestloop。生成计划如下所示: 4. 行数的Hint 功能描述 指明中间结果集的大小,支持绝对值和相对值的hint。 语法格式 rows(table_list #|+|-|* const) 参数说明 #、+、-、*,进行行数估算hint的四种操作符号。#表示直接使用后面的行数进行hint。+、-、*表示对原来估算的行数进行加、减、乘操作,运算后的行数最小值为1行。table_list为hint对应的单表或多表join结果集,与Join方式的Hint中table_list相同。 const可以是任意非负数,支持科学计数法。 例如: rows(t1 #5)表示:指定t1表的结果集为5行。 rows(t1 t2 t3 *1000)表示:指定t1、 t2、t3 join完的结果集的行数乘以1000。 建议 推荐使用两个表*的hint。对于两个表的采用*操作符的hint,只要两个表出现在join的两端,都会触发hint。例如:设置hint为rows(t1 t2 * 3),对于(t1 t3 t4)和(t2 t5 t6)join时,由于t1和t2出现在join的两端,所以其join的结果集也会应用该hint规则乘以3。 rows hint支持在单表、多表、function table及subquery scan table的结果集上指定hint。 示例 对示例中原语句使用如下hint: explain select /*+ rows(store_sales store_returns *50) */ i_product_name product_name ... 该hint表示:store_sales、store_returns关联的结果集估算行数在原估算行数基础上乘以50。生成计划如下所示: 5. Scan方式的Hint 功能描述 指明scan使用的方法,可以是tablescan、indexscan和indexonlyscan。 语法格式 [no] tablescan|indexscan|indexonlyscan(table [index]) 参数说明 no表示hint的scan方式不使用。 table表示hint指定的表,只能指定一个表,如果表存在别名应优先使用别名进行hint。 index表示使用indexscan或indexonlyscan的hint时,指定的索引名称,当前只能指定一个。 说明: 对于indexscan或indexonlyscan,只有hint的索引属于hint的表时,才能使用该hint。 scan hint支持在行列存表、obs表、子查询表上指定。 示例 为了hint使用索引扫描,需要首先在表item的i_item_sk列上创建索引,名称为i。 create index i on item(i_item_sk); 对示例中原语句使用如下hint: explain select /*+ indexscan(item i) */ i_product_name product_name ... 该hint表示:item表使用索引i进行扫描。生成计划如下所示: 6. 子链接块名的hint 功能描述 指明子链接块的名称。 语法格式 blockname (table) 参数说明 table表示为该子链接块hint的别名的名称。 说明: -blockname hint仅在对应的子链接块没有提升时才会被上层查询使用。目前支持的子链接提升包括IN子链接提升、EXISTS子链接提升和包含Agg等值相关子链接提升。该hint通常会和前面章节提到的hint联合使用。 - 对于FROM关键字后的子查询,则需要使用子查询的别名进行hint,blockname hint不会被用到。 - 如果子链接中含有多个表,则提升后这些表可与外层表以任意优化顺序连接,hint也不会被用到。 示例 explain select /*+nestloop(store_sales tt) */ * from store_sales where ss_item_sk in (select /*+blockname(tt)*/ i_item_sk from item group by 1); 该hint表示:子链接的别名为tt,提升后与上层的store_sales表关联时使用nestloop。生成计划如下所示: 7. Hint的错误、冲突及告警 Plan Hint的结果会体现在计划的变化上,可以通过explain来查看变化。 Hint中的错误不会影响语句的执行,只是不能生效,该错误会根据语句类型以不同方式提示用户。对于explain语句,hint的错误会以warning形式显示在界面上,对于非explain语句,会以debug1级别日志显示在日志中,关键字为PLANHINT。 hint的错误分为以下类型: 语法错误 语法规则树归约失败,会报错,指出出错的位置。 例如:hint关键字错误,leading hint或join hint指定2个表以下,其它hint未指定表等。一旦发现语法错误,则立即终止hint的解析,所以此时只有错误前面的解析完的hint有效。 例如: leading((t1 t2)) nestloop(t1) rows(t1 t2 #10) nestloop(t1)存在语法错误,则终止解析,可用hint只有之前解析的leading((t1 t2))。 语义错误 表不存在,存在多个,或在leading或join中出现多次,均会报语义错误。 scanhint中的index不存在,会报语义错误。 另外,如果子查询提升后,同一层出现多个名称相同的表,且其中某个表需要被hint,hint会存在歧义,无法使用,需要为相同表增加别名规避。 hint重复或冲突 如果存在hint重复或冲突,只有第一个hint生效,其它hint均会失效,会给出提示。 hint重复是指,hint的方法及表名均相同。例如:nestloop(t1 t2) nestloop(t1 t2)。 hint冲突是指,table list一样的hint,存在不一样的hint,hint的冲突仅对于每一类hint方法检测冲突。 例如:nestloop (t1 t2) hashjoin (t1 t2),则后面与前面冲突,此时hashjoin的hint失效。注意:nestloop(t1 t2)和no mergejoin(t1 t2)不冲突。 须知: leading hint中的多个表会进行拆解。例如:leading ((t1 t2 t3))会拆解成:leading((t1 t2)) leading(((t1 t2) t3)),此时如果存在leading((t2 t1)),则两者冲突,后面的会被丢弃。(例外:指定内外表的hint若与不指定内外表的hint重复,则始终丢弃不指定内外表的hint。) 子链接提升后hint失效 子链接提升后的hint失效,会给出提示。通常出现在子链接中存在多个表连接的场景。提升后,子链接中的多个表不再作为一个整体出现在join中。 列类型不支持重分布 对于skew hint来说,目的是为了进行重分布时的调优,所以当hint列的类型不支持重分布时,hint将无效。 hint未被使用 非等值join使用hashjoin hint或mergejoin hint。 不包含索引的表使用indexscan hint或indexonlyscan hint。 通常只有在索引列上使用过滤条件才会生成相应的索引路径,全表扫描将不会使用索引,因此使用indexscan hint或indexonlyscan hint将不会使用。 indexonlyscan只有输出列仅包含索引列才会使用,否则指定时hint不会被使用。 多个表存在等值连接时,仅尝试有等值连接条件的表的连接,此时没有关联条件的表之间的路径将不会生成,所以指定相应的leading、join、rows hint将不使用,例如:t1 t2 t3表join,t1和t2,t2和t3有等值连接条件,则t1和t3不会优先连接,leading(t1 t3)不会被使用。 生成stream计划时,如果表的分布列与join列相同,则不会生成redistribute的计划;如果不同,且另一表分布列与join列相同,只能生成redistribute的计划,不会生成broadcast的计划,指定相应的hint则不会被使用。 如果子链接未被提升,则blockname hint不会被使用。 对于skew hint,hint未被使用可能由于: 计划中不需要进行重分布。 hint指定的列为包含分布键。 hint指定倾斜信息有误或不完整,如对于join优化未指定值。 倾斜优化的GUC参数处于关闭状态。 8. 优化器GUC参数的Hint 功能描述 设置本次查询执行内生效的查询优化相关GUC参数。hint的推荐使用场景可以参考各guc参数的说明,此处不作赘述。 语法格式 set(param value) 参数说明 param表示参数名。 value表示参数的取值。 目前支持使用Hint设置生效的参数有 布尔类: enable_bitmapscan、enable_hashagg、enable_hashjoin、enable_indexscan、enable_indexonlyscan、enable_material、enable_mergejoin、enable_nestloop、enable_index_nestloop、enable_seqscan、enable_sort、enable_tidscan 整形类: query_dop 浮点类: cost_weight_index、default_limit_rows、seq_page_cost、random_page_cost、cpu_tuple_cost、cpu_index_tuple_cost、cpu_operator_cost、effective_cache_size 枚举类型: try_vector_engine_strategy 说明: - 设置不在白名单中的参数,参数取值不合法,或hint语法错误时,不会影响查询执行的正确性。使用explain(verbose on)执行可以看到hint解析错误的报错提示。 - GUC参数的hint只在最外层查询生效——子查询内的GUC参数hint不生效。 - 视图定义内的GUC参数hint不生效。 - CREATE TABLE … AS … 查询最外层的GUC参数hint可以生效。 9. Custom Plan和Generic Plan选择的Hint 功能描述 对于以PBE方式执行的查询语句和DML语句,优化器会基于规则、代价、参数等因素选择生成Custom Plan或Generic Plan执行。用户可以通过use_cplan/use_gplan的hint指定使用哪种计划执行方式。 语法格式 指定使用Custom Plan: use_cplan 指定使用Generic Plan: use_gplan 说明:- 对于非PBE方式执行的SQL语句,设置本hint不会影响执行方式。 - 本Hint的优先级仅高于基于代价的选择和plan_cache_mode参数,即plan_cache_mode无法强制选择执行方式的语句本hint也无法生效。 示例 强制使用Custom Plan create table t (a int, b int, c int); prepare p as select /*+ use_cplan */ * from t where a = $1; explain execute p(1); 可以看到过滤条件为入参的实际值,即此计划为Custom Plan。 强制使用Generic Plan deallocate p; prepare p as select /*+ use_gplan */ * from t where a = $1; explain execute p(1); 可以看到过滤条件为待填充的入参,即此计划为Generic Plan。 10. 指定子查询不展开的Hint 功能描述 数据库在对查询进行逻辑优化时通常会将可以提升的子查询提升到上层来避免嵌套执行,但对于某些本身选择率较低且可以使用索引过滤访问页面的子查询,嵌套执行不会导致性能下降过多,而提升之后扩大了查询路径的搜索范围,可能导致性能变差。对于此类情况,可以使用no_expand Hint进行调试。大多数情况下不建议使用此hint。 语法格式 no_expand 示例 正常的查询执行 explain select * from t1 where t1.a in (select t2.a from t2); 加入no_expand explain select * from t1 where t1.a in (select /*+ no_expand*/ t2.a from t2); 11. 指定不使用全局计划缓存的Hint 功能描述 全局计划缓存打开时,可以通过no_gpc Hint来强制单个查询语句不在全局共享计划缓存,只保留会话生命周期的计划缓存。 语法格式 no_gpc 说明:本参数仅在enable_global_plancache=on时对PBE执行的语句生效。 示例 dbe_perf.global_plancache_status视图中无结果即没有计划被全局缓存。 12. 同层参数化路径的Hint 功能描述 通过predpush_same_level Hint来指定同层表或物化视图之间参数化路径生成。 语法格式 predpush_same_level(src, dest) predpush_same_level(src1 src2 ..., dest) 说明:本参数仅在rewrite_rule中的predpushforce选项打开时生效。 示例 准备参数和表及索引: openGauss=# set rewrite_rule = 'predpushforce'; SET openGauss=# create table t1(a int, b int); CREATE TABLE openGauss=# create table t2(a int, b int); CREATE TABLE openGauss=# create index idx1 on t1(a); CREATE INDEX openGauss=# create index idx2 on t2(a); CREATE INDEX 执行语句查看计划: openGauss=# explain select * from t1, t2 where t1.a = t2.a; QUERY PLAN ------------------------------------------------------------------ Hash Join (cost=27.50..56.25 rows=1000 width=16) Hash Cond: (t1.a = t2.a) -> Seq Scan on t1 (cost=0.00..15.00 rows=1000 width=8) -> Hash (cost=15.00..15.00 rows=1000 width=8) -> Seq Scan on t2 (cost=0.00..15.00 rows=1000 width=8) (5 rows) 可以看到t1.a = t2.a条件过滤在Join上面,此时可以通过predpush_same_level(t1, t2)将条件下推至t2的扫描算子上: openGauss=# explain select /*+predpush_same_level(t1, t2)*/ * from t1, t2 where t1.a = t2.a; QUERY PLAN --------------------------------------------------------------------- Nested Loop (cost=0.00..335.00 rows=1000 width=16) -> Seq Scan on t1 (cost=0.00..15.00 rows=1000 width=8) -> Index Scan using idx2 on t2 (cost=0.00..0.31 rows=1 width=8) Index Cond: (a = t1.a) (4 rows) 须知:- predpush_same_level可以指定多个src,但是所有的src必须在同一个条件中。 - 如果指定的src和dest条件不存在,或该条件不符合参数化路径要求,则本hint不生效。

优秀的个人博客,低调大师

码农必备SQL调优(上)

目录 Query执行流程 SQL执行计划介绍 SQL执行计划概述 详解 调优流程 更新统计信息 审视和修改表定义 审视和修改表定义概述 选择存储模型 使用局部聚簇 使用分区表 选择数据类型 典型SQL调优点 SQL自诊断 子查询调优 统计信息调优 算子级调优 经验总结:SQL语句改写规则 SQL调优关键参数调整 Query执行流程 SQL引擎从接受SQL语句到执行SQL语句需要经历的步骤如图1和表1所示。其中,红色字体部分为DBA可以介入实施调优的环节。 图 1SQL引擎执行查询类SQL语句的流程 表 1SQL引擎执行查询类SQL语句的步骤说明 步骤 说明 1、语法&词法解析 按照约定的SQL语句规则,把输入的SQL语句从字符串转化为格式化结构(Stmt)。 2、语义解析 将“语法&词法解析”输出的格式化结构转化为数据库可以识别的对象。 3、查询重写 根据规则把“语义解析”的输出等价转化为执行上更为优化的结构。 4、查询优化 根据“查询重写”的输出和数据库内部的统计信息规划SQL语句具体的执行方式,也就是执行计划。统计信息和GUC参数对查询优化(执行计划)的影响,请参见调优手段之统计信息和调优手段之GUC参数。 5、查询执行 根据“查询优化”规划的执行路径执行SQL查询语句。底层存储方式的选择合理性,将影响查询执行效率。详见调优手段之底层存储。 调优手段之统计信息 openGauss优化器是典型的基于代价的优化(Cost-Based Optimization,简称CBO)。在这种优化器模型下,数据库根据表的元组数、字段宽度、NULL记录比率、distinct值、MCV值、HB值等表的特征值,以及一定的代价计算模型,计算出每一个执行步骤的不同执行方式的输出元组数和执行代价(cost),进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。这些特征值就是统计信息。从上面的描述可以看出统计信息是查询优化的核心输入,准确的统计信息将帮助规划器选择最合适的查询规划。一般来说我们会通过ANALYZE语法收集整个表或者表的若干个字段的统计信息,周期性地运行ANALYZE,或者在对表的大部分内容做了更改之后马上运行ANALYZE。 调优手段之GUC参数 查询优化的主要目的是为查询语句选择高效的执行方式。 如下SQL语句: select count(1) from customer inner join store_sales on (ss_customer_sk = c_customer_sk); 在执行customer inner join store_sales的时候,openGauss支持Nested Loop、Merge Join和Hash Join三种不同的Join方式。优化器会根据表customer和表store_sales的统计信息估算结果集的大小以及每种join方式的执行代价,然后对比选出执行代价最小的执行计划。 正如前面所说,执行代价计算都是基于一定的模型和统计信息进行估算,当因为某些原因代价估算不能反映真实的cost的时候,我们就需要通过guc参数设置的方式让执行计划倾向更优规划。 调优手段之底层存储 openGauss的表支持行存表、列存表,底层存储方式的选择严格依赖于客户的具体业务场景。一般来说计算型业务查询场景(以关联、聚合操作为主)建议使用列存表;点查询、大批量UPDATE/DELETE业务场景适合行存表。 对于每种存储方式还有对应的存储层优化手段,这部分会在后续的调优章节深入介绍。 调优手段之SQL重写 除了上述干预SQL引擎所生成执行计划的执行性能外,根据数据库的SQL执行机制以及大量的实践发现,有些场景下,在保证客户业务SQL逻辑的前提下,通过一定规则由DBA重写SQL语句,可以大幅度的提升SQL语句的性能。 这种调优场景对DBA的要求比较高,需要对客户业务有足够的了解,同时也需要扎实的SQL语句基本功,后续会介绍几个常见的SQL改写场景。 SQL执行计划介绍 SQL执行计划概述 SQL执行计划是一个节点树,显示openGauss执行一条SQL语句时执行的详细步骤。每一个步骤为一个数据库运算符。 使用EXPLAIN命令可以查看优化器为每个查询生成的具体执行计划。EXPLAIN给每个执行节点都输出一行,显示基本的节点类型和优化器为执行这个节点预计的开销值。如图1所示。 图 1SQL执行计划示例 最底层节点是表扫描节点,它扫描表并返回原始数据行。不同的表访问模式有不同的扫描节点类型:顺序扫描、索引扫描等。最底层节点的扫描对象也可能是非表行数据(不是直接从表中读取的数据),如VALUES子句和返回行集的函数,它们有自己的扫描节点类型。 如果查询需要连接、聚集、排序、或者对原始行做其它操作,那么就会在扫描节点之上添加其它节点。 并且这些操作通常都有多种方法,因此在这些位置也有可能出现不同的执行节点类型。 第一行(最上层节点)是执行计划总执行开销的预计。这个数值就是优化器试图最小化的数值。 执行计划显示信息 除了设置不同的执行计划显示格式外,还可以通过不同的EXPLAIN用法,显示不同详细程度的执行计划信息。常见有如下几种,关于更多用法请参见EXPLAIN语法说明。 EXPLAIN _statement_:只生成执行计划,不实际执行。其中statement代表SQL语句。 EXPLAIN ANALYZE _statement_:生成执行计划,进行执行,并显示执行的概要信息。显示中加入了实际的运行时间统计,包括在每个规划节点内部花掉的总时间(以毫秒计)和它实际返回的行数。 EXPLAIN PERFORMANCE _statement_:生成执行计划,进行执行,并显示执行期间的全部信息。 为了测量运行时在执行计划中每个节点的开销,EXPLAIN ANALYZE或EXPLAIN PERFORMANCE会在当前查询执行上增加性能分析的开销。在一个查询上运行EXPLAIN ANALYZE或EXPLAIN PERFORMANCE有时会比普通查询明显的花费更多的时间。超支的数量依赖于查询的本质和使用的平台。 因此,当定位SQL运行慢问题时,如果SQL长时间运行未结束,建议通过EXPLAIN命令查看执行计划,进行初步定位。如果SQL可以运行出来,则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及其实际的运行信息,以便更精准地定位问题原因。 EXPLAIN PERFORMANCE轻量化执行方式与EXPLAIN PERFORMANCE保持一致,在原来的基础上减少了性能分析的时间,执行时间与SQL执行时间的差异显著减少。 详解 如SQL执行计划概述节中所说,EXPLAIN会显示执行计划,但并不会实际执行SQL语句。EXPLAIN ANALYZE和EXPLAIN PERFORMANCE两者都会实际执行SQL语句并返回执行信息。在这一节将详细解释执行计划及执行信息。 执行计划 以如下SQL语句为例: SELECT * FROM t1, t2 WHERE t1.c1 = t2.c2; 执行EXPLAIN的输出为: ​ 执行计划层级解读(纵向): 第一层:Seq Scan on t2 表扫描算子,用Seq Scan的方式扫描表t2。这一层的作用是把表t2的数据从buffer或者磁盘上读上来输送给上层节点参与计算。 第二层:Hash Hash算子,作用是把下层计算输送上来的算子计算hash值,为后续hash join操作做数据准备。 第三层:Seq Scan on t1 表扫描算子,用Seq Scan的方式扫描表t1。这一层的作用是把表t1的数据从buffer或者磁盘上读上来输送给上层节点参与hash join计算。 第四层:Hash Join join算子,主要作用是将t1表和t2表的数据通过hash join的方式连接,并输出结果数据。 执行计划中的关键字说明: 表访问方式 Seq Scan 全表顺序扫描。 Index Scan 优化器决定使用两步的规划:最底层的规划节点访问一个索引,找出匹配索引条件的行的位置,然后上层规划节点真实地从表中抓取出那些行。独立地抓取数据行比顺序地读取它们的开销高很多,但是因为并非所有表的页面都被访问了,这么做实际上仍然比一次顺序扫描开销要少。使用两层规划的原因是,上层规划节点在读取索引标识出来的行位置之前,会先将它们按照物理位置排序,这样可以最小化独立抓取的开销。 如果在WHERE里面使用的好几个字段上都有索引,那么优化器可能会使用索引的AND或OR的组合。但是这么做要求访问两个索引,因此与只使用一个索引,而把另外一个条件只当作过滤器相比,这个方法未必是更优。 索引扫描可以分为以下几类,他们之间的差异在于索引的排序机制。 Bitmap Index Scan 使用位图索引抓取数据页。 Index Scan using index_name 使用简单索引搜索,该方式表的数据行是以索引顺序抓取的,这样就令读取它们的开销更大,但是这里的行少得可怜,因此对行位置的额外排序并不值得。最常见的就是看到这种规划类型只抓取一行,以及那些要求ORDER BY条件匹配索引顺序的查询。因为那时候没有多余的排序步骤是必要的以满足ORDER BY。 表连接方式 Nested Loop 嵌套循环,适用于被连接的数据子集较小的查询。在嵌套循环中,外表驱动内表,外表返回的每一行都要在内表中检索找到它匹配的行,因此整个查询返回的结果集不能太大(不能大于10000),要把返回子集较小的表作为外表,而且在内表的连接字段上建议要有索引。 (Sonic) Hash Join 哈希连接,适用于数据量大的表的连接方式。优化器使用两个表中较小的表,利用连接键在内存中建立hash表,然后扫描较大的表并探测散列,找到与散列匹配的行。Sonic和非Sonic的Hash Join的区别在于所使用hash表结构不同,不影响执行的结果集。 Merge Join 归并连接,通常情况下执行性能差于哈希连接。如果源数据已经被排序过,在执行融合连接时,并不需要再排序,此时融合连接的性能优于哈希连接。 运算符 sort 对结果集进行排序。 filter EXPLAIN输出显示WHERE子句当作一个“filter”条件附属于顺序扫描计划节点。这意味着规划节点为它扫描的每一行检查该条件,并且只输出符合条件的行。预计的输出行数降低了,因为有WHERE子句。不过,扫描仍将必须访问所有 10000 行,因此开销没有降低;实际上它还增加了一些(确切的说,通过10000 * cpu_operator_cost)以反映检查WHERE条件的额外CPU时间。 LIMIT LIMIT限定了执行结果的输出记录数。如果增加了LIMIT,那么不是所有的行都会被检索到。 执行信息 以如下SQL语句为例: 复制代码select sum(t2.c1) from t1,t2 where t1.c1=t2.c2 group by t1.c2; 执行EXPLAIN PERFORMANCE输出为: ​ 调优流程 对慢SQL语句进行分析,通常包括以下步骤: 操作步骤 收集SQL中涉及到的所有表的统计信息。在数据库中,统计信息是规划器生成计划的源数据。没有收集统计信息或者统计信息陈旧往往会造成执行计划严重劣化,从而导致性能问题。从经验数据来看,10%左右性能问题是因为没有收集统计信息。具体请参见更新统计信息。 通过查看执行计划来查找原因。如果SQL长时间运行未结束,通过EXPLAIN命令查看执行计划,进行初步定位。如果SQL可以运行出来,则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及实际运行情况,以便更精准地定位问题原因。有关执行计划的详细介绍请参见SQL执行计划介绍。 审视和修改表定义。 针对EXPLAIN或EXPLAIN PERFORMANCE信息,定位SQL慢的具体原因以及改进措施,具体参见典型SQL调优点。 通常情况下,有些SQL语句可以通过查询重写转换成等价的,或特定场景下等价的语句。重写后的语句比原语句更简单,且可以简化某些执行步骤达到提升性能的目的。查询重写方法在各个数据库中基本是通用的。经验总结:SQL语句改写规则介绍了几种常用的通过改写SQL进行调优的方法。 更新统计信息 在数据库中,统计信息是规划器生成计划的源数据。没有收集统计信息或者统计信息陈旧往往会造成执行计划严重劣化,从而导致性能问题。 背景信息 ANALYZE语句可收集与数据库中表内容相关的统计信息,统计结果存储在系统表PG_STATISTIC中。查询优化器会使用这些统计数据,以生成最有效的执行计划。 建议在执行了大批量插入/删除操作后,例行对表或全库执行ANALYZE语句更新统计信息。目前默认收集统计信息的采样比例是30000行(即:GUC参数default_statistics_target默认设置为100),如果表的总行数超过一定行数(大于1600000),建议设置Guc参数default_statistics_target为-2,即按2%收集样本估算统计信息。 对于在批处理脚本或者存储过程中生成的中间表,也需要在完成数据生成之后显式的调用ANALYZE。 对于表中多个列有相关性且查询中有同时基于这些列的条件或分组操作的情况,可尝试收集多列统计信息,以便查询优化器可以更准确地估算行数,并生成更有效的执行计划。 操作步骤 使用以下命令更新某个表或者整个database的统计信息。--更新单个表的统计信息。 ANALYZE tablename; --更新全库的统计信息。 ANALYZE; 使用以下命令进行多列统计信息相关操作。 --收集tablename表的column_1、column_2列的多列统计信息。 ANALYZE tablename ((column_1, column_2)); --添加tablename表的column_1、column_2列的多列统计信息声明。 ALTER TABLE tablename ADD STATISTICS ((column_1, column_2)); --收集单列统计信息,并收集已声明的多列统计信息。 ANALYZE tablename; --删除tablename表的column_1、column_2列的多列统计信息或其声明。 ALTER TABLE tablename DELETE STATISTICS ((column_1, column_2)); ​ 须知: 在使用ALTER TABLE tablename ADD STATISTICS语句添加了多列统计信息声明后,系统并不会立刻收集多列统计信息,而是在下次对该表或全库进行ANALYZE时,进行多列统计信息的收集。 如果想直接收集多列统计信息,请使用ANALYZE命令进行收集。 ​ 说明: 使用EXPLAIN查看各SQL的执行计划时,如果发现某个表SEQ SCAN的输出中rows=10,rows=10是系统给的默认值,有可能该表没有进行ANALYZE,需要对该表执行ANALY 审视和修改表定义 审视和修改表定义概述 好的表定义至少需要达到以下几个目标: 减少扫描数据数据量。通过分区的剪枝机制可以实现该点。 尽量极少随机IO。通过聚簇/局部聚簇可以实现该点。 表定义在数据库设计阶段创建,在SQL调优过程中进行审视和修改。 选择存储模型 进行数据库设计时,表设计上的一些关键项将严重影响后续整库的查询性能。表设计对数据存储也有影响:好的表设计能够减少I/O操作及最小化内存使用,进而提升查询性能。 表的存储模型选择是表定义的第一步。客户业务属性是表的存储模型的决定性因素,依据下面表格选择适合当前业务的存储模型。 存储模型 适用场景 行存 点查询(返回记录少,基于索引的简单查询)。 增删改比较多的场景。 列存 统计分析类查询(group 、join多的场景)。 使用局部聚簇 局部聚簇(Partial Cluster Key)是列存下的一种技术。这种技术可以通过min/max稀疏索引较快的实现基表扫描的filter过滤。Partial Cluster Key可以指定多列,但是一般不建议超过2列。Partial Cluster Key的选取原则: 受基表中的简单表达式约束。这种约束一般形如col op const,其中col为列名,op为操作符 =、>、>=、<=、<,const为常量值。 尽量采用选择度比较高(过滤掉更多数据)的简单表达式中的列。 尽量把选择度比较低的约束col放在Partial Cluster Key中的前面。 尽量把枚举类型的列放在Partial Cluster Key中的前面。 使用分区表 分区表是把逻辑上的一张表根据某种方案分成几张物理块进行存储。这张逻辑上的表称之为分区表,物理块称之为分区。分区表是一张逻辑表,不存储数据,数据实际是存储在分区上的。分区表和普通表相比具有以下优点: 改善查询性能:对分区对象的查询可以仅搜索自己关心的分区,提高检索效率。 增强可用性:如果分区表的某个分区出现故障,表在其他分区的数据仍然可用。 方便维护:如果分区表的某个分区出现故障,需要修复数据,只修复该分区即可。 openGauss支持的分区表为范围分区表。 范围分区表:将数据基于范围映射到每一个分区。这个范围是由创建分区表时指定的分区键决定的。分区键经常采用日期,例如将销售数据按照月份进行分区。 选择数据类型 高效数据类型,主要包括以下三方面: 尽量使用执行效率比较高的数据类型 一般来说整型数据运算(包括=、>、<、≧、≦、≠等常规的比较运算,以及group by)的效率比字符串、浮点数要高。比如某客户场景中对列存表进行点查询,filter条件在一个numeric列上,执行时间为10+s;修改numeric为int类型之后,执行时间缩短为1.8s左右。 尽量使用短字段的数据类型 长度较短的数据类型不仅可以减小数据文件的大小,提升IO性能;同时也可以减小相关计算时的内存消耗,提升计算性能。比如对于整型数据,如果可以用smallint就尽量不用int,如果可以用int就尽量不用bigint。 使用一致的数据类型 表关联列尽量使用相同的数据类型。如果表关联列数据类型不同,数据库必须动态地转化为相同的数据类型进行比较,这种转换会带来一定的性能开销。 典型SQL调优点 SQL调优是一个不断分析与尝试的过程:试跑Query,判断性能是否满足要求;如果不满足要求,则通过查看执行计划分析原因并进行针对性优化;然后重新试跑和优化,直到满足性能目标。 SQL自诊断 用户在执行查询或者执行INSERT/DELETE/UPDATE/CREATE TABLE AS语句时,可能会遇到性能问题。这种情况下,通过查询PG_CONTROL_GROUP_CONFIG、GS_SESSION_MEMORY_DETAIL视图的warning字段可以获得对应查询可能导致性能问题的告警信息,为性能调优提供参考。 SQL自诊断的告警类型与resource_track_level的设置有关系。如果resource_track_level设置为query,则可以诊断多列/单列统计信息未收集和SQL不下推的告警。如果resource_track_level设置为operator,则可以诊断所有的告警场景。 SQL自诊断的诊断范围与resource_track_cost的设置有关系。当SQL的代价大于resource_track_cost时,SQL才会被诊断。SQL的代价可以通过explain来确认。 告警场景 目前支持对多列/单列统计信息未收集导致性能问题的场景上报告警。 如果存在单列或者多列统计信息未收集,则上报相关告警。调优方法可以参考更新统计信息和统计信息调优。 告警信息示例: 整表的统计信息未收集: Statistic Not Collect: schema_test.t1 单列统计信息未收集: Statistic Not Collect: schema_test.t2(c1,c2) 多列统计信息未收集: Statistic Not Collect: schema_test.t3((c1,c2)) 单列和多列统计信息未收集: Statistic Not Collect: schema_test.t4(c1,c2) schema_test.t4((c1,c2)) 规格约束 告警字符串长度上限为2048。如果告警信息超过这个长度(例如存在大量未收集统计信息的超长表名、列名等信息)则不告警,只上报warning: WARNING, "Planner issue report is truncated, the rest of planner issues will be skipped" 如果query存在limit节点(即查询语句中包含limit),则不会上报limit节点以下的Operator级别的告警。 子查询调优 子查询背景介绍 应用程序通过SQL语句来操作数据库时会使用大量的子查询,这种写法比直接对两个表做连接操作在结构上和思路上更清晰,尤其是在一些比较复杂的查询语句中,子查询有更完整、更独立的语义,会使SQL对业务逻辑的表达更清晰更容易理解,因此得到了广泛的应用。 openGauss根据子查询在SQL语句中的位置把子查询分成了子查询、子链接两种形式。 子查询SubQuery:对应于查询解析树中的范围表RangeTblEntry,更通俗一些指的是出现在FROM语句后面的独立的SELECT语句。 子链接SubLink:对应于查询解析树中的表达式,更通俗一些指的是出现在where/on子句、targetlist里面的语句。 综上,对于查询解析树而言,SubQuery的本质是范围表,而SubLink的本质是表达式。针对SubLink场景而言,由于SubLink可以出现在约束条件、表达式中,按照openGauss对SubLink的实现,SubLink可以分为以下几类: exist_sublink:对应EXIST、NOT EXIST语句 any_sublink:对应op ALL(select…)语句,其中OP可以是IN、<、>、=操作符 all_sublink:对应op ALL(select…)语句,其中OP可以是IN、<、>、=操作符 rowcompare_sublink:对应record op (select …)语句 expr_sublink:对应(SELECT with single targetlist item …)语句 array_sublink:对应ARRAY(select…)语句 cte_sublink:对应with query(…)语句 其中OLAP、HTAP场景中常用的sublink为exist_sublink、any_sublink,在openGauss的优化引擎中对其应用场景做了优化(子链接提升),由于SQL语句中子查询的使用的灵活性,会带来SQL子查询过于复杂造成性能问题。子查询从大类上来看,分为非相关子查询和相关子查询: 非相关子查询None-Correlated SubQuery 子查询的执行不依赖于外层父查询的任何属性值。这样子查询具有独立性,可独自求解,形成一个子查询计划先于外层的查询求解。 例如: select t1.c1,t1.c2 from t1 where t1.c1 in ( select c2 from t2 where t2.c2 IN (2,3,4) ); QUERY PLAN ---------------------------------------------------------------- Hash Join Hash Cond: (t1.c1 = t2.c2) -> Seq Scan on t1 Filter: (c1 = ANY ('{2,3,4}'::integer[])) -> Hash -> HashAggregate Group By Key: t2.c2 -> Seq Scan on t2 Filter: (c2 = ANY ('{2,3,4}'::integer[])) (9 rows) 相关子查询Correlated-SubQuery 子查询的执行依赖于外层父查询的一些属性值(如下列示例t2.c1 = t1.c1条件中的t1.c1)作为内层查询的一个AND-ed条件。这样的子查询不具备独立性,需要和外层查询按分组进行求解。 例如: select t1.c1,t1.c2 from t1 where t1.c1 in ( select c2 from t2 where t2.c1 = t1.c1 AND t2.c2 in (2,3,4) ); QUERY PLAN ------------------------------------------------------------------------ Seq Scan on t1 Filter: (SubPlan 1) SubPlan 1 -> Seq Scan on t2 Filter: ((c1 = t1.c1) AND (c2 = ANY ('{2,3,4}'::integer[]))) (5 rows) openGauss对SubLink的优化 针对SubLink的优化策略主要是让内层的子查询提升(pullup),能够和外表直接做关联查询,从而避免生成SubPlan+Broadcast內表的执行计划。判断子查询是否存在性能风险,可以通过explain查询语句查看Sublink的部分是否被转换成SubPlan的执行计划。 例如: 箭头右侧执行计划应替换成下面的执行计划: QUERY PLAN -------------------------------- Seq Scan on t1 Filter: (SubPlan 1) SubPlan 1 -> Seq Scan on t2 Filter: (c1 = t1.c1) (5 rows) 目前openGauss支持的Sublink-Release场景 IN-Sublink无相关条件 不能包含上一层查询的表中的列(可以包含更高层查询表中的列)。 不能包含易变函数。 箭头右侧执行计划应替换成下面的执行计划: QUERY PLAN -------------------------------------- Hash Join Hash Cond: (t1.c1 = t2.c2) -> Seq Scan on t1 -> Hash -> HashAggregate Group By Key: t2.c2 -> Seq Scan on t2 Filter: (c1 = 1) (8 rows) Exist-Sublink包含相关条件 Where子句中必须包含上一层查询的表中的列,子查询的其它部分不能含有上层查询的表中的列。其它限制如下。 子查询必须有from子句。 子查询不能含有with子句。 子查询不能含有聚集函数。 子查询里不能包含集合操作、排序、limit、windowagg、having操作。 不能包含易变函数。 箭头右侧执行计划应替换成下面的执行计划: QUERY PLAN Hash Join Hash Cond: (t1.c1 = t2.c1) -> Seq Scan on t1 -> Hash -> HashAggregate Group By Key: t2.c1 -> Seq Scan on t2 (7 rows) 包含聚集函数的等值相关子查询的提升 子查询的where条件中必须含有来自上一层的列,而且此列必须和子查询本层涉及表中的列做相等判断,且这些条件必须用and连接。其它地方不能包含上层的列。其它限制条件如下。 子查询中where条件包含的表达式(列名)必须是表中的列。 子查询的Select关键字后,必须有且仅有一个输出列,此输出列必须是聚集函数(如max),并且聚集函数的参数(t2.c2)不能是来自外层表(t1)中的列。聚集函数不能是count。 例如,下列示例可以提升。 select * from t1 where c1 >( select max(t2.c1) from t2 where t2.c1=t1.c1 ); 下列示例不能提升,因为子查询没有聚集函数。 select * from t1 where c1 >( select t2.c1 from t2 where t2.c1=t1.c1 ); 下列示例不能提升,因为子查询有两个输出列。 select * from t1 where (c1,c2) >( select max(t2.c1),min(t2.c2) from t2 where t2.c1=t1.c1 ); 子查询必须是from子句。 子查询中不能有groupby、having、集合操作。 子查询只能是inner join。 例如:下列示例不能提升。 select * from t1 where c1 >( select max(t2.c1) from t2 full join t3 on (t2.c2=t3.c2) where t2.c1=t1.c1 ); 子查询的targetlist中不能包含返回set的函数。 子查询的where条件中必须含有来自上一层的列,而且此列必须和子查询层涉及表中的列做相等判断,且这些条件必须用and连接。其它地方不能包含上层的上层中的列。例如:下列示例中的最内层子链接可以提升。 select * from t3 where t3.c1=( select t1.c1 from t1 where c1 >( select max(t2.c1) from t2 where t2.c1=t1.c1 )); 基于上面的示例,再加一个条件,则不能提升,因为最内侧子查询引用了上层中的列。示例如下: select * from t3 where t3.c1=( select t1.c1 from t1 where c1 >( select max(t2.c1) from t2 where t2.c1=t1.c1 and t3.c1>t2.c2 )); 提升OR子句中的SubLink 当WHERE过滤条件中有OR连接的EXIST相关SubLink, 例如: select a, c from t1 where t1.a = (select avg(a) from t3 where t1.b = t3.b) or exists (select * from t4 where t1.c = t4.c); 将OR-ed连接的EXIST相关子查询OR字句的提升过程: 提取where条件中,or子句中的opExpr。为:t1.a = (select avg(a) from t3 where t1.b = t3.b) 这个op操作中包含subquery,判断是否可以提升,如果可以提升,重写subquery为:select avg(a)、 t3.b from t3 group by t3.b,生成not null条件t3.b is not null,并将这个opexpr用这个not null条件替换。此时SQL变为: select a, c from t1 left join (select avg(a) avg, t3.b from t3 group by t3.b) as t3 on (t1.a = avg and t1.b = t3.b) where t3.b is not null or exists (select * from t4 where t1.c = t4.c); 再次提取or子句中的exists sublink、exists (select * from t4 where t1.c = t4.c),判断是否可以提升,如果可以提升,转换subquery为:select t4.c from t4 group by t4.c生成NotNull条件t4.c is not null提升查询,SQL变为: select a, c from t1 left join (select avg(a) avg, t3.b from t3 group by t3.b) as t3 on (t1.a = avg and t1.b = t3.b) left join (select t4.c from t4 group by t4.c) where t3.b is not null or t4.c is not null; 目前openGauss不支持的Sublink-Release场景 除了以上场景之外都不支持Sublink提升,因此关联子查询会被计划成SubPlan+Broadcast的执行计划,当inner表的数据量较大时则会产生性能风险。 如果相关子查询中跟外层的两张表做join,那么无法提升该子查询,需要通过将父SQL创建成with子句,然后再跟子查询中的表做相关子查询查询。 例如: select distinct t1.a, t2.a from t1 left join t2 on t1.a=t2.a and not exists (select a,b from test1 where test1.a=t1.a and test1.b=t2.a); 改写为 with temp as ( select * from (select t1.a as a, t2.a as b from t1 left join t2 on t1.a=t2.a) ) select distinct a,b from temp where not exists (select a,b from test1 where temp.a=test1.a and temp.b=test1.b); 出现在targetlist里的相关子查询无法提升(不含count) 例如: explain (costs off) select (select c2 from t2 where t1.c1 = t2.c1) ssq, t1.c2 from t1 where t1.c2 > 10; 执行计划为: explain (costs off) select (select c2 from t2 where t1.c1 = t2.c1) ssq, t1.c2 from t1 where t1.c2 > 10; QUERY PLAN -------------------------------- Seq Scan on t1 Filter: (c2 > 10) SubPlan 1 -> Seq Scan on t2 Filter: (t1.c1 = c1) (5 rows) 由于相关子查询出现在targetlist(查询返回列表)里,对于t1.c1=t2.c1不匹配的场景仍然需要输出值,因此使用left-outerjoin关联T1&T2确保t1.c1=t2.c1在不匹配时,子SSQ能够返回不匹配的补空值。 说明: SSQ和CSSQ的解释如下: - SSQ:ScalarSubQuery一般指返回1行1列scalar值的sublink,简称SSQ。 - CSSQ:Correlated-ScalarSubQuery和SSQ相同不过是指包含相关条件的SSQ。 上述SQL语句可以改写为: with ssq as ( select t2.c2 from t2 ) select ssq.c2, t1.c2 from t1 left join ssq on t1.c1 = ssq.c2 where t1.c2 > 10; 改写后的执行计划为: QUERY PLAN --------------------------------- Hash Right Join Hash Cond: (ssq.c2 = t1.c1) CTE ssq -> Seq Scan on t2 -> CTE Scan on ssq -> Hash -> Seq Scan on t1 Filter: (c2 > 10) (8 rows) 可以看到出现在SSQ返回列表里的相关子查询SSQ,已经被提升成Right Join,从而避免当內表T2较大时出现SubPlan计划导致性能变差。 出现在targetlist里的相关子查询无法提升(带count) 例如: select (select count(*) from t2 where t2.c1=t1.c1) cnt, t1.c1, t3.c1 from t1,t3 where t1.c1=t3.c1 order by cnt, t1.c1; 执行计划为 QUERY PLAN -------------------------------------------- Sort Sort Key: ((SubPlan 1)), t1.c1 -> Hash Join Hash Cond: (t1.c1 = t3.c1) -> Seq Scan on t1 -> Hash -> Seq Scan on t3 SubPlan 1 -> Aggregate -> Seq Scan on t2 Filter: (c1 = t1.c1) (11 rows) 由于相关子查询出现在targetlist(查询返回列表)里,对于t1.c1=t2.c1不匹配的场景仍然需要输出值,因此使用left-outerjoin关联T1&T2确保t1.c1=t2.c1在不匹配时子SSQ能够返回不匹配的补空值,但是这里带了count语句及时在t1.c1=t2.t1不匹配时需要输出0,因此可以使用一个case-when NULL then 0 else count(*)来代替。 上述SQL语句可以改写为: with ssq as ( select count(*) cnt, c1 from t2 group by c1 ) select case when ssq.cnt is null then 0 else ssq.cnt end cnt, t1.c1, t3.c1 from t1 left join ssq on ssq.c1 = t1.c1,t3 where t1.c1 = t3.c1 order by ssq.cnt, t1.c1; 改写后的执行计划为 QUERY PLAN ------------------------------------------- Sort Sort Key: ssq.cnt, t1.c1 CTE ssq -> HashAggregate Group By Key: t2.c1 -> Seq Scan on t2 -> Hash Join Hash Cond: (t1.c1 = t3.c1) -> Hash Left Join Hash Cond: (t1.c1 = ssq.c1) -> Seq Scan on t1 -> Hash -> CTE Scan on ssq -> Hash -> Seq Scan on t3 (15 rows) 相关条件为不等值场景 例如: 复制代码select t1.c1, t1.c2 from t1 where t1.c1 = (select agg() from t2.c2 > t1.c2); 对于非等值相关条件的SubLink目前无法提升,从语义上可以通过做2次join(一次CorrelationKey,一次rownum自关联)达到提升改写的目的。 改写方案有两种。 子查询改写方式 复制代码select t1.c1, t1.c2 from t1, ( select t1.rowid, agg() aggref from t1,t2 where t1.c2 > t2.c2 group by t1.rowid ) dt /* derived table */ where t1.rowid = dt.rowid AND t1.c1 = dt.aggref; CTE改写方式 复制代码WITH dt as ( select t1.rowid, agg() aggref from t1,t2 where t1.c2 > t2.c2 group by t1.rowid ) select t1.c1, t1.c2 from t1, derived_table where t1.rowid = derived_table.rowid AND t1.c1 = derived_table.aggref; 须知: - 对于AGG类型为count(*)时需要进行CASE-WHEN对没有match的场景补0处理,非COUNT(*)场景NULL处理。 - CTE改写方式如果有sharescan支持性能上能够更优。 更多优化示例 示例:修改select语句,将子查询修改为和主表的join,或者修改为可以提升的subquery,但是在修改前后需要保证语义的正确性。 explain (costs off) select * from t1 where t1.c1 in (select t2.c1 from t2 where t1.c1 = t2.c2); QUERY PLAN -------------------------------- Seq Scan on t1 Filter: (SubPlan 1) SubPlan 1 -> Seq Scan on t2 Filter: (t1.c1 = c2) (5 rows) 上面事例计划中存在一个subPlan,为了消除这个subPlan可以修改语句为: explain (costs off) select * from t1 where exists (select t2.c1 from t2 where t1.c1 = t2.c2 and t1.c1 = t2.c1); QUERY PLAN ------------------------------------------ Hash Join Hash Cond: (t1.c1 = t2.c2) -> Seq Scan on t1 -> Hash -> HashAggregate Group By Key: t2.c2, t2.c1 -> Seq Scan on t2 Filter: (c2 = c1) (8 rows) 从计划可以看出,subPlan消除了,计划变成了两个表的hash join,这样会大大提高执行效率。 统计信息调优 统计信息调优介绍 openGauss是基于代价估算生成的最优执行计划。优化器需要根据analyze收集的统计信息行数估算和代价估算,因此统计信息对优化器行数估算和代价估算起着至关重要的作用。通过analyze收集全局统计信息,主要包括:pg_class表中的relpages和reltuples;pg_statistic表中的stadistinct、stanullfrac、stanumbersN、stavaluesN、histogram_bounds等。 实例分析1:未收集统计信息导致查询性能差 在很多场景下,由于查询中涉及到的表或列没有收集统计信息,会对查询性能有很大的影响。 表结构如下所示: CREATE TABLE LINEITEM ( L_ORDERKEY BIGINT NOT NULL , L_PARTKEY BIGINT NOT NULL , L_SUPPKEY BIGINT NOT NULL , L_LINENUMBER BIGINT NOT NULL , L_QUANTITY DECIMAL(15,2) NOT NULL , L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL , L_DISCOUNT DECIMAL(15,2) NOT NULL , L_TAX DECIMAL(15,2) NOT NULL , L_RETURNFLAG CHAR(1) NOT NULL , L_LINESTATUS CHAR(1) NOT NULL , L_SHIPDATE DATE NOT NULL , L_COMMITDATE DATE NOT NULL , L_RECEIPTDATE DATE NOT NULL , L_SHIPINSTRUCT CHAR(25) NOT NULL , L_SHIPMODE CHAR(10) NOT NULL , L_COMMENT VARCHAR(44) NOT NULL ) with (orientation = column, COMPRESSION = MIDDLE); CREATE TABLE ORDERS ( O_ORDERKEY BIGINT NOT NULL , O_CUSTKEY BIGINT NOT NULL , O_ORDERSTATUS CHAR(1) NOT NULL , O_TOTALPRICE DECIMAL(15,2) NOT NULL , O_ORDERDATE DATE NOT NULL , O_ORDERPRIORITY CHAR(15) NOT NULL , O_CLERK CHAR(15) NOT NULL , O_SHIPPRIORITY BIGINT NOT NULL , O_COMMENT VARCHAR(79) NOT NULL )with (orientation = column, COMPRESSION = MIDDLE); 查询语句如下所示: explain verbose select count(*) as numwait from lineitem l1, orders where o_orderkey = l1.l_orderkey and o_orderstatus = 'F' and l1.l_receiptdate > l1.l_commitdate and not exists ( select * from lineitem l3 where l3.l_orderkey = l1.l_orderkey and l3.l_suppkey <> l1.l_suppkey and l3.l_receiptdate > l3.l_commitdate ) order by numwait desc; 当出现该问题时,可以通过如下方法确认查询中涉及到的表或列有没有做过analyze收集统计信息。 通过explain verbose执行query分析执行计划时会提示WARNING信息,如下所示: WARNING:Statistics in some tables or columns(public.lineitem.l_receiptdate, public.lineitem.l_commitdate, public.lineitem.l_orderkey, public.lineitem.l_suppkey, public.orders.o_orderstatus, public.orders.o_orderkey) are not collected. HINT:Do analyze for them in order to generate optimized plan. 可以通过在pg_log目录下的日志文件中查找以下信息来确认是当前执行的query是否由于没有收集统计信息导致查询性能变差。 2017-06-14 17:28:30.336 CST 140644024579856 20971684 [BACKEND] LOG:Statistics in some tables or columns(public.lineitem.l_receiptdate, public.lineitem.l_commitdate, public.lineitem.l_orderkey, public.linei tem.l_suppkey, public.orders.o_orderstatus, public.orders.o_orderkey) are not collected. 2017-06-14 17:28:30.336 CST 140644024579856 20971684 [BACKEND] HINT:Do analyze for them in order to generate optimized plan. 当通过以上方法查看到哪些表或列没有做analyze,可以通过对WARNING或日志中上报的表或列做analyze可以解决由于为收集统计信息导致查询变慢的问题。 算子级调优 算子级调优介绍 一个查询语句要经过多个算子步骤才会输出最终的结果。由于个别算子耗时过长导致整体查询性能下降的情况比较常见。这些算子是整个查询的瓶颈算子。通用的优化手段是EXPLAIN ANALYZE/PERFORMANCE命令查看执行过程的瓶颈算子,然后进行针对性优化。 如下面的执行过程信息中,Hashagg算子的执行时间占总时间的:(51016-13535)/ 56476 ≈66%,此处Hashagg算子就是这个查询的瓶颈算子,在进行性能优化时应当优先考虑此算子的优化。 算子级调优示例 示例1:基表扫描时,对于点查或者范围扫描等过滤大量数据的查询,如果使用SeqScan全表扫描会比较耗时,可以在条件列上建立索引选择IndexScan进行索引扫描提升扫描效率。 openGauss=# explain (analyze on, costs off) select * from store_sales where ss_sold_date_sk = 2450944; id | operation | A-time | A-rows | Peak Memory | A-width ----+--------------------------------+---------------------+--------+--------------+--------- 1 | -> Streaming (type: GATHER) | 3666.020 | 3360 | 195KB | 2 | -> Seq Scan on store_sales | [3594.611,3594.611] | 3360 | [34KB, 34KB] | (2 rows) Predicate Information (identified by plan id) ----------------------------------------------- 2 --Seq Scan on store_sales Filter: (ss_sold_date_sk = 2450944) Rows Removed by Filter: 4968936 openGauss=# create index idx on store_sales_row(ss_sold_date_sk); CREATE INDEX openGauss=# explain (analyze on, costs off) select * from store_sales_row where ss_sold_date_sk = 2450944; id | operation | A-time | A-rows | Peak Memory | A-width ----+------------------------------------------------+-----------------+--------+--------------+---------- 1 | -> Streaming (type: GATHER) | 81.524 | 3360 | 195KB | 2 | -> Index Scan using idx on store_sales_row | [13.352,13.352] | 3360 | [34KB, 34KB] | (2 rows) 上述例子中,全表扫描返回3360条数据,过滤掉大量数据,在ss_sold_date_sk列上建立索引后,使用IndexScan扫描效率显著提高,从3.6秒提升到13毫秒。 示例2:如果从执行计划中看,两表join选择了NestLoop,而实际行数比较大时,NestLoop Join可能执行比较慢。如下的例子中NestLoop耗时181秒,如果设置参数enable_mergejoin=off关掉Merge Join,同时设置参数enable_nestloop=off关掉NestLoop,让优化器选择HashJoin,则Join耗时提升至200多毫秒。 示例3:通常情况下Agg选择HashAgg性能较好,如果大结果集选择了Sort+GroupAgg,则需要设置enable_sort=off,HashAgg耗时明显优于Sort+GroupAgg。 经验总结:SQL语句改写规则 根据数据库的SQL执行机制以及大量的实践,总结发现:通过一定的规则调整SQL语句,在保证结果正确的基础上,能够提高SQL执行效率。如果遵守这些规则,常常能够大幅度提升业务查询效率。 使用union all代替union。 union在合并两个集合时会执行去重操作,而union all则直接将两个结果集合并、不执行去重。执行去重会消耗大量的时间,因此,在一些实际应用场景中,如果通过业务逻辑已确认两个集合不存在重叠,可用union all替代union以便提升性能。 join列增加非空过滤条件。 若join列上的NULL值较多,则可以加上is not null过滤条件,以实现数据的提前过滤,提高join效率。 not in转not exists。 not in语句需要使用nestloop anti join来实现,而not exists则可以通过hash anti join来实现。在join列不存在null值的情况下,not exists和not in等价。因此在确保没有null值时,可以通过将not in转换为not exists,通过生成hash join来提升查询效率。 如下所示,如果t2.d2字段中没有null值(t2.d2字段在表定义中not null)查询可以修改为: SELECT * FROM t1 WHERE NOT EXISTS (SELECT * FROM t2 WHERE t1.c1=t2.d2); 产生的计划如下: QUERY PLAN ------------------------------ Hash Anti Join Hash Cond: (t1.c1 = t2.d2) -> Seq Scan on t1 -> Hash -> Seq Scan on t2 (5 rows) 选择hashagg。 查询中GROUP BY语句如果生成了groupagg+sort的plan性能会比较差,可以通过加大work_mem的方法生成hashagg的plan,因为不用排序而提高性能。 尝试将函数替换为case语句。 openGauss函数调用性能较低,如果出现过多的函数调用导致性能下降很多,可以根据情况把可下推函数的函数改成CASE表达式。 避免对索引使用函数或表达式运算。 对索引使用函数或表达式运算会停止使用索引转而执行全表扫描。 尽量避免在where子句中使用!=或<>操作符、null值判断、or连接、参数隐式转换。 对复杂SQL语句进行拆分。 对于过于复杂并且不易通过以上方法调整性能的SQL可以考虑拆分的方法,把SQL中某一部分拆分成独立的SQL并把执行结果存入临时表,拆分常见的场景包括但不限于: 作业中多个SQL有同样的子查询,并且子查询数据量较大。 Plan cost计算不准,导致子查询hash bucket太小,比如实际数据1000W行,hash bucket只有1000。 函数(如substr、to_number)导致大数据量子查询选择度计算不准。 SQL调优关键参数调整 本节将介绍影响openGauss SQL调优性能的关键数据库主节点配置参数,配置方法参见配置运行参数。 表 1数据库主节点配置参数 参数/参考值 描述 enable_nestloop=on 控制查询优化器对嵌套循环连接(Nest Loop Join)类型的使用。当设置为“on”后,优化器优先使用Nest Loop Join;当设置为“off”后,优化器在存在其他方法时将优先选择其他方法。 说明: 如果只需要在当前数据库连接(即当前Session)中临时更改该参数值,则只需要在SQL语句中执行如下命令: 复制代码SET enable_nestloop to off; 此参数默认设置为“on”,但实际调优中应根据情况选择是否关闭。一般情况下,在三种join方式(Nested Loop、Merge Join和Hash Join)里,Nested Loop性能较差,实际调优中可以选择关闭。 enable_bitmapscan=on 控制查询优化器对位图扫描规划类型的使用。设置为“on”,表示使用;设置为“off”,表示不使用。 说明: 如果只需要在当前数据库连接(即当前Session)中临时更改该参数值,则只需要在SQL语句中执行命令如下命令: 复制代码SET enable_bitmapscan to off; bitmapscan扫描方式适用于“where a > 1 and b > 1”且a列和b列都有索引这种查询条件,但有时其性能不如indexscan。因此,现场调优如发现查询性能较差且计划中有bitmapscan算子,可以关闭bitmapscan,看性能是否有提升。 enable_hashagg=on 控制优化器对Hash聚集规划类型的使用。 enable_hashjoin=on 控制优化器对Hash连接规划类型的使用。 enable_mergejoin=on 控制优化器对融合连接规划类型的使用。 enable_indexscan=on 控制优化器对索引扫描规划类型的使用。 enable_indexonlyscan=on 控制优化器对仅索引扫描规划类型的使用。 enable_seqscan=on 控制优化器对顺序扫描规划类型的使用。完全消除顺序扫描是不可能的,但是关闭这个变量会让优化器在存在其他方法的时候优先选择其他方法。 enable_sort=on 控制优化器使用的排序步骤。该设置不可能完全消除明确的排序,但是关闭这个变量可以让优化器在存在其他方法的时候优先选择其他方法。 rewrite_rule 控制优化器是否启用LAZY_AGG和MAGIC_SET重写规则。 sql_beta_feature 控制优化器是否启用。SEL_SEMI_POISSON/SEL_EXPR_INSTR/PARAM_PATH_GEN/RAND_COST_OPT/PARAM_PATH_OPT/PAGE_EST_OPT/CANONICAL_PATHKEY/PARTITION_OPFUSION测试功能。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

用户登录
用户注册