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

相关文章

MySQL MCP 服务器安装配置最佳实践

《MySQLMCP服务器安装配置最佳实践》本文介绍MySQLMCP服务器的安装配置方法,本文结合实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下... 目录mysql MCP 服务器安装配置指南简介功能特点安装方法数据库配置使用MCP Inspector进行调试开发指

mysql中insert into的基本用法和一些示例

《mysql中insertinto的基本用法和一些示例》INSERTINTO用于向MySQL表插入新行,支持单行/多行及部分列插入,下面给大家介绍mysql中insertinto的基本用法和一些示例... 目录基本语法插入单行数据插入多行数据插入部分列的数据插入默认值注意事项在mysql中,INSERT I

一文详解MySQL如何设置自动备份任务

《一文详解MySQL如何设置自动备份任务》设置自动备份任务可以确保你的数据库定期备份,防止数据丢失,下面我们就来详细介绍一下如何使用Bash脚本和Cron任务在Linux系统上设置MySQL数据库的自... 目录1. 编写备份脚本1.1 创建并编辑备份脚本1.2 给予脚本执行权限2. 设置 Cron 任务2

SQL Server修改数据库名及物理数据文件名操作步骤

《SQLServer修改数据库名及物理数据文件名操作步骤》在SQLServer中重命名数据库是一个常见的操作,但需要确保用户具有足够的权限来执行此操作,:本文主要介绍SQLServer修改数据... 目录一、背景介绍二、操作步骤2.1 设置为单用户模式(断开连接)2.2 修改数据库名称2.3 查找逻辑文件名

SQL Server数据库死锁处理超详细攻略

《SQLServer数据库死锁处理超详细攻略》SQLServer作为主流数据库管理系统,在高并发场景下可能面临死锁问题,影响系统性能和稳定性,这篇文章主要给大家介绍了关于SQLServer数据库死... 目录一、引言二、查询 Sqlserver 中造成死锁的 SPID三、用内置函数查询执行信息1. sp_w

python判断文件是否存在常用的几种方式

《python判断文件是否存在常用的几种方式》在Python中我们在读写文件之前,首先要做的事情就是判断文件是否存在,否则很容易发生错误的情况,:本文主要介绍python判断文件是否存在常用的几种... 目录1. 使用 os.path.exists()2. 使用 os.path.isfile()3. 使用

canal实现mysql数据同步的详细过程

《canal实现mysql数据同步的详细过程》:本文主要介绍canal实现mysql数据同步的详细过程,本文通过实例图文相结合给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的... 目录1、canal下载2、mysql同步用户创建和授权3、canal admin安装和启动4、canal

SQL中JOIN操作的条件使用总结与实践

《SQL中JOIN操作的条件使用总结与实践》在SQL查询中,JOIN操作是多表关联的核心工具,本文将从原理,场景和最佳实践三个方面总结JOIN条件的使用规则,希望可以帮助开发者精准控制查询逻辑... 目录一、ON与WHERE的本质区别二、场景化条件使用规则三、最佳实践建议1.优先使用ON条件2.WHERE用

MySQL存储过程之循环遍历查询的结果集详解

《MySQL存储过程之循环遍历查询的结果集详解》:本文主要介绍MySQL存储过程之循环遍历查询的结果集,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录前言1. 表结构2. 存储过程3. 关于存储过程的SQL补充总结前言近来碰到这样一个问题:在生产上导入的数据发现

MySQL 衍生表(Derived Tables)的使用

《MySQL衍生表(DerivedTables)的使用》本文主要介绍了MySQL衍生表(DerivedTables)的使用,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学... 目录一、衍生表简介1.1 衍生表基本用法1.2 自定义列名1.3 衍生表的局限在SQL的查询语句select