标签: explain

我的桌子:

CREATE TABLE test (
  id INT AUTO_INCREMENT,
  anotherID INT,
  PRIMARY KEY (id),
  INDEX testIndex (id, anotherID)
);
INSERT INTO test VALUES (1,1),(2,1),(3,1),(4,1);

我的查询:

EXPLAIN SELECT *
FROM test
WHERE id = 1
  AND anotherID = 1;

因为只使用了PRIMARY键.但是,testIndex不是.我的问题是......为什么？既然SELECT在id和anotherID中都引用了值,那么不应该使用testIndex吗？

SQL小提琴:

http://sqlfiddle.com/#!2/b833d9/1

Postgres 9.6；Centos 6.7; 24核

BigTable1包含1,500,000,000行；重量180GB。

max_worker_processes = 20
max_parallel_workers_per_gather = 12

1）跑步时

EXPLAIN
SELECT
    date_id, id1, id2, id3, id4, topdomain, ftype, SUM(imps), SUM(cls)
FROM BigTable1
WHERE
    date_id BETWEEN 2017021200 AND 2017022400             
    AND date_id BETWEEN 2017020000 AND 2017029999   
GROUP BY
date_id, id1, id2, id3, id4, topdomain, ftype;

完全没有使用“计划的工人：”。为什么？

2）在定义的会话中运行相同查询时

set max_parallel_workers_per_gather = 5;

出现“计划的工人数：5”。执行时间仅缩短了25％。

2.1）为什么仅在此设置之后出现“计划的工人：”？2.2）为什么在以max_parallel_workers_per_gather = 5运行时看不到更好的改进？

谢谢！。

我正在使用这个Kotlin函数.我知道我们有一个叫做mPasswordView!!.setOnEditorActionListener参数的函数TextView.OnEditorActionListener,但之后是什么呢？我们在参数里面有花括号吗？

mPasswordView!!.setOnEditorActionListener(TextView.OnEditorActionListener { textView, id, keyEvent ->
    if (id == R.id.login || id == EditorInfo.IME_NULL) {
        attemptLogin()
        return@OnEditorActionListener true
    }
    false
})

我有2张桌子,"transaksi"和"buku"."transaksi"有大约250k行,buku大约有170k行.两个表都有名为"k999a"的列,两个表都不使用索引.现在我检查这两个陈述.

声明1:

explain select k999a from transaksi where k999a not in (select k999a from buku);

声明1输出:

 Seq Scan on transaksi  (cost=0.00..721109017.46 rows=125426 width=9)
   Filter: (NOT (SubPlan 1))
   SubPlan 1
     ->  Materialize  (cost=0.00..5321.60 rows=171040 width=8)
           ->  Seq Scan on buku  (cost=0.00..3797.40 rows=171040 width=8)

声明2:

explain select k999a from transaksi where k999a in (select k999a from buku);

声明2输出:

Hash Semi Join  (cost=6604.40..22664.82 rows=250853 width=9)
   Hash Cond: (transaksi.k999a = buku.k999a)
   ->  Seq Scan on transaksi  (cost=0.00..6356.53 rows=250853 width=9)
   ->  Hash  (cost=3797.40..3797.40 rows=171040 width=8) …

我正在尝试优化查询。使用EXPLAIN告诉我它是Using temporary。考虑到表的大小（20m+ 条记录），这确实是低效的。查看 MySQL 文档内部临时表，我没有看到任何暗示在我的查询中需要临时表的内容。我还尝试将 ORDER BY 设置为与 GROUP BY 相同，但仍然说使用临时和查询需要永远运行。我正在使用 MySQL 5.7。

有没有办法避免为此查询使用临时表：

SELECT url,count(*) as sum 
FROM `digital_pageviews` as `dp` 
WHERE `publisher_uuid` = '8b83120e-3e19-4c34-8556-7b710bd7b812' 
GROUP BY url 
ORDER BY NULL;

这是我的表架构：

create table digital_pageviews
(
  id             int unsigned auto_increment
    primary key,
  visitor_uuid   char(36)            null,
  publisher_uuid char(36) default '' not null,
  property_uuid  char(36)            null,
  ip_address     char(15)            not null,
  referrer       text                null,
  url_delete     text                null,
  url            varchar(255)        null,
  url_tmp        varchar(255)        null,
  meta           text                null, …

我的产品桌很大.我需要以非常高的偏移量选择几种产品(例如下面的例子).关于索引和性能的Postgresql手册建议在ORDER BY +最终条件使用的列上创建索引.一切都是桃子,没有使用.但对于高偏移值,LIMIT非常昂贵.任何人都知道这可能是什么原因？

以下查询可以运行几分钟.

Indexes:
"product_slugs_pkey" PRIMARY KEY, btree (id)
"index_for_listing_by_default_active" btree (priority DESC, name, active)
"index_for_listing_by_name_active" btree (name, active)
"index_for_listing_by_price_active" btree (master_price, active)
"product_slugs_product_id" btree (product_id)

EXPLAIN SELECT * FROM "product_slugs" WHERE ("product_slugs"."active" = 1) ORDER BY product_slugs.name ASC LIMIT 10 OFFSET 14859;
                                                       QUERY PLAN                                                        
-------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=26571.55..26589.43 rows=10 width=1433)
   ->  Index Scan using index_for_listing_by_name_active on product_slugs  (cost=0.00..290770.61 rows=162601 width=1433)
         Index Cond: (active = 1)
(3 rows)

浏览器在生成jasper报告[PDF格式]时被绞死,该报告运行查询,其解释计划如下.

请帮忙分析查询,这个查询花了太多时间吗？我们还注意到在生成此报告时卡住了线程.

我有一个简单的SELECT * From tv Where Client = 'ABCD'查询,当我这样做时EXPLAIN EXTENDED,它给了我两个不同的结果.执行查询时,其中一个需要几毫秒,而另一个需要大约3秒.为什么它会给出两个不同的解释结果以及导致缓慢的原因？

慢查询:

快速查询:

这是explain.depesz.com上的示例计划:

Limit  (cost=65301.950..65301.950 rows=1 width=219) (actual time=886.074..886.074 rows=0 loops=1)
  ->  Sort  (cost=65258.840..65301.950 rows=17243 width=219) (actual time=879.683..885.211 rows=17589 loops=1)
          Sort Key: juliet.romeo
          Sort Method: external merge  Disk: 4664kB
        ->  Hash Join  (cost=30177.210..62214.980 rows=17243 width=219) (actual time=278.986..852.834 rows=17589 loops=1)
                Hash Cond: (whiskey_quebec.whiskey_five = juliet.quebec)
              ->  Bitmap Heap Scan on whiskey_quebec  (cost=326.060..21967.630 rows=17243 width=4) (actual time=7.494..65.956 rows=17589 loops=1)
                      Recheck Cond: (golf = 297)
                    ->  Bitmap Index Scan on kilo  (cost=0.000..321.750 rows=17243 width=0) (actual time=4.638..4.638 rows=17589 loops=1)
                            Index Cond: (golf = 297) …

我试图理解弹性文档中的Explain API评分： https://www.elastic.co/guide/en/elasticsearch/reference/current/search-explain.html

当我无法通过自己的简单索引仅使用几个文档来计算出结果时，我尝试在上述文档页面上重现计算。

在示例中，它显示的“值”为 1.3862944，其描述为：“idf，计算公式为 log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5))”。在“详细信息”下，它给出了以下字段值：docFreq：1.0，docCount：5.0

使用提供的 docFreq 和 docCount 值，我将其计算为： log(1 + (5.0 - 1.0 + 0.5) / (1.0 + 0.5)) = 0.602，这与示例中的 1.3862944 不同。

我无法获得任何匹配的值。

我读错了吗？

以下是整个帖子

GET /twitter/_doc/0/_explain   
{ 
  "query" : {
    "match" : { "message" : "elasticsearch" }
  }
}

这将产生以下结果：

{
   "_index": "twitter",
   "_type": "_doc",
   "_id": "0",
   "matched": true,
   "explanation": {
       "value": 1.6943599,
       "description": "weight(message:elasticsearch in 0) [PerFieldSimilarity], result of:",
       "details": [
       {
        "value": …