最稳妥的索引重建方式是 DROP INDEX + CREATE INDEX，它能彻底释放旧索引空间并按当前数据重新组织结构；TRUNCATE/DELETE 不清索引，反而易致碎片；MySQL 主键需用 ALTER TABLE 修改，PostgreSQL 推荐 REINDEX CONCURRENTLY 配合 ANALYZE。
直接 DROP INDEX 再 CREATE 是最稳妥的做法
想清空索引并重建，本质不是“清空”，而是“替换”。drop index + create index 组合能彻底释放旧索引占用的空间，并按当前数据分布重新组织 b-tree 或其他结构。很多用户误用 truncate table 或 delete from，但这两者只删数据，不碰索引——索引页还在磁盘上，甚至可能因大量删除产生碎片，反而更占空间。
-
TRUNCATE TABLE会保留索引结构（只是重置统计信息），索引文件大小基本不变 -
DELETE FROM后不VACUUM（PostgreSQL）或不OPTIMIZE TABLE（MySQL MyISAM）的话，索引页标记为“可复用”，但物理空间不返还 - 如果表有主键或唯一约束，
DROP INDEX可能失败（如 MySQL 中主键索引不能单独删），得先改表结构或用ALTER TABLE ... DROP PRIMARY KEY
MySQL 中重建索引必须用 ALTER TABLE ... DROP/ADD KEY
MySQL 不支持对主键或唯一索引直接 DROP INDEX（除非是普通二级索引）。常见错误是执行 DROP INDEX idx_name ON tbl 后报错 ERROR 1025 (HY000): Error on rename...，其实是被主键/外键/约束拦住了。
- 对普通索引：可用
DROP INDEX idx_name ON tbl+CREATE INDEX idx_name ON tbl (col) - 对主键：必须用
ALTER TABLE tbl DROP PRIMARY KEY, ADD PRIMARY KEY (new_col)（注意：InnoDB 要求主键存在，不能只删不加） - 重建时加
ALGORITHM=INPLACE（MySQL 5.6+）可避免全表锁，但仅限部分操作；加LOCK=NONE需确认存储引擎和版本是否支持
PostgreSQL 中用 REINDEX 最省事，但别在高峰期跑
REINDEX INDEX、REINDEX TABLE 或 REINDEX DATABASE 是 PostgreSQL 原生方案，它原地重建索引、释放碎片空间，且自动更新统计信息。但它会拿 ACCESS EXCLUSIVE 锁——意味着写操作完全阻塞，读也可能被卡住（取决于查询是否命中索引）。
- 单个索引重建：
REINDEX INDEX CONCURRENTLY idx_name（加CONCURRENTLY可避免长锁，但要求 PostgreSQL ≥ 12，且不能在事务块中执行） - 重建整个表的索引：
REINDEX TABLE tbl，比逐个重建快，但锁粒度更大 - 如果表刚经历大批量
INSERT/UPDATE/DELETE，先运行VACUUM ANALYZE tbl再REINDEX，效果更稳——否则新索引可能基于过期的统计信息生成
重建后务必检查索引统计信息是否更新
索引重建了，但优化器如果还用旧的统计信息，查询计划可能没变，性能提升就白做了。不同数据库刷新方式差异大，容易漏掉这步。
- PostgreSQL：
ANALYZE tbl（REINDEX不自动触发ANALYZE） - MySQL InnoDB：
ANALYZE TABLE tbl（尤其在CREATE INDEX后，因为 InnoDB 不自动收集新索引的统计） - SQL Server：
UPDATE STATISTICS tbl WITH FULLSCAN（默认采样可能不准，大表建议全扫） - 重建后查
pg_stat_all_indexes（PG）或SHOW INDEX FROM tbl（MySQL）确认indexdef或Cardinality是否已刷新
真正耗时的从来不是重建动作本身，而是锁等待、统计延迟、以及误判“索引已重建=查询变快”。特别是主键索引重建，稍不注意就会卡住上游写入，得提前看业务低峰时段再动手。
