标签: explain

对于糟糕的列/表名称感到抱歉，但由于这是一个工作项目，我想确保可以询问。我只是希望至少了解为什么我没有看到我的功能索引被使用，所以我觉得在生产环境中添加这些索引更好。

该查询使用我创建的视图，该视图具有许多不同的列，其中包含执行以下操作的 where 子句：

  ....
  AND e.sysid = NVL(wi.ALPHAid, -999)
  AND NVL(wi.ALPHAid,   -999)       <> -999
  AND NVL(wi.BRAVOid,   -999)        = -999
  AND NVL(wi.CHARLIEid, -999)        = -999
  ...

我的理解是，如果您通过函数传递列，则 Oracle 不能使用索引，而您需要创建基于函数的索引。因此，在创建索引之前，我在解释计划中获得了以下成本：

计划哈希值：1233409744

-------------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                           | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                 |                                |     1 |   223 |    56   (6)| 00:00:01 |
|   1 |  SORT ORDER BY                   |                                |     1 |   223 |    56   (6)| 00:00:01 |
|   2 …

有时，我的数据库进程的使用者会要求估计何时完成给定的任务。虽然我觉得我知道如何在大多数数据库引擎中阅读 EXPLAIN，但我很难将其翻译为“15 分钟后再次询问我”。有谁知道用于任何特定数据库的良好“经验法则”？

我意识到这不会是一个硬性规定，但在某些情况下，即使能够给出一个大概的数字也可能很有用。

TL;DR：当“EXPLAIN (BUFFERS)”显示“索引扫描”时，它不会显示需要从索引中读取的页数。它只是省略了那个数字，还是它实际上不读取页面（我误解了索引的工作原理）？

我们有一个大的只读表，看起来像这样：

database=> \d my_table
    Table "my_table"
        Column         |       Type       | Modifiers
-----------------------+------------------+-----------
 id                    | integer          |
 date                  | date             |
 country_id            | smallint         |
 ...other columns...
Indexes:
    "my_table_id_date_idx" btree (id, date)

并且对该表的典型查询具有这样的 EXPLAIN...

database=> EXPLAIN (BUFFERS, ANALYZE) SELECT id, date, country_id FROM my_table WHERE id = 50 AND date BETWEEN '2015-04-01' AND '2015-04-07';
                                                                                    QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on my_table  (cost=448.40..70400.85 rows=18810 width=10) (actual time=9.011..1447.817 rows=10224 loops=1)
   Recheck Cond: ((id = 50) AND (date >= '2015-04-01'::date) AND …

我有以下表格和内容

create table t(i int primary key, j int, k char(6000))
create  index ix on t(j)

insert into t values(1,1,1)
insert into t values(2,1,1)
insert into t values(3,1,1) 
insert into t values(4,1,1)
insert into t values(5,1,1)
insert into t values(6,1,1)
insert into t values(7,1,1)
insert into t values(8,2,2) 
insert into t values(9,2,2)

select * from t where j = 1
select * from t where j = 2

我真的很困惑为什么第一个 SELECT 只使用Clustered Index Scan (Clustered)而第二个使用Index Seek (NonClustered)和 …

我正在一些大表中运行查询，尽管它运行良好，即使是大量数据也很困难，但我想了解它的哪一部分对执行有影响。不幸的是，我不太擅长解释计划，所以我寻求帮助。

以下是有关这些表的一些数据：

• history_state_table 7.424.65行（其中只有13.412被后留下的t1.alarm_type = 'AT1'）
• costumer_price_history 448.284.169行
• cycle_table 215行

这将是查询（不要介意逻辑，仅供参考）：

SELECT t1.id_alarm, t2.load_id, t2.reference_date
  FROM history_state_table t1,
       (SELECT   op_code, contract_num,
                 COUNT (DISTINCT id_ponto) AS num_pontos,
                 COUNT
                    (DISTINCT CASE
                        WHEN vlr > 0
                           THEN id_ponto
                        ELSE NULL
                     END
                    ) AS bigger_than_zero,
                 MAX (load_id) AS load_id,
                 MAX (reference_date) AS reference_date
            FROM costumer_price_history
           WHERE load_id IN
                            (42232, 42234, 42236, 42238, 42240, 42242, 42244) /* arbitrary IDs depending on execution*/
             AND sistema = 'F1'          /* Hardcoded …

我有两张桌子levels和users_favorites

+--------------------+--------------+------+-----+ -------+-------+
| 领域 | 类型 | 空 | 钥匙 | 默认 | 额外 |
+--------------------+--------------+------+-----+ -------+-------+
| 身份证 | 整数(9) | 否 | PRI | 空 | |
| 用户 ID | 整数(10) | 否 | 多| 空 | |
| 级别名称 | varchar(20) | 否 | | 空 | |
| 用户名 | varchar(45) | 否 | | 空 | |
| 评级 | 十进制(3,2) | 否 | | 2.50 | |
| 投票 …

我在慢查询日志中有这个条目：

# User@Host: user[host] @  [ip]
# Thread_id: 1514428  Schema: db  Last_errno: 0  Killed: 0
# Query_time: 2.795454  Lock_time: 0.000116  Rows_sent: 15  Rows_examined: 65207  Rows_affected: 0  Rows_read: 65207
# Bytsent: 26618
SET timestamp=1407511874;

select off.*,translated_title,translated_description 
from ephpb2b_products off  USE INDEX(id_viewed)  
  INNER JOIN ephpb2b_members mem 
    ON  off.uid = mem.id 
  Left Join ephpb2b_product_language_new pol 
    ON  off.id = pol.offer_id                                         
    and pol.language='en'
where off.approved=1 
order by off.viewed  
LIMIT 15; 

当我解释这个查询时，它绝对没问题。

mysql> explain select off.*,translated_title,translated_description from ephpb2b_products off  USE INDEX(id_viewed)  INNER JOIN ephpb2b_members mem ON …

据我了解，当您向 Postgres 发送查询时，例如：

SELECT id FROM table1 WHERE name = $1;

Postgres 将创建一个查询计划。该计划将在同一个会话中为同一个查询缓存。但是如果你创建一个函数：

CREATE OR REPLACE FUNCTION get_table1 (parname text) RETURNS bigint
LANGUAGE plpgsql AS 
$$BEGIN
  RETURN (SELECT id FROM table1 where name = parname);
END$$;

查询计划将为所有未来的会话缓存。

我想通过检查查询分析器的调用频率来验证这个理论。有没有办法检查 Postgres 解析查询的次数？

如果可能，我想监视每秒 #parses 和最小/最大/平均解析持续时间等内容。

我想将一系列查询 EXPLAIN 计划的结果存档到一个表中以供以后分析。

我创建了一个包含 EXPLAIN 结果中所有字​​段的表，但我不知道如何通过执行 EXPLAIN 命令来填充它。

我想出了如何在 MySQL Workbench 中导出包含 INSERT 命令的 .sql 文件，但我必须手动编辑它才能使其工作。EXPLAIN 信息是否存储在某处以便我可以编写查询来自动执行？我在 information_schema 或 performance_schema 中都找不到它。

在 Postgres 中解释计划有宽度，其中（每 文档）是：

此计划节点输出的行的估计平均宽度（以字节为单位）。

我的问题：宽度何时为 0？因为在文档的示例中，有时如下所示：

EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;

                                  QUERY PLAN
------------------------------------------------------------------------------
 Bitmap Heap Scan on tenk1  (cost=5.07..229.20 rows=101 width=244)
   Recheck Cond: (unique1 < 100)
   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=101 width=0)
         Index Cond: (unique1 < 100)