一条存在多处性能问题的SQL分析

2024-01-06 13:38

本文主要是介绍一条存在多处性能问题的SQL分析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

背景:定制了一个脚本 排查数据库中具有潜在风险的SQL,显示下面这条SQL触发了多个风险 执行时间是33分钟

SELECT T1.DATA_DT,T1.BRANCH_NO,T5.FINANCE_ORG_NO,DECODE(T2.CUST_TYP, '01', '1', '02', '0', NULL),SUBSTR(T1.KEY_1, 4, 16),SUBSTR(T1.KEY_1, 4, 16),T4.PROD_TYP_CD,TO_VALID_DATE(2415020 + T1.ACCT_OPEN_DT),CASEWHEN T4.PROD_CD IN ('31060010', '41060010', '31060020', '41170010') THENTO_DATE('19990101', 'YYYYMMDD')WHEN T4.PROD_CD IN ('41090310', '41090110', '41090010', '41080010','31260010', '31080020', '31080010', '41160010', '31090310', '31090110','31090010','31090410') THENTO_DATE('19990107', 'YYYYMMDD')WHEN T4.PROD_CD = '41110010' THENNULLELSETO_DATE(SUBSTR(T1.OD_VISA_AREA, 23, 8), 'YYYY-MM-DD')END,T1.CURRENCY,T1.CURR_BAL,CASEWHEN T4.PROD_TYP_CD IN ('D02', 'D03') THEN'RF02'ELSE'RF01'END,CASE T1.VAR_INT_RATEWHEN 0 THEN(SELECT B.RATEFROM S_CCC_MMMM_H_TTTT BWHERE B.BASE_ID = SUBSTR(T3.CR_ID_DET, 1, 4)AND B.DATA_DT = TO_DATE('2017-12-31', 'YYYY-MM-DD')AND TRIM(B.RATE_ID) = SUBSTR(T3.CR_ID_DET, 5, 3)AND TO_CHAR(TO_VALID_DATE(2415020 + (999999999 - B.BASM_DATE)),'YYYYMMDD') || B.BASM_TIME =(SELECT MAX(TO_CHAR(TO_VALID_DATE(2415020 +(999999999 - S.BASM_DATE)),'YYYYMMDD') || S.BASM_TIME)FROM S_CCC_MMMM_H_TTTT SWHERE S.BASE_ID = B.BASE_IDAND S.DATA_DT = TO_DATE('2017-12-31', 'YYYY-MM-DD')AND S.RATE_ID = B.RATE_IDAND TO_VALID_DATE(2415020 + (999999999 - S.BASM_DATE)) <=TO_DATE('2017-12-31', 'YYYY-MM-DD')))ELSET1.VAR_INT_RATEEND,T2.CUST_NM,''FROM S_CCC_MMMM T1LEFT JOIN S_I_CCCC_OOOO T2 ON LPAD(T2.CUST_NUM, 16, '0') =T1.CUSTOMER_NOINNER JOIN S_SSS_DDDD T3 ON T3.SYS = 'INV' --INV代表存款AND T3.TYPE = T1.ACCT_TYPEAND T3.INT_CAT = T1.INT_CATINNER JOIN M_CCCC_DDD_CCC_SSS_TMP T4 ON T1.ACCT_TYPE || T1.INT_CAT = T4.PROD_CD AND T4.PROD_TYP_CD <> 'D051' AND T4.BIZ_CLS_CD <> '1'INNER JOIN JRTJAPP.RRR_OOO_OOOO T5 ON T1.BRANCH_NO = T5.ORG_NOWHERE T1.CURR_BAL <> 0AND T1.DATA_DT = TO_DATE('2017-12-31', 'YYYY-MM-DD')AND T1.CURRENCY = 'CNY'AND SUBSTR(T1.GL_CLASS_CODE, 10, 8) <> '13090101';Plan hash value: 1747367332------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name                   | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                        |     1 |   407 |   538K  (1)| 01:47:38 |       |       |
|*  1 |  FILTER                       |                        |       |       |            |          |       |       |
|   2 |   PARTITION RANGE SINGLE      |                        |     1 |    72 |    13   (0)| 00:00:01 |     2 |     2 |
|*  3 |    TABLE ACCESS FULL          | S_CCC_MMMM_H_TTTT      |     1 |    72 |    13   (0)| 00:00:01 |     2 |     2 |
|   4 |   SORT AGGREGATE              |                        |     1 |    59 |            |          |       |       |
|   5 |    PARTITION RANGE SINGLE     |                        |     1 |    59 |    13   (0)| 00:00:01 |     2 |     2 |
|*  6 |     TABLE ACCESS FULL         | S_CCC_MMMM_H_TTTT      |     1 |    59 |    13   (0)| 00:00:01 |     2 |     2 |
|*  7 |  HASH JOIN OUTER              |                        |     1 |   407 |   538K  (1)| 01:47:38 |       |       |
|   8 |   NESTED LOOPS                |                        |       |       |            |          |       |       |
|   9 |    NESTED LOOPS               |                        |     1 |   387 |   490K  (1)| 01:38:03 |       |       |
|* 10 |     HASH JOIN                 |                        |     1 |   377 |   490K  (1)| 01:38:03 |       |       |
|* 11 |      HASH JOIN                |                        |     1 |   354 |   490K  (1)| 01:38:03 |       |       |
|* 12 |       TABLE ACCESS FULL       | S_CCC_MMMM             |     1 |   313 |   490K  (1)| 01:38:03 |       |       |
|* 13 |       TABLE ACCESS FULL       | M_CCCC_DDD_CCC_SSS_TMP |   158 |  6478 |     5   (0)| 00:00:01 |       |       |
|* 14 |      TABLE ACCESS FULL        | S_SSS_DDDD             |  1100 | 25300 |     7   (0)| 00:00:01 |       |       |
|* 15 |     INDEX RANGE SCAN          | PK_RRR_OOO_OOOO        |     1 |       |     1   (0)| 00:00:01 |       |       |
|  16 |    TABLE ACCESS BY INDEX ROWID| RRR_OOO_OOOO           |     1 |    10 |     2   (0)| 00:00:01 |       |       |
|  17 |   TABLE ACCESS FULL           | S_I_CCCC_OOOO          |    23M|   456M| 47781   (2)| 00:09:34 |       |       |
------------------------------------------------------------------------------------------------------------------------Predicate Information (identified by operation id):
---------------------------------------------------1 - filter(TO_CHAR("TO_VALID_DATE"(2415020+(999999999-"B"."BASM_DATE")),'YYYYMMDD')||TO_CHAR("B"."BASM_TIME")= (SELECT MAX(TO_CHAR("TO_VALID_DATE"(2415020+(999999999-"S"."BASM_DATE")),'YYYYMMDD')||TO_CHAR("S"."BASM_TIME")) FROM "S_CCC_MMMM_H_TTTT" "S" WHERE "S"."BASE_ID"=:B1 AND "S"."DATA_DT"=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "S"."RATE_ID"=:B2 AND "TO_VALID_DATE"(2415020+(999999999-"S"."BASM_DATE"))<=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))3 - filter("B"."DATA_DT"=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "B"."BASE_ID"=SUBSTR(:B1,1,4) AND TRIM("B"."RATE_ID")=SUBSTR(:B2,5,3))6 - filter("S"."BASE_ID"=:B1 AND "S"."DATA_DT"=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "S"."RATE_ID"=:B2 AND "TO_VALID_DATE"(2415020+(999999999-"S"."BASM_DATE"))<=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))7 - access("T1"."CUSTOMER_NO"=LPAD("T2"."CUST_NUM"(+),16,'0'))10 - access("T3"."TYPE"="T1"."ACCT_TYPE" AND "T3"."INT_CAT"="T1"."INT_CAT")11 - access("T4"."PROD_CD"="T1"."ACCT_TYPE"||"T1"."INT_CAT")12 - filter("T1"."DATA_DT"=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "T1"."CURR_BAL"<>0 AND SUBSTR("T1"."GL_CLASS_CODE",10,8)<>'13090101' AND "T1"."CURRENCY"='CNY')13 - filter("T4"."PROD_TYP_CD"<>'D051' AND "T4"."BIZ_CLS_CD"<>'1')14 - filter("T3"."SYS"='INV')15 - access("T1"."BRANCH_NO"="T5"."ORG_NO")Note
------ dynamic sampling used for this statement (level=2)用定制的脚本先抓取出SQL涉及到的表和索引的一些信息
OWNER      OBJECT_TYPE          OBJECT_NAME                    ALIAS      PARTITIONED    SIZE_MB   NUM_ROWS ESTIMATE_P LAST_ANALYZED STATUS
---------- -------------------- ------------------------------ ---------- ----------- ---------- ---------- ---------- ------------- --------------
JRTJ       TABLE                M_CCCC_DDD_CCC_SSS_TMP         T4         NO               0.125            %                        统计信息过期
JRTJAPP    TABLE                RRR_OOO_OOOO                   T5         NO               0.375       3043 100%       2018/1/2 19:2 统计信息未过期
JRTJ       TABLE                S_CCC_MMMM_H_TTTT              B | S      YES              1.125       6867 100%       2018/1/2 19:2 统计信息未过期
JRTJ       TABLE                S_SSS_DDDD                     T3         NO              0.1875       1100 100%       2018/1/2 19:1 统计信息未过期
JRTJ       TABLE                S_CCC_MMMM                     T1         NO               14144   36104177 100%       2018/1/2 19:2 统计信息未过期
JRTJ       TABLE                S_I_CCCC_OOOO                  T2         NO                1411   23955089 100%       2018/1/2 19:2 统计信息未过期
JRTJAPP    INDEX (UNIQUE)       PK_RRR_OOO_OOOO                NOALIAS    NO               0.125       3043 100%       2018/1/2 19:2 统计信息未过期

分析过程:这个SQL从语句的写法和执行计划可以看出来有3处可能引起性能问题的点:标量子查询、有两个儿子节点的FILTER、嵌套循环
一、标量子查询
1.怎么找到标量子查询
SQL中SELECT后面FROM前面的子查询,并且和主查询存在关联关系,这一类的子查询就属于标量子查询
在执行计划中 ID=1 有兄弟ID,父ID不是连接方式(NEST LOOP ,HASH,SMJ等等)这一类就属于标量子查询,请看执行计划ID=1和ID=7
2.标量子查询有什么缺点
标量子查询的主查询返回多少行,标量子查询就会被执行多少次。所以对性能影响主要取决于主查询的返回的行数,
一般主查询返回在1000行以内,标量对性能没有丝毫影响。10000行(这里取决于数据库服务器性能,性能特别好的10w)往上才会产生性能问题。
所以标量子查询的缺点很明显:每次主查询返回的结果集不同,会影响到整个SQL的性能,主查询返回的结果集如果随着时间的推移而增加,这个性能问题才会慢慢浮现
一旦引起的性能问题,除非改写SQL。没有任何优化余地
3.怎么判断标量子查询是否对这个SQL产生了影响。
如果想快速判断,直接注释掉标量子查询的那段代码,再次运行SQL观察性能有没有提升
如果想准确判断,只能先count(*)查出主查询返回的结果集行数是否超过了临界值(10000)
两种方法都会消耗掉大量时间。所以标量子查询的性能问题都使用排除法在最后判断
4.怎么处理标量子查询引起的性能问题
使用外连接的方式对标量子查询进行等价改写

二、有两个儿子节点的FILTER
FILTER在执行计划中如果只有<=1的儿子ID,本身只表示一个简单的过滤,没有任何性能问题。
如果下面有两个以上的儿子ID,这时候FILTER则是一个连接方式,类似嵌套循环ID=1 FILTER下面有两个儿子ID 分别是2和4,
表示ID=2 PARTITION RANGE SINGLE 返回N行
ID=4 SORT AGGREGATE就会被执行N次,也就是ID=4最终的儿子节点ID=6 TABLE ACCESS FULL         | S_CCC_MMMM_H_TTTT会执行N次
这个N的临界值同样是10000
所以这时候我们需要查询ID=3  TABLE ACCESS FULL          | S_CCC_MMMM_H_TTTT 这一步返回的行数,
从上面的查询可看出S_CCC_MMMM_H_TTTT的NUM_ROWS是6867行
而且表上面有过滤3 - filter("B"."DATA_DT"=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND 
                "B"."BASE_ID"=SUBSTR(:B1,1,4) AND TRIM("B"."RATE_ID")=SUBSTR(:B2,5,3))
所以ID=3返回的结果集 肯定<10000行,其父ID=2同样
上面我们分析到ID=4最终的儿子节点ID=6 TABLE ACCESS FULL         | S_CCC_MMMM_H_TTTT会执行N次  可以确定这个N<10000没有性能问题
但是如果ID=6的这个表S_CCC_MMMM_H_TTTT很大,同样会出现大的性能问题(一个大表被TABLE ACCESS FULL一次都是不能容忍的,何况几千次)
当然这里面查到ID=6的这个表S_CCC_MMMM_H_TTTT很小只有1MB,否则需要在ID=6的这个表S_CCC_MMMM_H_TTTT连接列上面建索引来避免几千次的TABLE ACCESS FULL

三、嵌套的驱动表可能返回很大的结果集
ID=9这个NEST LOOP 的驱动表是ID=10这个HASH的结果集(如果这个结果集过大很容易),请看ID=11,12,13这三个
ID=12 这个表S_CCC_MMMM的NUM_ROWS是36104177 行,这是一张事实表
ID=13 这个表M_CCCC_DDD_CCC_SSS_TMP经过查询很小,是一个参数表,也就是说,事实表和参数表做关联的时候,返回的结果集约等于事实表的NUM_ROWS(因为参数表不起过滤作用)
对于事实表本身的过滤12 - filter("T1"."DATA_DT"=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "T1"."CURR_BAL"<>0 
              AND SUBSTR("T1"."GL_CLASS_CODE",10,8)<>'13090101' AND "T1"."CURRENCY"='CNY') 但是返回结也在10w行数量级,所以嵌套循环的驱动表会返回10w+行
被驱动表会被访问10w+次,所以真正的性能瓶颈 在这里 只需要将NEST LOOP 改为使用HASH的连接方式即可


四、对于HINT的使用
首先注意格式,空格。USE_HASH里面的表之间可以用逗号或者空格 隔开
执行顺序,单使用USE_HASH(T1,T4,T3,T5) 有时候无法控制顺序,使用ORDERED强制让连接变得有序。因为顺序错乱的情况下可能会出现笛卡尔积
    举个例子:WHERE A.ID=B.ID AND A.ID=C.ID  如果USE_HASH先让B,C作关联结果集关联A,会因为B,C关联条件的缺失造成笛卡尔积,当然这种概率不大,只有在统计信息过期的情况下才会出现的小概率事件
 

所以优化后的SQL如下:
SELECT /*+ USE_HASH(T1,T4,T3,T5) ORDERED */T1.DATA_DT,T1.BRANCH_NO,T5.FINANCE_ORG_NO,DECODE(T2.CUST_TYP, '01', '1', '02', '0', NULL),SUBSTR(T1.KEY_1, 4, 16),SUBSTR(T1.KEY_1, 4, 16),T4.PROD_TYP_CD,TO_VALID_DATE(2415020 + T1.ACCT_OPEN_DT),CASEWHEN T4.PROD_CD IN ('31060010', '41060010', '31060020', '41170010') THENTO_DATE('19990101', 'YYYYMMDD')WHEN T4.PROD_CD IN ('41090310', '41090110', '41090010', '41080010','31260010', '31080020', '31080010', '41160010', '31090310', '31090110','31090010','31090410') THENTO_DATE('19990107', 'YYYYMMDD')WHEN T4.PROD_CD = '41110010' THENNULLELSETO_DATE(SUBSTR(T1.OD_VISA_AREA, 23, 8), 'YYYY-MM-DD')END,T1.CURRENCY,T1.CURR_BAL,CASEWHEN T4.PROD_TYP_CD IN ('D02', 'D03') THEN'RF02'ELSE'RF01'END,CASE T1.VAR_INT_RATEWHEN 0 THEN(SELECT B.RATEFROM S_CCC_MMMM_H_TTTT BWHERE B.BASE_ID = SUBSTR(T3.CR_ID_DET, 1, 4)AND B.DATA_DT = TO_DATE('2017-12-31', 'YYYY-MM-DD')AND TRIM(B.RATE_ID) = SUBSTR(T3.CR_ID_DET, 5, 3)AND TO_CHAR(TO_VALID_DATE(2415020 + (999999999 - B.BASM_DATE)),'YYYYMMDD') || B.BASM_TIME =(SELECT MAX(TO_CHAR(TO_VALID_DATE(2415020 +(999999999 - S.BASM_DATE)),'YYYYMMDD') || S.BASM_TIME)FROM S_CCC_MMMM_H_TTTT SWHERE S.BASE_ID = B.BASE_IDAND S.DATA_DT = TO_DATE('2017-12-31', 'YYYY-MM-DD')AND S.RATE_ID = B.RATE_IDAND TO_VALID_DATE(2415020 + (999999999 - S.BASM_DATE)) <=TO_DATE('2017-12-31', 'YYYY-MM-DD')))ELSET1.VAR_INT_RATEEND,T2.CUST_NM,''FROM S_CCC_MMMM T1LEFT JOIN S_I_CCCC_OOOO T2 ON LPAD(T2.CUST_NUM, 16, '0') =T1.CUSTOMER_NOINNER JOIN S_SSS_DDDD T3 ON T3.SYS = 'INV' --INV代表存款AND T3.TYPE = T1.ACCT_TYPEAND T3.INT_CAT = T1.INT_CATINNER JOIN M_CCCC_DDD_CCC_SSS_TMP T4 ON T1.ACCT_TYPE || T1.INT_CAT = T4.PROD_CD AND T4.PROD_TYP_CD <> 'D051' AND T4.BIZ_CLS_CD <> '1'INNER JOIN JRTJAPP.RRR_OOO_OOOO T5 ON T1.BRANCH_NO = T5.ORG_NOWHERE T1.CURR_BAL <> 0AND T1.DATA_DT = TO_DATE('2017-12-31', 'YYYY-MM-DD')AND T1.CURRENCY = 'CNY'AND SUBSTR(T1.GL_CLASS_CODE, 10, 8) <> '13090101';Plan hash value: 3497671024-------------------------------------------------------------------------------------------------------------------
| Id  | Operation                | Name                   | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT         |                        |     1 |   407 |   538K  (1)| 01:47:38 |       |       |
|*  1 |  FILTER                  |                        |       |       |            |          |       |       |
|   2 |   PARTITION RANGE SINGLE |                        |     1 |    72 |    13   (0)| 00:00:01 |     2 |     2 |
|*  3 |    TABLE ACCESS FULL     | S_CCC_MMMM_H_TTTT      |     1 |    72 |    13   (0)| 00:00:01 |     2 |     2 |
|   4 |   SORT AGGREGATE         |                        |     1 |    59 |            |          |       |       |
|   5 |    PARTITION RANGE SINGLE|                        |     1 |    59 |    13   (0)| 00:00:01 |     2 |     2 |
|*  6 |     TABLE ACCESS FULL    | S_CCC_MMMM_H_TTTT      |     1 |    59 |    13   (0)| 00:00:01 |     2 |     2 |
|*  7 |  HASH JOIN OUTER         |                        |     1 |   407 |   538K  (1)| 01:47:38 |       |       |
|*  8 |   HASH JOIN              |                        |     1 |   387 |   490K  (1)| 01:38:03 |       |       |
|*  9 |    HASH JOIN             |                        |     1 |   377 |   490K  (1)| 01:38:03 |       |       |
|* 10 |     HASH JOIN            |                        |     1 |   354 |   490K  (1)| 01:38:03 |       |       |
|* 11 |      TABLE ACCESS FULL   | S_CCC_MMMM             |     1 |   313 |   490K  (1)| 01:38:03 |       |       |
|* 12 |      TABLE ACCESS FULL   | M_CCCC_DDD_CCC_SSS_TMP |   158 |  6478 |     5   (0)| 00:00:01 |       |       |
|* 13 |     TABLE ACCESS FULL    | S_SSS_DDDD             |  1100 | 25300 |     7   (0)| 00:00:01 |       |       |
|  14 |    TABLE ACCESS FULL     | RRR_OOO_OOOO           |  3043 | 30430 |    13   (0)| 00:00:01 |       |       |
|  15 |   TABLE ACCESS FULL      | S_I_CCCC_OOOO          |    23M|   456M| 47781   (2)| 00:09:34 |       |       |
-------------------------------------------------------------------------------------------------------------------Predicate Information (identified by operation id):
---------------------------------------------------1 - filter(TO_CHAR("TO_VALID_DATE"(2415020+(999999999-"B"."BASM_DATE")),'YYYYMMDD')||TO_CHAR("B"."BASM_TIME")= (SELECT MAX(TO_CHAR("TO_VALID_DATE"(2415020+(999999999-"S"."BASM_DATE")),'YYYYMMDD')||TO_CHAR("S"."BASM_TIME")) FROM "S_CCC_MMMM_H_TTTT" "S" WHERE "S"."BASE_ID"=:B1 AND "S"."DATA_DT"=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "S"."RATE_ID"=:B2 AND "TO_VALID_DATE"(2415020+(999999999-"S"."BASM_DATE"))<=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))3 - filter("B"."DATA_DT"=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "B"."BASE_ID"=SUBSTR(:B1,1,4) AND TRIM("B"."RATE_ID")=SUBSTR(:B2,5,3))6 - filter("S"."BASE_ID"=:B1 AND "S"."DATA_DT"=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "S"."RATE_ID"=:B2 AND "TO_VALID_DATE"(2415020+(999999999-"S"."BASM_DATE"))<=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))7 - access("T1"."CUSTOMER_NO"=LPAD("T2"."CUST_NUM"(+),16,'0'))8 - access("T1"."BRANCH_NO"="T5"."ORG_NO")9 - access("T3"."TYPE"="T1"."ACCT_TYPE" AND "T3"."INT_CAT"="T1"."INT_CAT")10 - access("T4"."PROD_CD"="T1"."ACCT_TYPE"||"T1"."INT_CAT")11 - filter("T1"."DATA_DT"=TO_DATE(' 2017-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "T1"."CURR_BAL"<>0 AND SUBSTR("T1"."GL_CLASS_CODE",10,8)<>'13090101' AND "T1"."CURRENCY"='CNY')12 - filter("T4"."PROD_TYP_CD"<>'D051' AND "T4"."BIZ_CLS_CD"<>'1')13 - filter("T3"."SYS"='INV')Note
------ dynamic sampling used for this statement (level=2)

优化完之后 7min就出结果。可以看出优化完之后,标量子查询和FILTER都在,但是因为他们不是性能瓶颈所以不需要处理。

这篇关于一条存在多处性能问题的SQL分析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/576520

相关文章

mybatis和mybatis-plus设置值为null不起作用问题及解决

《mybatis和mybatis-plus设置值为null不起作用问题及解决》Mybatis-Plus的FieldStrategy主要用于控制新增、更新和查询时对空值的处理策略,通过配置不同的策略类型... 目录MyBATis-plusFieldStrategy作用FieldStrategy类型每种策略的作

linux下多个硬盘划分到同一挂载点问题

《linux下多个硬盘划分到同一挂载点问题》在Linux系统中,将多个硬盘划分到同一挂载点需要通过逻辑卷管理(LVM)来实现,首先,需要将物理存储设备(如硬盘分区)创建为物理卷,然后,将这些物理卷组成... 目录linux下多个硬盘划分到同一挂载点需要明确的几个概念硬盘插上默认的是非lvm总结Linux下多

Springboot中分析SQL性能的两种方式详解

《Springboot中分析SQL性能的两种方式详解》文章介绍了SQL性能分析的两种方式:MyBatis-Plus性能分析插件和p6spy框架,MyBatis-Plus插件配置简单,适用于开发和测试环... 目录SQL性能分析的两种方式:功能介绍实现方式:实现步骤:SQL性能分析的两种方式:功能介绍记录

使用 sql-research-assistant进行 SQL 数据库研究的实战指南(代码实现演示)

《使用sql-research-assistant进行SQL数据库研究的实战指南(代码实现演示)》本文介绍了sql-research-assistant工具,该工具基于LangChain框架,集... 目录技术背景介绍核心原理解析代码实现演示安装和配置项目集成LangSmith 配置(可选)启动服务应用场景

oracle DBMS_SQL.PARSE的使用方法和示例

《oracleDBMS_SQL.PARSE的使用方法和示例》DBMS_SQL是Oracle数据库中的一个强大包,用于动态构建和执行SQL语句,DBMS_SQL.PARSE过程解析SQL语句或PL/S... 目录语法示例注意事项DBMS_SQL 是 oracle 数据库中的一个强大包,它允许动态地构建和执行

Python Jupyter Notebook导包报错问题及解决

《PythonJupyterNotebook导包报错问题及解决》在conda环境中安装包后,JupyterNotebook导入时出现ImportError,可能是由于包版本不对应或版本太高,解决方... 目录问题解决方法重新安装Jupyter NoteBook 更改Kernel总结问题在conda上安装了

pip install jupyterlab失败的原因问题及探索

《pipinstalljupyterlab失败的原因问题及探索》在学习Yolo模型时,尝试安装JupyterLab但遇到错误,错误提示缺少Rust和Cargo编译环境,因为pywinpty包需要它... 目录背景问题解决方案总结背景最近在学习Yolo模型,然后其中要下载jupyter(有点LSVmu像一个

SQL 中多表查询的常见连接方式详解

《SQL中多表查询的常见连接方式详解》本文介绍SQL中多表查询的常见连接方式,包括内连接(INNERJOIN)、左连接(LEFTJOIN)、右连接(RIGHTJOIN)、全外连接(FULLOUTER... 目录一、连接类型图表(ASCII 形式)二、前置代码(创建示例表)三、连接方式代码示例1. 内连接(I

解决jupyterLab打开后出现Config option `template_path`not recognized by `ExporterCollapsibleHeadings`问题

《解决jupyterLab打开后出现Configoption`template_path`notrecognizedby`ExporterCollapsibleHeadings`问题》在Ju... 目录jupyterLab打开后出现“templandroidate_path”相关问题这是 tensorflo

如何解决Pycharm编辑内容时有光标的问题

《如何解决Pycharm编辑内容时有光标的问题》文章介绍了如何在PyCharm中配置VimEmulator插件,包括检查插件是否已安装、下载插件以及安装IdeaVim插件的步骤... 目录Pycharm编辑内容时有光标1.如果Vim Emulator前面有对勾2.www.chinasem.cn如果tools工