数据异常使执行计划没有使用期望索引导致查询效率降低

最新推荐文章于 2023-05-23 12:00:20 发布
原创 最新推荐文章于 2023-05-23 12:00:20 发布 · 935 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#oracle

系统割接后，A_S表产生大量account级别数据导致查询效率低下。通过分析发现大部分记录的subscr_no和subscr_no_resets为0，使得Oracle选择全表扫描而非索引扫描，进而导致性能问题。通过调整执行计划，采用特定索引，显著提高了查询效率。

系统割接之后，用户资料表A_S表产生很多account级别的数据。程序在查询此表时(下表第一个SQL)，根据AWR report，消耗资源严重。


SQL ordered by Gets

  • Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
  • %Total - Buffer Gets as a percentage of Total Buffer Gets
  • %CPU - CPU Time as a percentage of Elapsed Time
  • %IO - User I/O Time as a percentage of Elapsed Time
  • Total Buffer Gets: 503,703,670
  • Captured SQL account for 97.7% of Total

Buffer Gets

Executions

Gets per Exec

%Total

Elapsed Time (s)

%CPU

%IO

SQL Id

SQL Module

SQL Text

481,852,220

1,544

312,080.45

95.66

4,883.83

55.9

0

7mn0s0rj9rcaq

 

Select /*+ USE_NL(a b c) */ a....

3,184,950

8,646

368.37

0.63

36.79

49.5

.3

6hwxvxahyup08

URE_U9

begin PUBLIC_PKG_NOTIF_CIRQ . ...

2,513,179

233

10,786.18

0.50

170.38

58.4

0

060zmjty9da91

URE_U9

begin PUBLIC_PKG_NOTIF_CIRQ . ...

2,277,956

9

253,106.22

0.45

23.97

53.8

0

c4qkh3s9p2384

oracle@sdp1 (TNS V1-V3)

SELECT /*+ USE_NL ("A2") USE_N...

1,545,893

386,472

4.00

0.31

7.47

50.8

.6

dtkk2mrmqpj34

URE_U9

SELECT SUB_MSISDN, NVL(IMSI, '...

1,539,048

384,761

4.00

0.31

7.57

50.8

.7

75v522q8bhcyv

URE_U9

SELECT SUB_MSISDN, NVL(IMSI, '...

550,432

668

824.00

0.11

8.12

55.5

0

9ngq9b1zmyu0k

LTP@sdp1 (TNS V1-V3)

SELECT EAC.TABLE_NAME, EAC.BIL...

420,264

234

1,796.00

0.08

28.20

59

0

3bn7wp5vypt1g

URE_U9

select count(*) from NOTIF_QUE...

418,468

233

1,796.00

0.08

28.76

57.5

0

18c1z8x947qr8

URE_U9

SELECT COUNT(1) FROM NOTIF_QUE...

418,468

234

1,788.32

0.08

28.09

58.9

0

2k4rfb2dhbad7

URE_U9

select count(*) from NOTIF_QUE...



分析得知，在A_S表的3620724条记录中, 3620017条记录的subscr_no和subscr_no_resets为0.

select current_state, count(*) from account_subscriber group by current_state order by 1;

CURRENT_STATE   COUNT(*)

------------- ----------

            0    3620017

            1          1

            2        543

           50         30

           60        113


select count(*) from account_subscriber where subscr_no=0 and subscr_no_resets=0 and account_no!=0;

  COUNT(*)

----------

   3620017


因为大部分的subscr_no和subscr_no_resets为0，oracle认为原有主键("SUBSCR_NO", "SUBSCR_NO_RESETS", "ACCOUNT_NO")的索引并不需要，使用全表扫描的策略要优于使用索引。全表扫描使查询变慢，出现ORA-01013的原因(ORA-01013原因暂时不明，不确定是oracle机制还是程序有查询时间控制，一旦超时，就取消查询)。


---------------------------------------------------------------------------------------------------------------

| Id  | Operation                      | Name                 | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |

---------------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT               |                      |       |       |       |  5591K(100)|          |

|   1 |  SORT ORDER BY                 |                      |  4712K|  4678M|  5259M|  5591K  (1)| 21:44:43 |

|   2 |   NESTED LOOPS OUTER           |                      |  4712K|  4678M|       |  4948K  (1)| 19:14:33 |

|   3 |    NESTED LOOPS OUTER          |                      |  4344K|  3500M|       |  2770K  (2)| 10:46:25 |

|   4 |     NESTED LOOPS OUTER         |                      |  4344K|  1831M|       |   592K  (4)| 02:18:16 |

|   5 |      TABLE ACCESS FULL         | BULK_SUBSCRIBER_JOIN |     6 |   234 |       |     2   (0)| 00:00:01 |

|*  6 |      TABLE ACCESS FULL         | ACCOUNT_SUBSCRIBER   |   724K|   278M|       | 98761   (4)| 00:23:03 |

|   7 |     TABLE ACCESS BY INDEX ROWID| ACCOUNT_SUBSCRIBER   |     1 |   403 |       |     1   (0)| 00:00:01 |

|*  8 |      INDEX RANGE SCAN          | I_ACCOUNT_NO         |     1 |       |       |     1   (0)| 00:00:01 |

|   9 |    TABLE ACCESS BY INDEX ROWID | ACCOUNT_SUBSCRIBER   |     1 |   196 |       |     1   (0)| 00:00:01 |

|* 10 |     INDEX RANGE SCAN           | I_ACCOUNT_NO         |     1 |       |       |     1   (0)| 00:00:01 |

---------------------------------------------------------------------------------------------------------------


Predicate Information (identified by operation id):

---------------------------------------------------

   6 - filter(("D"."SUBSCR_NO"="A"."SUBSCR_NO" AND "D"."SUBSCR_NO_RESETS"="A"."SUBSCR_NO_RESETS"))

   8 - access("C"."ACCOUNT_NO"="A"."TARGET_ACCOUNT_NO")

  10 - access("B"."ACCOUNT_NO"=DECODE("A"."ACCOUNT_NO",0,"A"."PARENT_ACCOUNT_NO","A"."ACCOUNT_NO"))


联系DBA，强制使oracle执行下列执行计划

--------------------------------------------------------------------------------------------------------

| Id  | Operation                       | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |

--------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT                |                      |     1 |  1248 |    12   (9)| 00:00:01 |

|   1 |  SORT ORDER BY                  |                      |     1 |  1248 |    12   (9)| 00:00:01 |

|   2 |   NESTED LOOPS OUTER            |                      |     1 |  1248 |    11   (0)| 00:00:01 |

|   3 |    NESTED LOOPS OUTER           |                      |     1 |   845 |    10   (0)| 00:00:01 |

|   4 |     NESTED LOOPS OUTER          |                      |     1 |   442 |     9   (0)| 00:00:01 |

|   5 |      TABLE ACCESS FULL          | BULK_SUBSCRIBER_JOIN |     1 |    39 |     2   (0)| 00:00:01 |

|   6 |      TABLE ACCESS BY INDEX ROWID| ACCOUNT_SUBSCRIBER   |   724K|   278M|     7   (0)| 00:00:01 |

|*  7 |       INDEX RANGE SCAN          | ASR_PK               |    14 |       |     1   (0)| 00:00:01 |

|   8 |     TABLE ACCESS BY INDEX ROWID | ACCOUNT_SUBSCRIBER   |     1 |   403 |     1   (0)| 00:00:01 |

|*  9 |      INDEX RANGE SCAN           | I_ACCOUNT_NO         |     1 |       |     1   (0)| 00:00:01 |

|  10 |    TABLE ACCESS BY INDEX ROWID  | ACCOUNT_SUBSCRIBER   |     1 |   403 |     1   (0)| 00:00:01 |

|* 11 |     INDEX RANGE SCAN            | I_ACCOUNT_NO         |     1 |       |     1   (0)| 00:00:01 |

--------------------------------------------------------------------------------------------------------


Predicate Information (identified by operation id):

---------------------------------------------------

   7 - access("D"."SUBSCR_NO"="A"."SUBSCR_NO"(+) AND "D"."SUBSCR_NO_RESETS"="A"."SUBSCR_NO_RESETS"(+))

   9 - access("B"."ACCOUNT_NO"(+)=DECODE("A"."ACCOUNT_NO",0,"A"."PARENT_ACCOUNT_NO","A"."ACCOUNT_NO"))

  11 - access("C"."ACCOUNT_NO"(+)="A"."TARGET_ACCOUNT_NO")

AI动态定价如何提升数据交易效率？架构师实战案例拆解
AI天才研究院
07-26 1321
标题：AI动态定价：数据交易效率革命的架构设计与实战案例深度解析 关键词：AI动态定价、数据交易效率、机器学习定价模型、实时决策系统、数据资产估值、架构设计模式、多模态数据定价 摘要：数据作为数字经济时代的核心生产要素，其交易效率直接制约着数字经济的发展速度与质量。传统静态定价机制已无法应对数据商品的非竞争性、易复制性和价值不确定性等固有特性，导致数据交易市场普遍存在定价失衡、供需错配和效率低下等问题。本文从第一性原理出发，系统剖析AI动态定价如何通过融合机器学习、实时数据分析和经济博弈理论，构建适应数据商
全面解析！能源效率优化AI智能体提升能源使用效率，AI应用架构师不可错过
AI天才研究院
07-25 923
能源是现代社会运转的基石。然而，随着全球经济的快速发展和人口的持续增长，能源需求与日俱增，而传统化石能源的储量有限且使用过程中会产生大量温室气体，引发了严重的能源安全和环境问题。“双碳”（碳达峰、碳中和）目标已成为全球共识，各国政府纷纷出台严格的能源政策和碳排放法规。对于企业而言，能源成本在运营支出中占比日益提高，尤其是在高耗能行业（如钢铁、水泥、化工、制造等）。提升能源效率，意味着直接降低生产成本，提升市场竞争力。同时，积极响应环保政策、履行社会责任，也是企业可持续发展的必然要求。
34.Oracle深度学习笔记——12C的AWR初步解读
热门推荐
badman250的专栏
03-10 4万+
34.Oracle深度学习笔记——12C的AWR初步解读 关于AWR，蛤蟆也经常看。因为经常看别人给出的建议，很难有深刻体会。对此，计划花费几个晚上时间好好体会一把并记录下来。此处以单实例为例。列出目录便于整体理解。 目录 1.      快照生成方法... 1 2.      生成AWR报告... 1 3.      系统描述... 3 4.      报告汇总... 3
oracle数据库主机CPU使用率高问题的分析及SQL优化
还不算晕的专栏
05-23 4052
因此建议改写SQL，使用绑定变量。对TOP SQL的SQL文本进行分析，这些SQL的文本事实上一致，因未使用绑定变量，只在一些WHERE条件中不同；对TOP SQL的SQL文本进行分析，这些SQL的文本基本一致，只在一些WHERE条件中不同；当前的应急解决方案是针对出现问题的SQL，进行相应的索引创建，从而降低逻辑读(逻辑读会消耗CPU资源)，提高SQL执行效率，缓解当前CPU使用率高的问题。对TOP SQL的SQL文本进行分析，这些SQL的文本事实上一致，因未使用绑定变量，只在一些WHERE条件中不同；
oracle服务器cpu 100,【Oracle服务器cpu100%调查日记】Oracle bug(cursor: mutex S)
weixin_42128270的博客
04-03 532
最近一周服务器再一次发现了cpu100%的问题，看来上次对sql语句的优化没有彻底根治这个问题。话不多说，继续开始调查这个问题。首先查看了当天发生问题的一小时内的AWR报告：SQL ordered by CPU TimeResources reported for PL/SQL code includes the resources used by all SQL statements calle...
jmeter名词解释之时间（Elapsed Time/ Latency Time/Connection Time）
01-05 2万+
jmeter报告结果中会出现三个时间 1. Elapsed time    经过的时间(= Sample time = Load time = Response time )        这个时间是我们测试常用的时间，也是整个请求的消耗时间，从发送到接收完成全程消耗的时间 2. Latency time  延迟时间      不常用，表示请求发送到刚开始接收响应时，这
11gRAC由于drm特性引起的sql语句性能波动分析
还不算晕的专栏
01-26 1306
近期比较有空闲时间，记录下之前的一个DRM导致insert插入语句执行时间波动的案例。 某用户反映OLTP系统某业务正常只需要ms级可以完成，偶尔出现需要5-10s左右才能完成，导致后续关联业务执行错误的情况，近期此问题出现频率每天有几次，需要介入调查出现此问题的原因。通过与客户沟通了解到此业务只是简单的插入数据的SQL语句，此业务模块有日志记录完成所需时间，客户通过后续业务模块报错信息...
MYSQL——索引设计原则
庄小焱
12-28 1935
之前优化器选择使用索引 b，是因为它认为使用索引 b 可以避免排序（b 本身是索引，已经是有序的了，如果选择索引 b 的话，不需要再做排序，只需要遍历），所以即使扫描行数多，也判定为代价更小。但是，对于这个查询语句来说，如果你定义的 index2 不是 email(6) 而是 email(7），也就是说取 email 字段的前 7 个字节来构建索引的话，即满足前缀’zhangss’的记录只有一个，也能够直接查到 ID2，只扫描一行就结束了。其中，Q1 的结果还是符合预期的，rows 的值是 104620；
【SQL性能分析工具】：使用EXPLAIN理解查询执行计划
![卸载前警告提示-mysql查询最近一条记录的sql语句(优化篇)]...随后，详细探讨了EXPLAIN输出参数的详细解释和优化点，如id列、select_type以及type列与索引效率的关系。在第三章中，我们通过实践应用，展示了如何使
【数据库索引优化】：提升MFC选课系统查询效率
首先介绍了索引的工作原理、类型和创建管理，然后深入分析了MFC选课系统数据库的结构和查询效率现状，识别出性能瓶颈。接着，文章详细论述了索引优化前的准备工作和实施步骤，并通过案例分析展示了优化过程和效果。...
oracle gets/exec 单位,Oracle AWR报告分析之–SQL ordered by
weixin_39692271的博客
04-09 1506
1、SQL ordered by Elapsed TimeResources reported for PL/SQL code includes the resources used by all SQL statements called by the code.% Total DB Time is the Elapsed Time of the SQL statement divided in...
oracle hint push_pred,乱用Oracle Hint造成性能问题案例一
weixin_29169899的博客
04-04 4860
某系统上午9点到11点的AWR报告中TOP SQL，其中消耗时间最长的花了9770秒，该SQL_ID为36cbabzyq13gy这条SQL语句与SQL_ID为0frcad5600xdu,g1a0qu2b42j83所对应的SQL语句除了文本值不一样外，其它部分是相同的，这里没有使用绑定变量SQL ordered by Elapsed TimeResources reported for PL/SQL...
oracle_慢SQL的优化过程（awr报表）
anzhen0429的博客
11-27 3285
 怎么样判断系统运行慢，或者SQL运行慢原因以及解决办法？ 第一步：判断哪个应用进程消耗资源 查看CPU的信息： [root@alimysql03 ~]# top     #top查看cup的资源和内存利用率，磁盘io等问题：主要看%CPU，MEM，WA等参数，按1可以查看多 个CPU的信息。 top - 09:55:39 up 41 days, 1 min,  2 users, 
AWR报表解读-02
congza2755的博客
03-17 474
五、首要的SQL语句 SQL ordered by Gets Resources reported for PL/SQL code includes the resources used by all SQL state...
缩减oracle日志,[20180829]减少日志生成量.txt
weixin_39866966的博客
04-10 128
[20180829]减少日志生成量.txt--//最近一段时间优化一下生产数据库,主要是问题比我预计要严重,实际上exadata实在太快了,把许多问题都给掩盖了.--//实际上这个问题很早就存在,我实在不想提,基于国内许多应用都可能存在类似问题,还是写一下.SQL ordered by Executions%CPU - CPU Time as a percentage of Elapsed Tim...
Oracle AWR报告详细分析
羽之大公公的博客
01-13 4759
Oracle AWR报告详细分析 (文档 ID 1523048.1) AWR 是 Oracle 10g 版本 推出的新特性， 全称叫Automatic Workload Repository-自动负载信息库 AWR 是通过对比两次快照(snapshot)收集到的统计信息，来生成报表数据，生成的报表包括多个部分。WORKLOAD REPOSITORY report for ...
ORACLE 11g 通过ASH结合AWR实战解决cpu高负载的详细过程
csdn's blog
07-24 1万+
ASH结合AWR实战解决oracle高负载 线上oracle数据库负载比较高，所以需要优化，一般进去看负载高的进程，如果是oracle进程，那么就是oracle运行不健康出异常了，我们通常可以用ash来分析问题，如果ash还无法解决，我们就需要扩大分析范围，需要采用awr分析日志来进行分析。 1、ASH分析日志分析Events Top S...
[Oracle维护工程师手记]一次升级后运行变慢的分析
weixin_30376453的博客
04-29 248
客户报告，当他从 Oracle 11.1.0.7 ，迁移到云环境，并且升级到12.1.0.2。运行客户的应用程序测试，发现比以前更慢了。从AWR report 的"Top 10 Foreground Events by Total Wait Time"和"Wait Classes by Total Wait Time"等信息，可以看到 CPU 值升高了。初步思考，怀疑由于环境的不同，导致性能不同。...
[20180829]减少日志生成量.txt
08-30 113
[20180829]减少日志生成量.txt --//最近一段时间优化一下生产数据库,主要是问题比我预计要严重,实际上exadata实在太快了,把许多问题都给掩盖了. --//实际上这个问题很早就存在,我实在不...
explain 分析sql的时候，用唯一索引查出来的一条数据，width 为1361，正常么？耗时达到220ms，应该怎么优化？
最新发布
07-31
<think>首先，用户的问题是关于数据库查询优化的。具体内容是：用户在使用唯一索引从数据库中检索一条数据时，字段width的值为1361是否正常，并且查询耗时220ms。用户希望进行性能优化。 关键点： - 使用唯一索引查询一条数据。 - width字段值为1361。 - 查询耗时220ms。 - 优化查询性能。 我需要理解用户的问题： - "width字段为1361是否正常"：这可能指的是查询结果中的某个字段的值是1361，但这似乎无关紧要，因为优化焦点是性能，而不是数据值。用户可能在问这个值是否合理，但结合上下文，应该是问查询耗时是否正常。 - 查询耗时220ms：对于一个唯一索引查询来说，这似乎很慢。通常，索引查询应该很快，毫秒级。 参考引用： - 引用[1]：讨论索引扫描和OR操作。 - 引用[2]：展示局部索引的使用和查询计划。 - 引用[3]：提到数据库查询优化，避免多次查询。 - 引用[4]：关于LangChain开发ChatBI助手，不直接相关。 用户的问题核心是优化查询性能。查询耗时220ms，对于一个唯一索引查询，这可能不正常，表明存在性能瓶颈。 可能的原因： 1. 索引问题：唯一索引可能没有被正确使用，或者索引碎片化。 2. 数据大小：如果表很大，但索引查询应该高效。 3. 服务器负载：高负载可能导致延迟。 4. 查询本身：可能有其他开销，如网络延迟或数据库配置。 5. 字段类型：width字段可能是一个大字段（如BLOB或TEXT），影响查询性能。 在引用[2]中，有局部索引的例子，但用户是使用唯一索引查询一条数据，所以索引应该被使用。 优化建议： 1. 检查查询计划：使用EXPLAIN ANALYZE查看查询执行计划。 2. 索引优化：确保索引有效，无碎片。 3. 减少数据大小：如果width字段很大，考虑只检索必要字段。 4. 数据库配置：调整缓存、内存设置。 5. 硬件或网络：检查服务器资源。 回答结构： - 使用中文。 - 清晰结构：先确认问题，分析可能原因，提供优化建议。 - 添加引用标识：自然地引用提供的参考。 - 生成相关问题：在最后添加相关问题。 回答大纲： 1. 介绍：确认用户查询耗时220ms可能不正常。 2. 分析可能原因： - 索引使用情况。 - 字段大小影响。 - 其他因素。 3. 优化建议： - 检查执行计划。 - 优化索引。 - 只选择必要字段。 - 数据库调优。 4. 结论：强调测试和监控。 5. 相关问题。 关于width字段值1361：用户问"width字段的值为1361是否正常"。这可能是一个误解；1361可能是字段值，但优化焦点是性能。我应该澄清：值本身正常与否取决于业务逻辑，但耗时是问题。 在上下文中，width可能是一个字段名，值1361是示例。但用户说"字段width的值为1361"，意思是查询结果中width字段的值是1361。但这对性能优化无关紧要。所以，我应聚焦在性能上。 最终回答： - 开头：对于使用唯一索引查询一条数据耗时220ms，这通常不正常，可能表示性能问题。 - 原因分析：参考引用，如索引扫描效率。 - 优化步骤：建议具体措施。 - 相关问题：生成相关优化问题。 生成相关问题： 基于主题：数据库查询优化、索引使用、性能调优。 例如： 1. 如何检查数据库查询的执行计划？ 2. 索引碎片如何影响查询性能？ 3. 对于大字段查询，如何优化响应时间？ 4. 数据库配置参数如何调整以提高查询速度？ 5. 唯一索引和普通索引在查询性能上有什么区别？</think>### 数据库查询优化分析：唯一索引查询性能问题 针对您的查询场景——使用唯一索引检索一条数据，其中`width`字段值为1361，查询耗时220ms——我将逐步分析并给出优化建议。首先，**查询耗时220ms在大多数数据库系统中通常不正常**，尤其对于唯一索引查询（通常应在毫秒级）。这暗示存在潜在性能瓶颈。以下分析基于数据库优化原理和参考引用内容。 #### 1. **问题分析：为什么耗时220ms可能不正常？** - **唯一索引查询的预期性能**：唯一索引设计用于快速定位单条记录（时间复杂度接近$O(1)$）。在标准OLTP系统中，此类查询应在1-10ms内完成（除非表极大或硬件限制）。 - **可能原因**： - **索引未有效利用**：查询可能未直接命中索引，或者索引碎片化导致扫描效率下降。参考引用[1]提到，数据库可能将查询分解为多个索引扫描（如OR条件），但您的查询是单值查询，应直接使用索引。如果索引未被正确使用，执行计划可能退化为全表扫描。 - **字段大小影响**：如果`width`字段是大型数据类型（如TEXT、BLOB或VARCHAR(1361)），检索整个字段会消耗更多I/O资源。引用[2]中局部索引示例显示，字段大小直接影响扫描成本（如`Bitmap Heap Scan` vs `Seq Scan`）。 - **数据库负载或配置问题**：高并发、内存不足或缓存设置不当可能增加延迟。 - **网络或应用层开销**：220ms可能包括网络传输或ORM框架处理时间（如引用[3]所示，多次查询会造成性能浪费）。 - **`width`字段值1361是否正常**：字段值本身取决于业务逻辑（如宽度单位是像素或字符），1361在数据层面无异常。但字段**定义**（如数据类型和大小）影响性能：如果`width`定义为大对象字段，检索它可能拖慢查询。 #### 2. **优化建议：降低查询耗时** 优化核心是**减少I/O和计算开销**。以下是具体步骤（优先非侵入性方法）： - **步骤1: 检查查询执行计划** 使用`EXPLAIN ANALYZE`分析查询，确认索引是否被使用。例如： ```sql EXPLAIN ANALYZE SELECT * FROM your_table WHERE unique_field = 'value'; ``` - **期望输出**：应显示`Index Scan`（索引扫描）而非`Seq Scan`（全表扫描）。如果输出包含`Recheck Cond`或`Filter`（如引用[2]），表明索引未完全覆盖查询，需优化索引或查询。 - **行动**：如果执行计划显示全表扫描，重建索引（`REINDEX INDEX your_index`）或检查索引定义。 - **步骤2: 优化索引和查询结构** - **只选择必要字段**：避免`SELECT *`，尤其当表包含大字段时。改为`SELECT id, other_field`（不包括`width`），如果业务允许。这减少数据传输量。 - **添加覆盖索引**：如果`width`常被查询，创建包含该字段的复合索引（但唯一索引已存在，需权衡）。例如： ```sql CREATE UNIQUE INDEX idx_unique_covering ON your_table (unique_field) INCLUDE (width); ``` - 这允许索引直接返回`width`值，避免访问表数据（堆扫描）。 - **处理大字段**：如果`width`是大型数据，考虑： - 存储为压缩格式（如数据库内置压缩）。 - 移出到大字段分离表（仅存储引用）。 - **步骤3: 数据库级调优** - **内存与缓存**：增大数据库缓冲池（如PostgreSQL的`shared_buffers`或MySQL的`innodb_buffer_pool_size`），使索引和数据常驻内存。 - **连接池与并发**：使用连接池（如PgBouncer）避免连接开销。监控负载（如`pg_stat_activity`），确保无资源争用。 - **统计信息更新**：运行`ANALYZE your_table`更新统计信息，帮助优化器选择更好计划。 - **步骤4: 应用层优化** - **减少ORM开销**：如引用[3]所示，避免多次查询（如Django的`Entry.objects.all()`）。确保ORM生成高效SQL（使用`only()`或`defer()`限制字段）。 - **批处理或缓存**：对高频查询结果缓存（如Redis），减少数据库访问。 - **预期优化效果**：通过上述步骤，耗时通常可降至1-50ms。测试环境示例： - 优化前：220ms（全字段检索）。 - 优化后：5ms（只选索引字段 + 覆盖索引）。 #### 3. **监控与测试** - 使用工具（如`pg_stat_statements`或慢查询日志）持续监控。 - 测试建议：在低负载时运行查询，排除网络影响（如直接在数据库服务器执行）。 - 如果问题持续，检查硬件（磁盘I/O速度）或考虑分库分表。 #### 总结 `width`字段值1361本身正常，但查询耗时220ms表明性能瓶颈，可能源于索引无效、字段大小或配置问题。优先通过执行计划分析和查询重构优化。引用[1]和[2]强调索引扫描效率的重要性[^1][^2]，而引用[3]提醒应用层避免冗余操作[^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值