Jimmy Angelakos：LinkedIn直播：好吧，所以你接手了一个糟糕的数据库……
内容提要
继承糟糕数据库时，别慌，问题可解。先倾听用户痛点，避免XY问题，全面检查模式、数据和配置。以小项目逐步修复，记录过程，并自动化高可用与维护。团队协作分享准则，从被动应对转向主动规划，防患于未然。
延伸解读
接手烂库先别慌
文章强调，接手糟糕数据库时，首要的是不要恐慌。这类问题通常源于历史原因，如团队当时没有DBA、工期紧张或系统自然演化，甚至可能是“架构师病”——过度自信的设计导致后期维护困难。重要的是，指责无济于事，而应视之为解决问题的机会。
倾听用户，避免XY问题
修复前应先了解用户的实际痛点，鼓励他们抱怨。但要警惕“XY问题”：当用户提出具体技术方案（如分区或Kafka管道）时，需探究其背后的真实需求，避免盲目实施。这有助于确保解决方案真正对症下药，而非浪费资源。
小步快跑，逐步修复
建议通过小项目、可衡量的目标来逐步修复，一次只改一处，并记录过程。同时，自动化高可用、灾备和维护，并与团队分享准则，避免独自承担。这种渐进式方法能降低风险，确保持续改进。
从被动应对到主动规划
文章强调，不要等到数据丢失才备份、宕机才规划高可用、膨胀才调优autovacuum、行数过亿才分区、云账单惊人才优化。应提前规划，防患于未然，将被动应对转为主动管理，以降低未来风险。
Q&A
接手一个糟糕的数据库时，首先应该做什么？
首先不要慌张，要认识到这些问题是可以解决的。同时，把这次接手视为一个改进的机会，因为你有权限去修复问题。
什么是“XY问题”，在倾听用户需求时如何避免？
XY问题是指用户提出一个解决方案（Y），但实际要解决的是根本问题（X）。在倾听用户痛点时，要探究他们真正想解决的问题，而不是直接实现他们提出的方案。例如，当有人要求分区或Kafka管道时，先弄清楚他们实际要解决的业务问题。
接手糟糕数据库后，如何全面检查数据库？
需要检查模式（schema）、数据、配置和行为。模式可以用pg_dump、pgAdmin或DBeaver查看；数据通过探索性查询检查；配置和行为通过日志、pg_stat_activity和pg_stat_statements来观察。
修复糟糕数据库时，应该采用什么样的项目策略？
应该采用小项目、可衡量目标的方式，一次只做一项更改，并记录整个过程。这样可以逐步改进，避免大规模改动带来的风险。
在修复数据库后，如何防止问题再次发生？
需要自动化高可用性、灾难恢复和维护，并与整个团队分享准则。不要独自修复，否则会独自承受，而其他人仍按旧方式行事。要从被动应对转向主动规划，提前考虑备份、高可用性、自动清理、分区和成本优化。
糟糕数据库通常有哪些典型症状？
典型症状包括：不正确的数据库编码、表有上百列（因为曾是电子表格）、缺少索引、没有约束导致数据不一致等。
为什么说“指责不是策略”？
因为糟糕数据库的产生往往有历史原因，如团队没有DBA、紧迫的截止日期、自然增长或架构师的傲慢。重要的是解决问题，而不是追究责任。
