REINDEX — 重建索引
REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURRENTLY ] name
REINDEX使用索引的表里存储的数据重建一个索引，
并且替换该索引的旧拷贝。有一些场景需要使用REINDEX：
一个索引已经损坏，并且不再包含合法数据。尽管理论上这不会发生，
实际上索引会因为软件缺陷或硬件失效损坏。
REINDEX提供了一种恢复方法。
一个索引变得“臃肿”，其中包含很多空的或者近乎为空的页面。
PostgreSQL中的 B-树索引在特定的非
常规访问模式下可能会发生这种情况。REINDEX
提供了一种方法来减少索引的空间消耗，即制造一个新版本的索引，其中没有
死亡页面。详见第 24.2 节。
修改了一个索引的存储参数（例如填充因子），并且希望确保这种修改完全 生效。
如果索引在用CONCURRENTLY选项创建失败，该索引保留为一个“invalid”。
这类索引是无用的，但是可以方便的用REINDEX来重建它们。注意，只有REINDEX INDEX可以在无效的索引上执行并发创建。
INDEX重新创建指定的索引。
TABLE重新创建指定表的所有索引。如果该表有一个二级 “TOAST”表，它也会被重索引。
SCHEMA
重建指定方案的所有索引。如果这个方案中的一个表有次级的“TOAST”表，它也会被重建索引。共享系统目录上的索引也会被处理。这种形式的REINDEX不能在事务块内执行。
DATABASE
重新创建当前数据库内的所有索引。共享的系统目录上的索引也会被
处理。这种形式的REINDEX不能在一个
事务块内执行。
SYSTEM
重新创建当前数据库中在系统目录上的所有索引。共享系统目录上的
索引也被包括在内。用户表上的索引则不会被处理。这种形式的
REINDEX不能在一个事务块内执行。
name
要被重索引的特定索引、表或者数据库的名字。索引和表名可以被
模式限定。当前，REINDEX DATABASE和
REINDEX SYSTEM只能重索引当前数据库，因此
它们的参数必须匹配当前数据库的名称。
CONCURRENTLY使用此选项时，PostgreSQL 将重建索引，而不在表上采取任何阻止并发插入、更新或删除的锁; 标准的索引重建将会锁定表上的写操作(而不是读操作)，直到它完成。 使用此选项—时，有几个事项需要注意；请参阅Rebuilding Indexes Concurrently。
对于临时表，REINDEX始终是非并发的，因为没有其他会话可以访问它们，并且非并发重新索引更便宜。
VERBOSE在每个索引被重建时打印进度报告。
如果怀疑一个用户表上的索引损坏，可以使用
REINDEX INDEX或者
REINDEX TABLE简单地重建该索引
或者表上的所有索引。
如果你需要从一个系统表上的索引损坏中恢复，就更困难一些。在
这种情况下，对系统来说重要的是没有使用过任何可疑的索引本身（
实际上，这种场景中，你可能会发现服务器进程会在启动时立刻崩溃，
这是因为对于损坏的索引的依赖）。要安全地恢复，服务器必须用
-P选项启动，这将阻止它使用索引来进行系统
目录查找。
这样做的一种方法是关闭服务器，并且启动一个单用户的
PostgreSQL服务器，在其命令行
中包括-P选项。然后，可以发出
REINDEX DATABASE、REINDEX SYSTEM、
REINDEX TABLE或者REINDEX INDEX，
具体使用哪个命令取决于你想要重构多少东西。如果有疑问，可以使用
REINDEX SYSTEM来选择重建数据库中的所有系统索引。
然后退出单用户服务器会话并且重启常规的服务器。更多关于如何与
单用户服务器接口交互的内容请见postgres参考页。
在另一种方法中，可以开始一个常规的服务器会话，在其命令行选项
中包括-P。这样做的方法与客户端有关，但是在
所有基于libpq的客户端中都可以在开始客户端
之前设置PGOPTIONS环境变量为-P。
注意虽然这种方法不要求用锁排斥其他客户端，在修复完成之前避免
其他用户连接到受损的数据库才是更加明智的。
REINDEX类似于删除索引并且重建索引，在其中
索引内容会被从头开始建立。不过，锁定方面的考虑却相当不同。
REINDEX会用锁排斥写，但不会排斥在索引的父表上的读。
它也会在被处理的索引上取得一个排他锁，该锁将会阻塞对该索引的使用尝试。
相反，DROP INDEX 会暂时在附表上取得一个排他锁，阻塞
写和读。后续的CREATE INDEX会排斥写但不排斥读，由于
该索引不存在，所以不会有读取它的尝试，这意味着不会有阻塞但是读操作可能
被强制成昂贵的顺序扫描。
重索引单独一个索引或者表要求用户是该索引或表的拥有者。对方案或数据库重建索引要求是该方案或者数据库的拥有者。注意因此非超级用户有时无法重建其他用户拥有的表上的索引。不过，作为一种特例，当一个非超级用户发出REINDEX DATABASE、REINDEX SCHEMA或者REINDEX SYSTEM时，共享目录上的索引将被跳过，除非该用户拥有该目录（通常不会是这样）。当然，超级用户总是可以重建所有的索引。
不支持重建分区表的索引或者分区索引。不过可以单独为每个分区重建索引。
重建索引可能会影响数据库的常规操作。通常PostgreSQL会锁定重建的表以防止写操作，并通过单次扫描表来执行整个索引构建。 其他事务仍可以读取表，但如果它们尝试在表中插入、更新或删除行，它们将被阻止，直到索引重建完成。 如果系统是实时生产数据库，这可能会产生严重影响。非常大的表可能需要几个小时才能编制索引，即使对于较小的表，索引重建也会锁定编写器，这些时间段对于生产系统来说是不可接受的。
PostgreSQL支持以最少的写入锁定来重建索引。此方法通过指定REINDEX的CONCURRENTLY选项来调用。
使用此选项时，PostgreSQL必须对需要重新生成的每个索引执行两次表扫描，并等待可能使用索引的所有现有事务的终止。
此方法需要比标准索引重建更大的工作量，并且需要相当长的时间才能完成，因为它需要等待可能修改索引的未完成的事务。
但是，由于它允许在重建索引时继续正常操作，此方法可用于在生产环境中重建索引。当然，重建索引所需的额外 CPU、内存和 I/O 负载可能会减慢其他操作的速度。
以下步骤发生在并发重建索引中。 每个步骤在单独的事务中运行。 如果要重建多个索引，则每个步骤在进入到下一步之前都要循环遍历所有索引。
新的临时索引定义将添加到目录pg_index中。 此定义将用于替换旧索引。
一个SHARE UPDATE EXCLUSIVE会话级别的锁将放在要重建的索引以及其关联的表上，以防止处理时的任何模式修改。
为每个新索引完成生成索引的首个操作。
生成索引后，其标志pg_index.indisready切换到“true”使其准备好插入，使其在执行生成的事务完成后对其他会话可见。
此步骤在每个索引的单独事务中完成。
然后执行第二个操作以添加在第一个操作运行时添加的元组。此步骤也在每个索引的单独事务中完成。
引用索引的所有约束都已更改以引用新的索引定义，并且索引名称也已经更改。
此时，pg_index.indisvalid会为新索引切换到“true”，以及为旧索引切换到“false”，并且缓存无效会导致引用旧索引的所有会话失效。
旧索引有pg_index.indisready切换到“false”以防止任何新的元组插入，在等待可能引用旧索引的查询之后完成。
旧索引被丢弃。索引和表的SHARE UPDATE EXCLUSIVE会话锁被释放。
如果在重建索引时出现问题，例如唯一索引中的唯一性冲突， REINDEX命令将失败，但会留下一个 “invalid”新索引，在已经存在的索引之外。
出于查询目的此索引将被忽略，因为它可能不完整;但是它仍将消耗更新开销。psql \d命令将此类索引报告为 INVALID:
postgres=# \d tab
Table "public.tab"
Column | Type | Modifiers
--------+---------+-----------
col | integer |
Indexes:
"idx" btree (col)
"idx_ccnew" btree (col) INVALID
在这种情况下，推荐的恢复方法是删除无效索引，然后尝试重新执行REINDEX CONCURRENTLY。
在处理期间创建的并发索引的名称以ccnew为后缀，如果它是一个我们未能删除的旧索引定义，后缀是ccold。
可以使用DROP INDEX删除无效索引，包括无效的toast 索引。
常规索引创建允许在同一表上的其他常规索引创建同时发生，但在一个表上一次只能发生一个并发索引创建。在这两种情况下，不允许同时对表上其他类型的模式进行修改。
另一个区别是，常规REINDEX TABLE或REINDEX INDEX命令可以在事务块中执行，但REINDEX CONCURRENTLY不能执行。
REINDEX SYSTEM 不支持 CONCURRENTLY 因为系统目录不能并发重新索引。
此外，排除约束的索引不能并发重新编制索引。 如果此命令中直接命名了这样的索引，则会引发错误。
如果并发重新编制具有排除约束索引的表或数据库，将跳过这些索引。 （它可以不使用CONCURRENTLY选项来重新编制这样的索引）。
重建单个索引：
REINDEX INDEX my_index;
重建表my_table上的所有索引：
REINDEX TABLE my_table;
重建一个特定数据库中的所有索引，且不假设系统索引已经可用：
$export PGOPTIONS="-P"$psql broken_db... broken_db=> REINDEX DATABASE broken_db; broken_db=> \q
重建表的索引，在重建索引过程中不阻止对相关关系进行读写操作：
REINDEX TABLE CONCURRENTLY my_broken_table;
在 SQL 标准中没有REINDEX命令。