amazon-redshift - 当表 svv_table_info 中的 stats_off 列的值为 99% 时，这意味着什么？

对于表 stats_off 中的表 svv_table_info 列之一，其值为 99% 。这是什么意思？以及如何修复它？

我尝试获取该表的 anaylse 和 vaccum 的历史记录。分析和真空对该列值有任何作用吗？

最佳答案

VACUUM 命令将检查表并根据需要重新排列磁盘上的数据，这将影响 unsorted 和 empty 列。越接近0越好。
ANALYZE 命令将检查表并适本地重新计算统计信息，这将影响 stats_off 列。越接近0越好。

有可能即使在运行 ANALYZE 命令之后，它也没有太大变化。要最大化可能的最低值，您应该首先运行 VACUUM 命令。表的统计信息包括已删除的旧记录 - 在 Redshift 中，它们只是被跳过，但它们仍然会对整体查询性能产生影响。因此，通过首先在表上运行 VACUUM，您将为 ANALYZE 命令提供可用数据的最佳 View 。

仅仅因为表的统计数据陈旧并不意味着它有必要导致问题。您需要查找来自查询计划生成器的警报，以查看它是否在提示表上的统计信息。当您执行表连接时，您通常会看到这些提示。此查询将查看是否有任何投诉在最后一天注册，并提供一个命令列表，以便在需要时运行...

SELECT DISTINCT 'ANALYZE ' + feedback_tbl.schema_name + '.' + feedback_tbl.table_name + ';' AS command
FROM ((SELECT
         TRIM(n.nspname) schema_name,
         c.relname       table_name
       FROM (SELECT
               TRIM(SPLIT_PART(SPLIT_PART(a.plannode, ':', 2), ' ', 2)) AS Table_Name,
               COUNT(a.query),
               DENSE_RANK()
               OVER (
                 ORDER BY COUNT(a.query) DESC)                          AS qry_rnk
             FROM stl_explain a,
               stl_query b
             WHERE a.query = b.query
                   AND CAST(b.starttime AS DATE) >= dateadd(DAY, -1, CURRENT_DATE)
                   AND a.userid > 1
                   AND a.plannode LIKE '%%missing statistics%%'
                   AND a.plannode NOT LIKE '%%_bkp_%%'
             GROUP BY Table_Name) miss_tbl
         LEFT JOIN pg_class c ON c.relname = TRIM(miss_tbl.table_name)
         LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
       WHERE miss_tbl.qry_rnk <= 25)
      -- Get the top N rank tables based on the stl_alert_event_log alerts
      UNION
      SELECT
        schema_name,
        table_name
      FROM (SELECT
              TRIM(n.nspname)              schema_name,
              c.relname                    table_name,
              DENSE_RANK()
              OVER (
                ORDER BY COUNT(*) DESC) AS qry_rnk,
              COUNT(*)
            FROM stl_alert_event_log AS l
              JOIN (SELECT
                      query,
                      tbl,
                      perm_table_name
                    FROM stl_scan
                    WHERE perm_table_name <> 'Internal Worktable'
                    GROUP BY query,
                      tbl,
                      perm_table_name) AS s ON s.query = l.query
              JOIN pg_class c ON c.oid = s.tbl
              JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
            WHERE l.userid > 1
                  AND l.event_time >= dateadd(DAY, -1, CURRENT_DATE)
                  AND l.Solution LIKE '%%ANALYZE command%%'
            GROUP BY TRIM(n.nspname),
              c.relname) anlyz_tbl
      WHERE anlyz_tbl.qry_rnk < 25) feedback_tbl
  JOIN svv_table_info info_tbl
    ON info_tbl.schema = feedback_tbl.schema_name
       AND info_tbl.table = feedback_tbl.table_name
WHERE info_tbl.stats_off :: DECIMAL(32, 4) > 10 :: DECIMAL(32, 4)
      AND TRIM(info_tbl.schema) = 'public'
ORDER BY info_tbl.size ASC;

当我们在做的时候，这个查询将检查 VACUUM 命令的表......

SELECT 'VACUUM FULL ' + "schema" + '.' + "table" + ';' AS command
FROM svv_table_info
WHERE (unsorted > 5 OR empty > 5)
      AND size < 716800;

这些查询包含 Amazon 定义的建议阈值，可在其用于管理 Redshift 集群 located here 的公共(public) Python 脚本中使用。

关于amazon-redshift - 当表 svv_table_info 中的 stats_off 列的值为 99% 时，这意味着什么？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/42382906/