扩大varchar长度不需重建索引，因仅修改pg_attribute.atttypmod元数据，不重写表，索引键值二进制表示不变；例外是函数索引失效等非ddl直接导致的情况。
ALTER COLUMN TYPE 扩大 VARCHAR 长度后，索引通常不用重建
扩大 VARCHAR 长度（如从 VARCHAR(50) 改为 VARCHAR(500)）不改变数据物理存储格式，底层仍是变长字符串，和 TEXT 共享同一存储机制。PostgreSQL 只更新 pg_attribute.atttypmod 元数据，不重写表，也不影响已有索引结构。
此时索引键值的二进制表示没变，B-tree 页内比较逻辑依然有效，查询、插入、更新都能照常走索引 —— 不需要 手动 REINDEX。
- 验证方式：执行
ALTER TABLE t ALTER COLUMN c TYPE VARCHAR(500);后，查pg_stat_all_indexes，idx_scan和idx_tup_read不会归零或异常跳变 - 例外情况：字段上有 函数索引（如
CREATE INDEX ON t ((lower(c)));），扩大长度本身不触发重建，但若后续该索引因其他原因失效（如统计信息过期、WAL corruption），才需干预 - 注意：如果字段是复合索引的前导列，且你之后又做了缩小长度或类型转换，那才是重建索引的信号点
缩小 VARCHAR 长度或改类型时，索引大概率要重建
缩小长度（如 VARCHAR(200) → VARCHAR(20)）会触发全表扫描校验存量数据是否超长，这个过程 PostgreSQL 必须重写表 —— 意味着所有 B-tree 索引也同步重建。这不是“要不要”的问题，而是 DDL 自动完成的副产品。
同理，改成非兼容类型（如 VARCHAR → INT 或 VARCHAR → DATE）也会重写表，索引自然跟着刷新。
- 操作后可快速确认：执行
SELECT pg_size_pretty(pg_total_relation_size('t'));对比前后大小，明显增长说明发生了重写，索引已更新 - 不要手动
REINDEX INDEX补救 —— 这会额外加锁，且没必要；重写表过程中索引已重建完毕 - 若缩小操作卡住，大概率是表上有长事务未提交，用
SELECT * FROM pg_stat_activity WHERE state = 'active' AND backend_start 排查
CHAR 类型改长度必须重写表，连带索引一起重建
CHAR(n) 是定长类型，修改长度会强制填充或截断每行数据，无法靠元数据调整实现。哪怕只是 CHAR(10) → CHAR(11)，PostgreSQL 也得逐行 rewrite，索引必然重建。
这点和 VARCHAR 有本质区别 —— 实际使用中应避免对大表用 CHAR 存业务字段，尤其当长度可能调整时。
- 性能差异显著：测试显示
CHAR(10) → CHAR(100)耗时约 35 秒（千万级表），而同场景VARCHAR(10) → VARCHAR(100)仅 1.8ms - 如果已误用
CHAR，稳妥做法是先转成VARCHAR（需重写），再按需扩长（毫秒级） - 别碰
pg_attribute手动改atttypmod来绕过 ——CHAR的长度语义绑定在存储层，硬改会导致数据读取错乱
真正需要主动 REINDEX 的场景，和字段长度无关
索引是否需要重建，取决于它自身的健康状态，而不是字段长度变更。长度操作只是“偶然触发者”，不是“根本原因”。
以下情况才该考虑 REINDEX：
- 索引膨胀严重：
bloat_ratio > 1.4，可用pgstattuple扩展查pgstatindex() - 索引扫描次数长期为 0（
idx_scan = 0），且确认无查询用到它 —— 此时更该删索引，而非重建 - 创建并发索引失败，留下 invalid 状态索引（
pg_index.indisvalid = false） - 升级 PostgreSQL 大版本后，某些索引格式不兼容（罕见，但文档会明确列出）
最后提醒一句：别在高峰期对大表跑 REINDEX TABLE，它会对整张表加 ACCESS EXCLUSIVE 锁 —— 这比扩个 VARCHAR 长度的锁严苛得多。
