一条存在多处性能问题的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

相关文章

Go标准库常见错误分析和解决办法

《Go标准库常见错误分析和解决办法》Go语言的标准库为开发者提供了丰富且高效的工具,涵盖了从网络编程到文件操作等各个方面,然而,标准库虽好,使用不当却可能适得其反,正所谓工欲善其事,必先利其器,本文将... 目录1. 使用了错误的time.Duration2. time.After导致的内存泄漏3. jsO

springboot循环依赖问题案例代码及解决办法

《springboot循环依赖问题案例代码及解决办法》在SpringBoot中,如果两个或多个Bean之间存在循环依赖(即BeanA依赖BeanB,而BeanB又依赖BeanA),会导致Spring的... 目录1. 什么是循环依赖?2. 循环依赖的场景案例3. 解决循环依赖的常见方法方法 1:使用 @La

MySQL双主搭建+keepalived高可用的实现

《MySQL双主搭建+keepalived高可用的实现》本文主要介绍了MySQL双主搭建+keepalived高可用的实现,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,... 目录一、测试环境准备二、主从搭建1.创建复制用户2.创建复制关系3.开启复制,确认复制是否成功4.同

MyBatis 动态 SQL 优化之标签的实战与技巧(常见用法)

《MyBatis动态SQL优化之标签的实战与技巧(常见用法)》本文通过详细的示例和实际应用场景,介绍了如何有效利用这些标签来优化MyBatis配置,提升开发效率,确保SQL的高效执行和安全性,感... 目录动态SQL详解一、动态SQL的核心概念1.1 什么是动态SQL?1.2 动态SQL的优点1.3 动态S

Mysql表的简单操作(基本技能)

《Mysql表的简单操作(基本技能)》在数据库中,表的操作主要包括表的创建、查看、修改、删除等,了解如何操作这些表是数据库管理和开发的基本技能,本文给大家介绍Mysql表的简单操作,感兴趣的朋友一起看... 目录3.1 创建表 3.2 查看表结构3.3 修改表3.4 实践案例:修改表在数据库中,表的操作主要

Python如何使用__slots__实现节省内存和性能优化

《Python如何使用__slots__实现节省内存和性能优化》你有想过,一个小小的__slots__能让你的Python类内存消耗直接减半吗,没错,今天咱们要聊的就是这个让人眼前一亮的技巧,感兴趣的... 目录背景:内存吃得满满的类__slots__:你的内存管理小助手举个大概的例子:看看效果如何?1.

Spring事务中@Transactional注解不生效的原因分析与解决

《Spring事务中@Transactional注解不生效的原因分析与解决》在Spring框架中,@Transactional注解是管理数据库事务的核心方式,本文将深入分析事务自调用的底层原理,解释为... 目录1. 引言2. 事务自调用问题重现2.1 示例代码2.2 问题现象3. 为什么事务自调用会失效3

mysql出现ERROR 2003 (HY000): Can‘t connect to MySQL server on ‘localhost‘ (10061)的解决方法

《mysql出现ERROR2003(HY000):Can‘tconnecttoMySQLserveron‘localhost‘(10061)的解决方法》本文主要介绍了mysql出现... 目录前言:第一步:第二步:第三步:总结:前言:当你想通过命令窗口想打开mysql时候发现提http://www.cpp

MySQL大表数据的分区与分库分表的实现

《MySQL大表数据的分区与分库分表的实现》数据库的分区和分库分表是两种常用的技术方案,本文主要介绍了MySQL大表数据的分区与分库分表的实现,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有... 目录1. mysql大表数据的分区1.1 什么是分区?1.2 分区的类型1.3 分区的优点1.4 分

MySQL错误代码2058和2059的解决办法

《MySQL错误代码2058和2059的解决办法》:本文主要介绍MySQL错误代码2058和2059的解决办法,2058和2059的错误码核心都是你用的客户端工具和mysql版本的密码插件不匹配,... 目录1. 前置理解2.报错现象3.解决办法(敲重点!!!)1. php前置理解2058和2059的错误