15._Parameter参数和$

1.mybatis的规则:
当parameterType的参数是java.lang 基本数据类型时,在sql语句中使用传入的参数判断,参数名不能随意命名需写成指定的格式**_parameter**
在这里插入图片描述
还有一个必须使用_parameter的地方$
在这里插入图片描述
在排序的时候会用到:
以下未排序:desc倒序
在这里插入图片描述
把#换成$符号,倒序正常
在这里插入图片描述

在这里插入图片描述

<think>嗯,用户给了一个SQL查询,想优化它,并且想知道在维护PIE时需要检查哪些参数的值。首先,我需要仔细看看这个SQL的结构可能存在的问题。 首先,这个查询使用了CONNECT BY来进行层级递归,但看起来是为了拆分STAGE字段中的逗号分隔值。REGEXP_SUBSTR配合LEVEL来逐级提取每个STAGE。不过,这里用了CONNECT BY并且有多个PRIOR条件,可能会造成性能问题,尤其是在数据量大的情况下。因为CONNECT BY通常用于树状结构,而这里可能只是用来拆分字符串,这种方式可能不够高效。 接下来,LEFT JOIN的条件涉及到多个字段,比如DPM.PARAMETER_NAMEWP.NAME,以及DPM.LIMIT_FILEWP.SPECFILE_NAME。需要确认这些关联条件是否正确,是否有遗漏的索引,或者是否存在重复数据导致连接效率低下。 然后,DISTINCT关键字的使用可能是因为拆分STAGE后产生了重复行,但DISTINCT会增加排序去重的开销。或许可以考虑其他方法避免重复,比如使用更高效的字符串拆分方式,比如递归子查询或者XMLTABLE方法,这可能比CONNECT BY更高效,尤其是在Oracle 12c及以上版本支持的情况下。 另外,检查表是否有合适的索引。比如,DRB_PARAMETER_MAPPING表的FAB、PRODUCT_ID、TEST_PROGRAM等字段是否被索引,尤其是在连接条件WHERE子句中用到的字段。WAT_PARAMETER表的NAMESPECFILE_NAME是否有索引,这可能会加快连接速度。 还有,SYS_GUID()在PRIOR条件中使用,这可能会导致性能问题,因为它每次都会生成一个唯一值,可能会影响查询的执行计划。可能需要检查这部分逻辑是否有必要,或者是否存在更好的写法。 关于PIE维护需要检查的参数,用户可能想知道在运行这个查询时需要关注哪些关键参数,比如STAGE的拆分是否正确,关联条件是否准确,数据是否存在重复或缺失,以及性能相关的参数。比如,确保PARAMETER_NAMENAME的匹配正确,LIMIT_FILESPECFILE_NAME对应正确,STAGE拆分后的每个值都正确无误,以及查询的执行计划是否高效。 可能的优化步骤包括:替换CONNECT BY为递归WITH子句或使用XMLTABLE拆分字符串,移除不必要的DISTINCT,确保索引的存在,检查连接条件是否正确,避免不必要的函数使用,比如SYS_GUID(),以及分析执行计划来找出瓶颈。 需要确认用户使用的Oracle版本,因为不同版本支持的优化方法不同。例如,Oracle 12c及以上支持更强大的字符串拆分方法。另外,数据量的大小也会影响优化策略,如果数据量很大,可能需要更强调索引分区。</think>针对您提供的SQL查询,以下是优化建议及需要重点检查的参数说明: ----- ### **一、需要重点检查的参数值(PIE维护关键点)** 1. **STAGE字段拆分逻辑** - `REGEXP_SUBSTR(DPM.STAGE, '[^,]+', 1, LEVEL)`:确保逗号分隔符格式统一 - 检查拆分后`STAGE_TRUE`是否产生空值或重复项 2. **表连接条件准确性** - `DPM.PARAMETER_NAME = WP.NAME` - `DPM.LIMIT_FILE = WP.SPECFILE_NAME` - 需验证`WAT_PARAMETER`表中是否存在匹配的`NAME``SPECFILE_NAME` 3. **层级连接条件冗余** - `PRIOR`子句中重复使用所有字段(如`PRODUCT_ID, FAB`等) - 可能导致递归查询效率低下,需精简必要字段 ----- ### **二、SQL优化建议** #### **1. 替换低效的CONNECT BY层级查询** ```sql WITH split_stage AS ( SELECT DPM.FAB, DPM.PRODUCT_ID, WP.WAT_PARAMETER_ID, DPM.PARAMETER_NAME, DPM.PARAMETER_MAPPING, DPM.LIMIT_FILE, DPM.TEST_PROGRAM, TRIM(REGEXP_SUBSTR(DPM.STAGE, '[^,]+', 1, LEVEL)) AS STAGE_TRUE FROM DRB_PARAMETER_MAPPING DPM LEFT JOIN WAT_PARAMETER WP ON DPM.PARAMETER_NAME = WP.NAME AND DPM.LIMIT_FILE = WP.SPECFILE_NAME CONNECT BY LEVEL <= REGEXP_COUNT(DPM.STAGE, ',') + 1 ) SELECT DISTINCT * FROM split_stage; ``` #### **2. 使用更高效的字符串拆分方法(Oracle 12c+)** ```sql SELECT DPM.FAB, DPM.PRODUCT_ID, WP.WAT_PARAMETER_ID, DPM.PARAMETER_NAME, DPM.PARAMETER_MAPPING, DPM.LIMIT_FILE, DPM.TEST_PROGRAM, TRIM(t.column_value) AS STAGE_TRUE FROM DRB_PARAMETER_MAPPING DPM LEFT JOIN WAT_PARAMETER WP ON DPM.PARAMETER_NAME = WP.NAME AND DPM.LIMIT_FILE = WP.SPECFILE_NAME CROSS JOIN XMLTABLE(('"' || REPLACE(DPM.STAGE, ',', '","') || '"')); ``` #### **3. 索引优化** ```sql -- 在DRB_PARAMETER_MAPPING表创建组合索引 CREATE INDEX idx_dpm_main ON DRB_PARAMETER_MAPPING (FAB, PRODUCT_ID, TEST_PROGRAM, PARAMETER_NAME); -- 在WAT_PARAMETER表创建覆盖索引 CREATE INDEX idx_wp_lookup ON WAT_PARAMETER (NAME, SPECFILE_NAME) INCLUDE (WAT_PARAMETER_ID); ``` ----- ### **三、性能验证要点** 1. **执行计划分析** - 检查是否出现`FULL TABLE SCAN` - 确认索引`INDEX RANGE SCAN`是否生效 2. **数据分布验证** ```sql -- 检查STAGE字段最大分隔数量 SELECT MAX(REGEXP_COUNT(STAGE, ',')+1) FROM DRB_PARAMETER_MAPPING; -- 验证连接匹配率 SELECT COUNT(*) total, SUM(CASE WHEN WP.WAT_PARAMETER_ID IS NULL THEN 1 ELSE 0 END) miss_match FROM DRB_PARAMETER_MAPPING DPM LEFT JOIN WAT_PARAMETER WP ON ...; ``` 建议先在生产环境的测试库执行`EXPLAIN PLAN`分析,确认优化效果后再实施。注意Oracle版本差异对语法的影响。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值