先来了解两个概念：“统计信息”、“执行计划”。

什么是统计信息呢？讲这个前得先了解什么是执行计划。

一、什么是执行计划？

讲执行计划前得先了解下数据库的引擎架构（后续补张引擎架构图在这里）。

数据库核心主要由三大引擎组成：SQL引擎、执行引擎和存储引擎。关系数据库到现在这种引擎架构30年来基本保持不变。

SQL引擎、执行引擎和存储引擎是DBMS系统的内部强大机制。有了这一套强大的机制，我们只需简单的下发SQL命令，等着三个引擎帮我们把要找的数据找给我们。而趁他们忙碌的时候，我们可以翻个报纸、喝口咖啡啥的。有时候，翻完报纸、喝完咖啡，发现数据还没有递交给我们，我们就很着急，就想知道，这帮家伙到底在私底下（后台）捣鼓啥呢，这么久还没给个信儿~~。于是我们就想了解下，他们到底是怎么工作的，有没有办法帮帮他们。

那这三个引擎到底是怎么工做的呢？总括起来说呢就是：

SQL引擎对你下发的SQL命令进行词法&语法解析、查询重写及查询优化后，由优化器生成一个执行计划后，交给执行引擎进行查询执行，执行引擎按照执行计划找存储引擎取数据。觉得存储引擎特像现在大型医院的药房，要并行处理很多事务，因此需要有一套强大的事务管理机制。

执行计划决定了你到存储引擎中调度数据是走什么样的套路（采用什么样的算子）。套路有多种，借用一篇博客中的说法就是：一条SQL的执行，可能有多种方法，条条大路通罗马，是用串行扫描Seq Scan还是Index Scan还是Bitmap Heap Scan，对于SQL中的union是用Nested Loop还是使用Hash Join，这都需要优化器决策。

而优化器决策的依据又是什么呢？代价！是的，选择代价小的执行计划。那么代价又是在怎么计算的呢？根据统计信息。统计信息提供的越准确，那么代价估算的越准确，那么选择的执行计划就越合理。

二、什么是统计信息？

统计信息到底是什么呢（我们离打破砂锅所要问到的底越来越近了）？

可以参考简书上的这篇帖子，写的很清楚了。

https://www.jianshu.com/p/d7b2034cc68d 

为什么要记录统计信息

优化器决策执行计划所依据的代价主要是计算IO代价。即读页面的开销，可以认为读取的页面数和行数是正相关的（需重点关注和领会的）。统计信息主要记录的就是表的行数以及不同列不同值的分布关系。

统计信息都记录什么

统计信息除了记录行数和页数外，当查询语句包括where这类条件语句时，例如WHERE unique1 < 1000，还需要记录数据的分布率，来预计小于1000到底存在多少行的数据，如果大部分数据都小于1000，那么顺序扫描的开销要低于索引扫描。

统计信息记录在哪里

PG系数据库中用于进行查询计划选择的统计信息记录在系统表内

1. pg_statistic 记录值的分布率

2. pg_class 记录行数和页面数

三、为什么需要做Analyze？

终于到达本帖所要回答的问题了。

统计信息记录了数据库对象的详细信息，优化器要决策的时候就直接从pg_statistic和pg_class提取统计信息就行了，为什么还需要手动通过Analyze来收集呢？

原因是这样的：

表中的记录在有变化的时候，表的统计信息就肯定会发生变化。按理如果所使用的DBMS系统如果能自动的收集和刷新上面的系统表中的统计信息，就不需要手动了。

实际上各数据库基本都支持统计信息的自动收集，比如上面提到的简书中的博客中就提到了PG的autovacuum就可以定期更新统计信息。但是autovacuum定期更新统计信息和清理过期元组都是要做全表扫描的，这样会耗费很大的I/O资源。如何长期定期去执行，势必会影响到正常业务查询的效率。因此通常，大家都会把系统中的autovacuum关闭。且数据的变化都是人为计划和安排的，只要在数据变化完成后，安排手动执行Analyze进行收集即可。