这绝对是生产环境里必须慎之又慎的操作——百万行级别的表建索引确实会引发一系列问题，风险完全不能忽视，我见过不少团队踩过这个坑，轻则业务卡顿，重则直接导致服务中断。下面拆解一下核心风险和应对思路：

核心风险点 #

1. 表锁与读写阻塞 #

不同数据库引擎的锁行为差异极大：

• 像MySQL的MyISAM引擎，创建索引时会直接锁全表，期间所有读、写请求都会被阻塞，直到索引创建完成——百万行的表可能要跑几分钟甚至几十分钟，这对实时业务来说完全是灾难。
• 即使是支持在线DDL的InnoDB（MySQL 5.6及以上版本），也不是完全无锁：创建二级索引时，虽然允许正常读写，但在操作的起始和结束阶段会有短暂的元数据锁，而且如果表的写负载很高，后续的变更日志合并也可能间接导致延迟。
• PostgreSQL的话，默认建索引也会锁表阻止写操作，只有用特定参数才能避免锁表，但代价是索引创建速度变慢。

2. 性能雪崩 #

创建索引需要全表扫描，百万行的数据量会瞬间拉高数据库的CPU、磁盘IO使用率：

• 磁盘IO持续飙高会挤占其他业务查询的资源，导致正常请求变慢、超时；
• 如果数据库本身资源预留不足（比如CPU核心少、磁盘是机械盘），甚至可能导致数据库进程卡顿，触发监控告警。

3. 其他隐性影响 #

• 磁盘空间耗尽：索引本身会占用大量磁盘空间（通常是原表数据的30%-50%），如果事先没预留足够空间，建到一半磁盘满了，轻则索引创建失败，重则导致数据库服务异常。
• 主从复制延迟：在主从架构中，建索引的DDL语句会同步到从库，从库执行同样的全表扫描操作，会导致从库延迟飙升，进而影响依赖从库的读业务。
• 回滚风险：如果索引创建过程中意外中断（比如数据库重启、磁盘故障），部分数据库（比如MySQL）会触发回滚操作，这个回滚过程同样会占用大量资源，甚至比创建索引本身更耗时。

不同数据库的优化方案 #

针对主流数据库，有对应的参数可以降低风险：

• MySQL（InnoDB）：使用ALTER TABLE your_table ADD INDEX idx_col (col_name) ALGORITHM=INPLACE, LOCK=NONE;，指定ALGORITHM=INPLACE避免拷贝全表，LOCK=NONE尽可能减少锁表时间。
• PostgreSQL：使用CREATE INDEX CONCURRENTLY idx_col ON your_table (col_name);，这个参数会在不锁表的情况下创建索引，但注意不能在事务块中执行，且创建时间会更长。
• SQL Server：使用CREATE INDEX idx_col ON your_table (col_name) WITH (ONLINE = ON);，在线创建索引，减少对业务的阻塞。

生产环境操作建议 #

• 选低峰期执行：比如凌晨业务量最低的时间段，即使出问题影响范围也最小。
• 先在测试环境模拟：用和生产环境一致的数据量、配置测试建索引的耗时、资源占用情况，提前预判风险。
• 全程监控：操作时实时监控数据库的CPU、IO、锁状态、主从延迟，一旦出现异常立即终止操作。
• 预留磁盘空间：提前检查磁盘使用率，确保至少有原表数据量50%以上的空闲空间。
• 拆分大表（可选）：如果表已经大到百万行以上，后续可以考虑分区表，后续建索引可以针对单个分区操作，降低影响范围。

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