PostgreSQL未analyze表n_tup_ins与行数不匹配及未触发自动分析问题

• 查询对象不匹配
  你执行count(*)的表是variant，但查询pg_stat_user_tables时返回的表名是variant_analysis_dependent，存在明显不一致：
  1. 优先检查是否存在search_path配置问题，你统计行数的表和查询统计信息的表可能属于不同schema
  2. 检查表名是否存在大小写敏感问题，建表时如果使用双引号包裹大小写混合的表名，直接用小写表名查询会匹配到错误对象
• 统计计数器被重置
  如果近期执行过全局统计重置SELECT pg_stat_reset();或单表统计重置SELECT pg_stat_reset_single_table_counters('variant'::regclass);，n_tup_ins、n_live_tup等字段值为重置后的增量值，而非表创建以来的累计值，此时基于该值计算的触发阈值不具备参考性。
• 表级自动分析被禁用
  全局autovacuum开启不代表单表配置未被修改，可执行以下命令检查表级自定义参数：

SELECT reloptions FROM pg_class WHERE relname = 'variant';

如果返回结果中存在autovacuum_enabled=false、autovacuum_analyze_threshold=-1这类配置，会直接禁止该表触发自动分析。

• 长事务阻塞自动分析
  如果存在运行时间超过autovacuum_naptime的长事务，自动分析（及自动 vacuum）会为了避免破坏长事务的可见性，跳过对相关表的处理。可执行以下命令核查长事务：

SELECT pid, xact_start, query FROM pg_stat_activity WHERE state != 'idle' AND xact_start < now() - interval '1h';

• 自动分析任务排队
  如果实例中存在大量需要做vacuum/analyze的表，且autovacuum_max_workers配置值过小，会导致自动分析任务长时间排队，无法及时处理到该表。可通过pg_stat_activity查看是否有持续运行的autovacuum worker进程。
• 分区表/继承表特性限制
  如果variant是分区表的子分区，部分PostgreSQL版本中不会单独触发子分区的自动分析，需要父级分区表的变更量达到阈值后才会统一触发统计信息更新。
• 权限配置问题
  如果variant表的权限设置过于严格，导致autovacuum运行的默认用户（通常为postgres）没有该表的读权限，也会导致自动分析任务执行失败，且不会在last_autoanalyze字段留下记录。

内容的提问来源于stack exchange，提问作者franDayz