sql - 涉及大表的性能调优 Oracle SQL-6ren

sql - 涉及大表的性能调优 Oracle SQL

转载作者：行者123 更新时间：2023-12-02 00:52:34

我有一个 Oracle SQL 查询，它涉及与 4 个大表和几个小表的连接。
大表是 TBL_1、TBL_2、TBL_3、TBL4，每个表都有大约 800 万条记录。其余的是少于 10K 记录的小表。

问题:即使没有数据返回，查询也需要3分钟以上。

表和索引统计信息是最新的。这些表上没有陈旧的统计数据。

我试过使用提示，但没有用。

请看下面我的观察:

询问:

    SELECT a.*, ROWNUM AS rnm
      FROM (  SELECT c.idntfr,
             pr.program_name AS "Program",
             e.case_number,
             (SELECT DECODE (s.status_name,
                     'EA', 'A',
                     'ED', 'D',
                     'EU', 'U',
                     s.status_name)
                FROM TBL_5 ms, status s
               WHERE     ms.status_type_cid = 7
                 AND mbr_sid = c.mbr_sid
                 AND ms.status_type_cid = s.status_type_cid
                 AND s.status_cid = ms.status_cid
                 AND ms.oprtnl_flag = 'A'
                 AND SYSDATE BETWEEN ms.from_date AND ms.TO_DATE),
             DECODE (
                LENGTH (TRIM (e.social_security_nmbr)),
                NULL, 'Not Available',
                (   SUBSTR (e.social_security_nmbr, 1, 3)
                 || '-'
                 || SUBSTR (e.social_security_nmbr, 4, 2)
                 || '-'
                 || SUBSTR (e.social_security_nmbr, 6, 4)))
                AS "SSN",
             e.last_name || ',' || e.first_name || ' ' || e.middle_name,
             TO_CHAR (e.injury_date, 'MM/dd/yyyy'),
             DECODE (e.gender_lkpcd,
                 'M', 'Male',
                 'F', 'Female',
                 'U', 'Unknown'),
             e.mbr_sid,
             pr.program_cid,
             e.last_name,
             e.social_security_nmbr,
             e.first_name AS
            FROM TBL_1 c,
             program pr,
             TBL_2 e,
             TBL_3 mai,
             TBL_4 uaxou
           WHERE     c.mbr_sid = e.mbr_sid
             AND c.mbr_sid = mai.mbr_sid
             AND c.oprtnl_flag = 'A'
             AND c.idntfr_type_cid = 423
             AND TRUNC (SYSDATE) BETWEEN c.from_date AND c.TO_DATE
             AND TRUNC (SYSDATE) BETWEEN e.from_date AND e.TO_DATE
             AND e.oprtnl_flag = 'A'
             AND e.status_cid = 2
             AND mai.oprtnl_flag = 'A'
             AND mai.status_cid = 2
             AND TRUNC (SYSDATE) BETWEEN mai.from_date AND mai.TO_DATE
             AND e.program_code = pr.program_code
             AND pr.oprtnl_flag = 'A'
             AND uaxou.user_acct_sid = 1
             AND uaxou.oprtnl_flag = 'A'
             AND SYSDATE BETWEEN uaxou.from_date AND uaxou.TO_DATE
             AND uaxou.org_unit_sid = mai.org_unit_sid
        ORDER BY "Program" ASC) a
     WHERE ROWNUM < 102;

没有以下条件的数据

    AND uaxou.user_acct_sid = 1

预期结果:如果没有返回数据，响应时间应低于 4 秒。

解释计划:

Plan hash value: 2272581586

---------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                             |   101 | 22220 |  1361   (1)| 00:00:01 |
|   1 |  NESTED LOOPS                         |                             |     1 |    58 |     7   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                        |                             |     1 |    58 |     7   (0)| 00:00:01 |
|*  3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TBL_5                       |     1 |    31 |     6   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | XIF1TBL_5                   |     8 |       |     3   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN                  | XPKSTATUS                   |     1 |       |     0   (0)| 00:00:01 |
|   6 |   TABLE ACCESS BY INDEX ROWID         | STATUS                      |     1 |    27 |     1   (0)| 00:00:01 |
|*  7 |  COUNT STOPKEY                        |                             |       |       |            |          |
|   8 |   VIEW                                |                             |   169 | 37180 |  1361   (1)| 00:00:01 |
|   9 |    NESTED LOOPS                       |                             |   169 | 36166 |   767   (0)| 00:00:01 |
|  10 |     NESTED LOOPS                      |                             | 11904 | 36166 |   767   (0)| 00:00:01 |
|  11 |      NESTED LOOPS                     |                             |    62 | 11284 |   333   (0)| 00:00:01 |
|  12 |       NESTED LOOPS                    |                             |    45 |  6660 |   108   (0)| 00:00:01 |
|  13 |        NESTED LOOPS                   |                             |    33 |  3564 |     9   (0)| 00:00:01 |
|* 14 |         TABLE ACCESS BY INDEX ROWID   | PROGRAM                     |     5 |    70 |     2   (0)| 00:00:01 |
|  15 |          INDEX FULL SCAN              | XAK1OWCP_PROGRAM            |     2 |       |     1   (0)| 00:00:01 |
|* 16 |         TABLE ACCESS FULL             | TBL_2                       |    20 |  1880 |     4   (0)| 00:00:01 |
|* 17 |        TABLE ACCESS BY INDEX ROWID    | TBL_1                       |     1 |    40 |     3   (0)| 00:00:01 |
|* 18 |         INDEX RANGE SCAN              | TUNE_WS_19NOV10_X2          |     1 |       |     2   (0)| 00:00:01 |
|* 19 |       TABLE ACCESS BY INDEX ROWID     | TBL_3                       |     1 |    34 |     5   (0)| 00:00:01 |
|* 20 |        INDEX RANGE SCAN               | XIE2_TBL_3                  |     3 |       |     2   (0)| 00:00:01 |
|* 21 |      INDEX RANGE SCAN                 | XIF3TBL_4                   |   192 |       |     1   (0)| 00:00:01 |
|* 22 |     TABLE ACCESS BY INDEX ROWID       | TBL_4                       |     3 |    96 |     7   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("MS"."STATUS_TYPE_CID"=7 AND "MS"."OPRTNL_FLAG"='A' AND "MS"."TO_DATE">=SYSDATE@! AND 
          "MS"."FROM_DATE"<=SYSDATE@!)
   4 - access("MBR_SID"=:B1)
   5 - access("S"."STATUS_TYPE_CID"=7 AND "S"."STATUS_CID"="MS"."STATUS_CID")
   7 - filter(ROWNUM<102)
  14 - filter("PR"."OPRTNL_FLAG"='A')
  16 - filter("E"."PROGRAM_CODE"="PR"."PROGRAM_CODE" AND "E"."OPRTNL_FLAG"='A' AND "E"."STATUS_CID"=2 AND 
          "E"."FROM_DATE"<=TRUNC(SYSDATE@!) AND TRUNC(INTERNAL_FUNCTION("FROM_DATE"))<=TRUNC(TRUNC(SYSDATE@!)) AND 
          "E"."TO_DATE">=TRUNC(SYSDATE@!) AND TRUNC(INTERNAL_FUNCTION("TO_DATE"))>=TRUNC(TRUNC(SYSDATE@!)))
  17 - filter("C"."FROM_DATE"<=TRUNC(SYSDATE@!) AND "C"."TO_DATE">=TRUNC(SYSDATE@!))
  18 - access("C"."MBR_SID"="E"."MBR_SID" AND "C"."IDNTFR_TYPE_CID"=423 AND "C"."OPRTNL_FLAG"='A')
  19 - filter("MAI"."OPRTNL_FLAG"='A' AND "MAI"."STATUS_CID"=2 AND "MAI"."FROM_DATE"<=TRUNC(SYSDATE@!) AND 
          "MAI"."TO_DATE">=TRUNC(SYSDATE@!))
  20 - access("C"."MBR_SID"="MAI"."MBR_SID")
  21 - access("UAXOU"."USER_ACCT_SID"=1)
  22 - filter("UAXOU"."ORG_UNIT_SID"="MAI"."ORG_UNIT_SID" AND "UAXOU"."OPRTNL_FLAG"='A' AND 
          "UAXOU"."FROM_DATE"<=SYSDATE@! AND "UAXOU"."TO_DATE">=SYSDATE@!)

这是来自 v$parameter 的查询输出

    NAME                                |   VALUE
    compatible                          |   12.2.0
    optimizer_adaptive_plans            |   TRUE
    optimizer_adaptive_reporting_only   |   FALSE
    optimizer_features_enable           |   12.2.0.1

这是添加 GATHER_PLAN_STATISTICS 后显示实际基数值的解释计划:

    Plan hash value: 2272581586

    -------------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                             | Name                        | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
    -------------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                      |                             |      1 |        |      0 |00:00:00.01 |       0 |
    |   1 |  NESTED LOOPS                         |                             |      0 |      1 |      0 |00:00:00.01 |       0 |
    |   2 |   NESTED LOOPS                        |                             |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TBL_5                       |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  4 |     INDEX RANGE SCAN                  | XIF1TBL_5                   |      0 |      8 |      0 |00:00:00.01 |       0 |
    |*  5 |    INDEX UNIQUE SCAN                  | XPKSTATUS                   |      0 |      1 |      0 |00:00:00.01 |       0 |
    |   6 |   TABLE ACCESS BY INDEX ROWID         | STATUS                      |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  7 |  COUNT STOPKEY                        |                             |      1 |        |      0 |00:00:00.01 |       0 |
    |   8 |   VIEW                                |                             |      1 |    169 |      0 |00:00:00.01 |       0 |
    |   9 |    NESTED LOOPS                       |                             |      1 |    169 |      0 |00:00:00.01 |       0 |
    |  10 |     NESTED LOOPS                      |                             |      1 |  11904 |      0 |00:00:00.01 |       0 |
    |  11 |      NESTED LOOPS                     |                             |      1 |     62 |      0 |00:00:00.01 |       0 |
    |  12 |       NESTED LOOPS                    |                             |      1 |     45 |      0 |00:00:00.01 |       0 |
    |  13 |        NESTED LOOPS                   |                             |      1 |     33 |      0 |00:00:00.01 |       0 |
    |* 14 |         TABLE ACCESS BY INDEX ROWID   | PROGRAM                     |      1 |      5 |      1 |00:00:00.01 |       2 |
    |  15 |          INDEX FULL SCAN              | XAK1OWCP_PROGRAM            |      1 |      2 |      2 |00:00:00.01 |       1 |
    |* 16 |         TABLE ACCESS FULL             | TBL_2                       |      1 |     20 |      0 |00:00:00.01 |       0 |
    |* 17 |        TABLE ACCESS BY INDEX ROWID    | TBL_1                   |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 18 |         INDEX RANGE SCAN              | TUNE_WS_19NOV10_X2          |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 19 |       TABLE ACCESS BY INDEX ROWID     | TBL_3                       |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 20 |        INDEX RANGE SCAN               | XIE2_TBL_3                  |      0 |      3 |      0 |00:00:00.01 |       0 |
    |* 21 |      INDEX RANGE SCAN                 | XIF3TBL_4           |      0 |    192 |      0 |00:00:00.01 |       0 |
    |* 22 |     TABLE ACCESS BY INDEX ROWID       | TBL_4                   |      0 |      3 |      0 |00:00:00.01 |       0 |
    -------------------------------------------------------------------------------------------------------------------------------

    Predicate Information (identified by operation id):
    ---------------------------------------------------

       3 - filter(("MS"."STATUS_TYPE_CID"=7 AND "MS"."OPRTNL_FLAG"='A' AND "MS"."TO_DATE">=SYSDATE@! AND 
              "MS"."FROM_DATE"<=SYSDATE@!))
       4 - access("MBR_SID"=:B1)
       5 - access("S"."STATUS_TYPE_CID"=7 AND "S"."STATUS_CID"="MS"."STATUS_CID")
       7 - filter(ROWNUM<102)
      14 - filter("PR"."OPRTNL_FLAG"='A')
      16 - filter(("E"."PROGRAM_CODE"="PR"."PROGRAM_CODE" AND "E"."OPRTNL_FLAG"='A' AND "E"."STATUS_CID"=2 AND 
              "E"."FROM_DATE"<=TRUNC(SYSDATE@!) AND "E"."TO_DATE">=TRUNC(SYSDATE@!)))
      17 - filter(("C"."FROM_DATE"<=TRUNC(SYSDATE@!) AND "C"."TO_DATE">=TRUNC(SYSDATE@!)))
      18 - access("C"."MBR_SID"="E"."MBR_SID" AND "C"."IDNTFR_TYPE_CID"=423 AND "C"."OPRTNL_FLAG"='A')
      19 - filter(("MAI"."OPRTNL_FLAG"='A' AND "MAI"."STATUS_CID"=2 AND "MAI"."FROM_DATE"<=TRUNC(SYSDATE@!) AND 
              "MAI"."TO_DATE">=TRUNC(SYSDATE@!)))
      20 - access("C"."MBR_SID"="MAI"."MBR_SID")
      21 - access("UAXOU"."USER_ACCT_SID"=1)
      22 - filter(("UAXOU"."ORG_UNIT_SID"="MAI"."ORG_UNIT_SID" AND "UAXOU"."OPRTNL_FLAG"='A' AND 
              "UAXOU"."FROM_DATE"<=SYSDATE@! AND "UAXOU"."TO_DATE">=SYSDATE@!))

我尝试了各种提示 USE_HASH(c e) 和各种其他组合，都没有奏效。

一个有趣的观察，如果我评论条件:

    --AND uaxou.user_acct_sid = 1

结果在 7 秒内出现。 (显然，在这种情况下返回数据)。
那么，当没有数据返回时，是什么导致查询花费这么长时间？ (即此条件未注释 AND uaxou.user_acct_sid = 1 )

我让慢查询完成，花了 10 分 46 秒。没有数据返回

这是解释计划。我不知道为什么 A-Time 与实际执行时间不匹配。

    Plan hash value: 2272581586

    -------------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                             | Name                        | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
    -------------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                      |                             |      1 |        |      0 |00:00:00.01 |       0 |
    |   1 |  NESTED LOOPS                         |                             |      0 |      1 |      0 |00:00:00.01 |       0 |
    |   2 |   NESTED LOOPS                        |                             |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  3 |    TABLE ACCESS BY INDEX ROWID BATCHED| TBL_5                       |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  4 |     INDEX RANGE SCAN                  | XIF1TBL_5                   |      0 |      8 |      0 |00:00:00.01 |       0 |
    |*  5 |    INDEX UNIQUE SCAN                  | XPKSTATUS                   |      0 |      1 |      0 |00:00:00.01 |       0 |
    |   6 |   TABLE ACCESS BY INDEX ROWID         | STATUS                      |      0 |      1 |      0 |00:00:00.01 |       0 |
    |*  7 |  COUNT STOPKEY                        |                             |      1 |        |      0 |00:00:00.01 |       0 |
    |   8 |   VIEW                                |                             |      1 |    169 |      0 |00:00:00.01 |       0 |
    |   9 |    NESTED LOOPS                       |                             |      1 |    169 |      0 |00:00:00.01 |       0 |
    |  10 |     NESTED LOOPS                      |                             |      1 |  11904 |      0 |00:00:00.01 |       0 |
    |  11 |      NESTED LOOPS                     |                             |      1 |     62 |      0 |00:00:00.01 |       0 |
    |  12 |       NESTED LOOPS                    |                             |      1 |     45 |      0 |00:00:00.01 |       0 |
    |  13 |        NESTED LOOPS                   |                             |      1 |     33 |      0 |00:00:00.01 |       0 |
    |* 14 |         TABLE ACCESS BY INDEX ROWID   | PROGRAM                     |      1 |      5 |      1 |00:00:00.01 |       2 |
    |  15 |          INDEX FULL SCAN              | XAK1OWCP_PROGRAM            |      1 |      2 |      2 |00:00:00.01 |       1 |
    |* 16 |         TABLE ACCESS FULL             | TBL_2                       |      1 |     20 |      0 |00:00:00.01 |       0 |
    |* 17 |        TABLE ACCESS BY INDEX ROWID    | TBL_1                       |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 18 |         INDEX RANGE SCAN              | TUNE_WS_19NOV10_X2          |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 19 |       TABLE ACCESS BY INDEX ROWID     | TBL_3                       |      0 |      1 |      0 |00:00:00.01 |       0 |
    |* 20 |        INDEX RANGE SCAN               | XIE2_TBL_3                  |      0 |      3 |      0 |00:00:00.01 |       0 |
    |* 21 |      INDEX RANGE SCAN                 | XIF3TBL_4                   |      0 |    192 |      0 |00:00:00.01 |       0 |
    |* 22 |     TABLE ACCESS BY INDEX ROWID       | TBL_4                       |      0 |      3 |      0 |00:00:00.01 |       0 |
    -------------------------------------------------------------------------------------------------------------------------------

    Predicate Information (identified by operation id):
    ---------------------------------------------------

       3 - filter(("MS"."STATUS_TYPE_CID"=7 AND "MS"."OPRTNL_FLAG"='A' AND "MS"."TO_DATE">=SYSDATE@! AND 
              "MS"."FROM_DATE"<=SYSDATE@!))
       4 - access("MBR_SID"=:B1)
       5 - access("S"."STATUS_TYPE_CID"=7 AND "S"."STATUS_CID"="MS"."STATUS_CID")
       7 - filter(ROWNUM<102)
      14 - filter("PR"."OPRTNL_FLAG"='A')
      16 - filter(("E"."PROGRAM_CODE"="PR"."PROGRAM_CODE" AND "E"."OPRTNL_FLAG"='A' AND "E"."STATUS_CID"=2 AND 
              "E"."FROM_DATE"<=TRUNC(SYSDATE@!) AND "E"."TO_DATE">=TRUNC(SYSDATE@!)))
      17 - filter(("C"."FROM_DATE"<=TRUNC(SYSDATE@!) AND "C"."TO_DATE">=TRUNC(SYSDATE@!)))
      18 - access("C"."MBR_SID"="E"."MBR_SID" AND "C"."IDNTFR_TYPE_CID"=423 AND "C"."OPRTNL_FLAG"='A')
      19 - filter(("MAI"."OPRTNL_FLAG"='A' AND "MAI"."STATUS_CID"=2 AND "MAI"."FROM_DATE"<=TRUNC(SYSDATE@!) AND 
              "MAI"."TO_DATE">=TRUNC(SYSDATE@!)))
      20 - access("C"."MBR_SID"="MAI"."MBR_SID")
      21 - access("UAXOU"."USER_ACCT_SID"=1)
      22 - filter(("UAXOU"."ORG_UNIT_SID"="MAI"."ORG_UNIT_SID" AND "UAXOU"."OPRTNL_FLAG"='A' AND 
              "UAXOU"."FROM_DATE"<=SYSDATE@! AND "UAXOU"."TO_DATE">=SYSDATE@!))

最佳答案

自适应计划可以改进执行计划。

您将问题标记为 12c，但由于某种原因，执行计划似乎没有使用自适应计划。自适应计划让 Oracle 在运行时更改操作，例如在 NESTED LOOPS 和 HASH JOINS 之间切换。

NESTED LOOPS 适用于一小部分行，而 HASH JOINS 适用于大部分行。由于 ROWS 估计值都很小，但查询运行了三分钟，我猜优化器明显低估了表达式和连接的基数，并且使用了太多 NESTED LOOP。

如果启用了自适应计划，执行计划应该在底部有这个:

Note
-----
   - this is an adaptive plan

由于缺少该注释，我猜想您的数据库中存在一个参数问题，阻止了自适应计划。运行以下查询并查看其中一项功能是否已关闭，或者这些功能是否设置为低于 12 的版本:

select name, value
from v$parameter
where name in (
    'optimizer_adaptive_features', --12.1 only
    'optimizer_adaptive_plans', --12.2+
    'optimizer_adaptive_reporting_only',
    'optimizer_features_enable',
    'compatible'
    )
order by 1;

编辑 1

我不确定为什么适应性计划对您不起作用。如果没有人能弄清楚，那么我们需要调查执行计划的实际值，以准确找出哪些操作很慢。

至少有两种方法可以获得实际数字。如果您可以更改并重新运行有问题的查询，则可以使用提示 GATHER_PLAN_STATISTICS .

--Run slow query and wait for it to finish:
select /*+ gather_plan_statistics */ * from dual;

--Find the SQL_ID of the query using some distinctive text:
select *
from v$sql
where lower(sql_fulltext) like '%gather_plan_statistics%';

--Generate execution plan with actual values.
select *
from table(dbms_xplan.display_cursor(sql_id => 'SQL_ID from above', format=>'allstats last'));

如果您无法更改查询，则可以使用 SQL Monitor 报告来查找实际值。 (此功能需要企业版和调整包许可证。)

--Generate SQL Monitoring Report:
select dbms_sqltune.report_sql_monitor(sql_id => 'SQL_ID from above') from dual;

编辑 2

您是否 100% 确定您找到了正确的 SQL_ID？您可能需要仔细检查 GV$SQL .如果 SQL 是从应用程序或 PL/SQL 块提交的，有时情况会发生变化。很少有真正的 SQL 语句会过时 GV$SQL , 如果有人运行 alter system flush shared_pool; , 或者收集了统计信息，或者如果您等待的时间过长。

如果这确实是正确的执行计划，则不会在查询上花费时间。通常，这意味着网络发送结果或应用程序处理结果必须花费时间。但由于没有返回行，网络或应用程序问题听起来不太可能。

如果时间花在数据库上，而不是花在该查询上，那么我猜它要么是解析问题，要么是递归查询问题。解析问题可以通过跟踪找到，但这些问题是由极其不寻常的问题或查询引起的，在这里可能不是这种情况。

也许 Oracle 用于收集元数据的查询之一花费的时间太长。对于许多查询，Oracle 需要运行其他查询来检查权限、动态采样等。您可能需要调整其他查询之一，以下语句可以帮助完成这个痛苦的过程:

--Clear existing run times (be careful running this on production).
--(This won't flush queries that are actively running.)
alter system flush shared_pool;

--Run your slow SQL statement here.
--...

--Now look for anything "weird" that has taken up most of the time. 
select elapsed_time/1000000 seconds, gv$sql.*
from gv$sql
order by seconds desc;

关于sql - 涉及大表的性能调优 Oracle SQL，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56411418/

文章推荐： c - 为什么 Berkeley 套接字需要字节交换？

文章推荐： python - 只迭代 python 字典的两个键

文章推荐： system-verilog - UVM- 在顶部 block 和宏中运行 test()

javascript - Ember.js，性能，性能 :
性能:数据存储写入与请求日志写入
我们希望通过我们的应用收集使用情况统计信息。因此，我们希望在服务器端的某个地方跟踪用户操作。就性能而言，哪个选项更合适: 在 App Engine 请求日志中跟踪用户操作。即为每个用户操作写入一个日
LINQ 性能
在针对对象集合的 LINQ 查询的幕后究竟发生了什么？它只是语法糖还是发生了其他事情使其更有效的查询？最佳答案您是指查询表达式，还是查询在幕后的作用？查询表达式首先扩展为“普通”C#。例如: v
WPF 性能
我正在构建一个简单的照片库应用程序，它在列表框中显示图像。 xaml 是:
java缓存系统和静态HashMap存储-性能
对于基于 Web 的企业应用程序，使用“静态 Hashmap 存储对象” 和 apache java 缓存系统有何优缺点？哪一个最有利于性能并减少堆内存问题例如: Map store=Applica
jquery存储变量类(性能)
我想知道在性能方面存储类变量的最佳方式是什么。我的意思是，由于 Children() 函数，存储一个 div id 比查找所有其他类名更好。还是把类名写在变量里比较好？例如这样: var $inne
Cassandra 性能
我已经阅读了所有这些关于 cassandra 有多快的文章，例如单行读取可能需要大约 5 毫秒。到目前为止，我不太关心我的网站速度，但是随着网站变得越来越大，一些页面开始需要相当多的查询，例如一个页
MySQL 性能
最近，我在缓存到内存缓存之前的查询一直需要很长时间才能处理!在这个例子中，它花费了 10 秒。在这种情况下，我要做的就是获得 10 个最近的点击。我感觉它加载了所有 125,592 行然后只返回 1
基本操作的C#性能
我找了几篇文章(包括SA中的一些问题)，试图找到基本操作的成本。但是，我尝试制作自己的小程序，以便自己进行测试。在尝试测试加法和减法时，我遇到了一些问题，我用简单的代码向您展示了这一点
Java远程调试——性能
这个问题在这里已经有了答案: Will Java app slow down by presence of -Xdebug or only when stepping through code? (
Javascript with() 性能
我记得很久以前读过 with() 对 JavaScript 有一些严重的性能影响，因为它可能对范围堆栈进行非确定性更改。我很难找到最近对此的讨论。这仍然是真的吗？最佳答案与其说 with 对性能有
MySQL 性能
我们有一个数据仓库，其中包含非规范化表，行数从 50 万行到 6 多万行不等。我正在开发一个报告解决方案，因此出于性能原因我们正在使用数据库分页。我们的报告有搜索条件，并且我们已经创建了必要的索引，但
mysql - 性能
我有一条有效的 SQL 语句，但需要很长时间才能处理我有一个 a_log 表和一个 people 表。我需要在 people 表中找到给定人员的每个 ID 的最后一个事件和关联的用户。 SELECT
JavaScript 性能
很难说出这里问的是什么。这个问题是含糊的、模糊的、不完整的、过于宽泛的或修辞性的，无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开它，visit the help center 。已关
CSS 性能
通常当我建立一个站点时，我将所有的 CSS 放在一个文件中，并且一次性定义与一组元素相关的所有属性。像这样: #myElement { color: #fff; background-
CSS 性能
两者之间是否存在任何性能差异: p { margin:0px; padding:0px; } 并省略最后的分号: p { margin:0px; padding:0px } 提前致谢!
PHP高精数学-性能
我的应用程序 (PHP) 需要执行大量高精度数学运算(甚至可能出现一共100个数字) 通过这个论坛的最后几篇帖子，我发现我必须使用任何高精度库，如 BC Math 或 GMP，因为 float 类型不
Javamail 性能
我一直在使用 javamail 从 IMAP 服务器(目前是 GMail)检索邮件。 Javamail 非常快速地从服务器检索特定文件夹中的消息列表(仅 id)，但是当我实际获取消息(仅包含甚至不包含
ruby 性能
我非常渴望开发我的第一个 Ruby 应用程序，因为我的公司终于在内部批准了它的使用。在我读到的关于 Ruby v1.8 之前的所有内容中，从来没有任何关于性能的正面评价，但我没有发现关于 1.9 版
redis结构、性能
我是 Redis 的新手，我有一个包含数百万个成员(member) ID、电子邮件和用户名的数据集，并且正在考虑将它们存储在例如列表结构中。我认为 list 和 sorted set 可能最适合我的情

行者123

个人简介

我是一名优秀的程序员,十分优秀！

作者热门文章

滴滴打车优惠券免费领取

全站热门文章

首页

博学

6Ren·AI

商城

sql - 涉及大表的性能调优 Oracle SQL