首页>Database>source

假设我有一个带有列 customer_id的仅附加表 (随机生成的字符串)和 x ,并且查询总是在 customer_id上完成

说数据如下所示,好像当客户最初签约某商品时,我们得到了一批行,然后再没有该客户签约。

customer_id=XCVFY0001, x=...
customer_id=XCVFY0001, x=...
(continues for ~1 page with same customer_id)
customer_id=HUMBN0001, x=...
customer_id=HUMBN0001, x=...
(continues for ~1 page with same customer_id)
(and so on...)

所以当 customer_id 的字母顺序与物理行不相关,我们可以这样写:

  • there are few distinct customer IDs per page
  • there are few pages per ID
  • there are long "runs" of IDs, or, if you need one customer_id ,您很可能会在几个连续的页面上找到它
  • 就信息论而言,我想他们会说没有相关性,但是"互信息"很高。

如果未明确运行 CLUSTER,查询计划者可以在估算中使用此类信息吗? ? 我以为如果 correlation低 如 pg_stats中报道 ,则可能会认为行在整个页面上均匀分布,并且可能对各种计划感到悲观。

(在我的现实世界中,一个普通的非聚集索引无论如何都会使事情变得好又快,但是当我注意到数据中的模式时,我只是感到好奇。)

最新回答
  • 1月前
    1 #

    计划者是 没有意识到这种类型的聚类,因此无法基于它做出决策。

    在这种情况下,ANALyzE使用的两步采样方法可能会生成倾斜的样本,这可能会导致n_distinct的低估.如果不深入研究各个查询的细节,就很难预测其后果。

  • sql server:具有默认的完全备份模型和失控日志文件的经典傻瓜-如何控制它?
  • query performance:如何在MySQL上优化很多子查询