专栏名称: AustinDatabases

PostgreSQL ACE ,PolarDB 3年, OceanBase 极速学习ING, MongoDB 8年经验, MySQL OCP, SQL SERVER, MCITP，REDIS ，做一个合格的数据库架构师

PostgreSQL 添加索引导致崩溃，参数调整需谨慎--文档未必完全覆盖场景

AustinDatabases · 公众号 · 数据库 · 2025-02-17 06:00

主要观点总结

文章主要围绕数据库技术进行讨论，涉及PostgreSQL、MongoDB、MySQL、PolarDB、OceanBase等数据库的问题和解决方案，以及DBA的工作和AI技术的发展等。将其关键点总结为以下几点：

关键观点总结

关键观点1: PostgreSQL数据库崩溃原因及注意事项

文章详细阐述了PostgreSQL数据库在添加大表索引时引发系统崩溃的问题，分析了内存使用情况和系统反应。同时指出了在维护过程中需要注意的几个地方，如maintenance_work_mem参数的设置和KILL -9命令的使用。

关键观点2: MongoDB相关问题的讨论

文章涉及MongoDB的多个主题，包括MongoDB的使用技巧、分片问题、数据更新案例、表碎片清理等，以及MongoDB在数据处理和建模方面的优势。

关键观点3: MySQL高级应用和性能优化

文章讨论了MySQL如何提升性能的方法，包括内存表的使用、参数调整等，同时提到了MySQL在数据库领域的应用和发展趋势。

关键观点4: PolarDB和OceanBase数据库的特点和使用体验

文章介绍了PolarDB和OceanBase数据库的特点、优势以及在实际使用中的体验反馈，包括性能评测、Serverless特性的讨论等。

关键观点5: 数据库技术的发展和选型建议

文章综述了数据库技术的发展趋势，对分布式数据库、云数据库等进行了讨论，并提出了数据库选型的建议，包括考虑技术、成本、合规和地缘政治等因素。

正文

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2720人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群200 9群)

题目比较混乱，实际上这件事也让我认识到两点问题

1 官方的说明文档，你不能全信，官方文档说明的部分只能是一个大概或者大部分情况，你的情况是否属于这个部分，你的自行评估。

2 参数的调节，是一个漫长的过程，是不断踩坑的过程中总结的，实践是产出经验的地方

3 一些不能使用的命令，在关键时刻，必须使用，这也是我对PostgreSQL的数据库安全担心的地方。

具体案例：

最近遇到一则比较怪的问题，就是关于PostgreSQL大表添加索引，直接引起PostgreSQL crash的问题。故障的现象是，对这张2亿行表添加索引，系统会crash。

以上是当时的情况，从图中和对应日志，我们可以分析到一个问题在添加索引的情况下，且有大量的UPDATE ，在短时间内存使用率持续走高，我们看下面这张图

一开始在添加索引的时候，mem_size_cache持续走低，同时mem_size_rss持续走高。

mem_size_cache是指的操作系统缓存，这是用来缓存磁盘上的数据页的内存，随着添加内存的操作，系统开始检测到内存不足，在不断腾出更多的内存给正在运行的进程。

mem_size_rss 持续走高，RSS 是Resident set size ，这个量是指的在物理内存中实际占用的内存量。

这两个符合在添加索引中内存的消耗，在崩溃的前一刻，系统的mem_size_rss已经接近了20G 整体的内存才32G，shared buffer pool 设置为8G。

从这里分析系统崩溃的主要原因就是内存OOM，然后系统作出了 KILL -9 客户进程的操作，然后系统就开始触发了整体的进程的重启，最后系统进入了recovery_mode，整体进行recoery 的过程在2秒结束。这说明一个问题，系统OOM 的时候操作系统KILL的是客户的添加索引的进程，而不是主进程。如果是重启一个11T的大库2秒是起不来的,尤其还是要进行recovery 的过程。

POSTGRESQL 数据库崩溃的原因搞清楚了，需要我们注意的有几个地方

1 maintenance_work_mem 的设置是否和官方说的是可以更大一点进行设置，到底应该多大，部分情况下设置的过大，会不会出现我们的问题，因为可能一次批量添加很多索引，那么每个进程都会开启使用maintenance_work_mem的模式，包含了一个添加过程中的多个子进程也都可以进行内存的单独分配，所以如果有批量干一些事情的情况下，maintenance_work_mem一定不要设置太大，否则就会和我们一样，操作系统直接发出KILL -9 的命令直接将客户的进程KILL ，而引发整体的进程的重启。

（下图为官方关于此参数的说明）

2 KILL -9 这个问题已经很明确了，在我们个人的操作中是不允许使用KILL-9 去KILL 客户或者系统的进程，这对PG来说是非常容易出现数据丢失，但是在系统层面，如果发现某个进程使用内存太多，他们会直接发起KILL -9 的工作来将这个进程杀死，好让整体系统进行工作。

这类就产生一个问题，到底要不要KILL -9 ，人工我们可以使用命令 pg_terminal_backend（PID）来操作，或者使用kill term 的方式来，但是操作系统在遇到真正的问题OOM 的情况下，是直接上来就KILL 的。所以POSTGRESQL 目前还避免不了系统级的KILL -9的发生。

总结：在POSTGRESQL 分配一些核心内存使用的时候，要注意大小和一次操作的命令的数量，INDEX 有的时候是批量添加，尤其大表容易发生参数设置不对，导致OOM的情况，同时会发生KILL -9 对相关进程的操作。