在日常开发中，数据库查询速度直接影响用户体验。为了加快查询，很多人习惯性地给字段加索引。但很少有人意识到，索引创建本身并不是零成本的操作，尤其是在内存使用上，可能带来不小的压力。
索引不是免费的午餐
当你执行一条 CREATE INDEX 语句时，数据库并不会悄悄完成。它需要将目标表的数据读入内存，进行排序、构建B+树或哈希结构，最后再写回磁盘。这个过程会临时占用大量内存。比如在MySQL的InnoDB引擎中，创建索引时会用到 sort_buffer_size 和 innodb_sort_buffer_size 等内存区域。如果表有几千万行，这些缓冲区可能迅速被撑满。
举个例子，你在运营一个电商后台，用户订单表已经积累了一亿条数据。某天产品经理说要按“收货省份”做快速筛选，你随手执行：
CREATE INDEX idx_province ON orders (province);结果发现数据库响应变慢，监控显示内存使用率瞬间飙到90%以上。这就是索引创建过程中，数据库为排序和结构构建分配了大量临时内存所致。
不同数据库的处理方式
PostgreSQL 在创建普通索引时默认使用排序算法，会申请临时内存空间。如果可用内存不足，它会退回到磁盘排序，虽然避免了OOM（内存溢出），但速度明显下降。
MongoDB 在后台创建索引时，默认会锁定整个集合。3.4版本之后支持后台创建，但依然会消耗大量内存来遍历文档并构建索引节点。如果你的集合文档结构复杂，嵌套字段多，内存占用会更明显。
而像Elasticsearch这类搜索引擎，在新增索引字段时，其实是在内存中构建倒排表。一旦数据量大，heap size设置不合理，很容易触发GC频繁甚至节点宕机。
如何减少内存压力
可以考虑分阶段操作。比如先在从库创建索引，完成后再切换主从角色。或者使用在线DDL工具，像pt-online-schema-change，它通过创建影子表逐步同步数据，避免长时间锁表和集中内存消耗。
另一个办法是控制并发。不要同时为多个大表创建索引。可以通过脚本排队执行，监控系统负载，错开高峰时段。
还可以调整数据库参数。比如MySQL中适当调大 innodb_online_alter_log_max_size，有助于减少重建表时的内存峰值。当然，调参前得评估服务器实际资源，别让优化变成雪崩的导火索。
小表也不该掉以轻心
有些开发者觉得“我这表才几千行，随便建”。但如果应用频繁重启、测试环境反复初始化，每次都重新建索引，累积起来的内存申请和释放会造成碎片，长期下来影响整体性能。特别是在容器化部署中，内存限制严格，这种“小动作”反而容易触发限流或重启。
所以，哪怕只是本地调试，也建议在不需要时及时删除无用索引。每多一个索引，不仅是磁盘空间的浪费，更是内存潜在的负担。