Jimmy Angelakos：LinkedIn直播：好吧，所以你继承了一个糟糕的数据库……
内容提要
继承糟糕数据库是常见问题，源于历史原因或架构傲慢。应对策略包括：不恐慌，借机修复；询问用户痛点，避免XY问题；全面检查架构、配置和日志；小步改进并记录；自动化高可用和备份；团队共享准则。预防胜于补救，提前规划备份、高可用和优化。
延伸解读
历史遗留问题与“架构傲慢”
文章指出，糟糕数据库往往源于“历史原因”：团队没有DBA、工期紧、自然增长等。此外，作者提出“架构傲慢”概念：新加入的架构师忽视最佳实践，自信设计出难以维护的系统。理解这些成因有助于避免指责，转而聚焦于解决问题。
警惕XY问题：先问用户真正需求
在修复过程中，作者提醒注意“XY问题”：当用户要求分区或Kafka管道时，需先弄清其背后真正想解决的问题。直接实现请求可能偏离实际需求，导致资源浪费。因此，倾听用户痛点时，要深入挖掘，确保解决方案对症下药。
小步快跑与自动化运维
修复策略强调小项目、可衡量目标，一次只改一处并记录文档。同时，自动化高可用、灾难恢复和维护，并将准则共享给团队，避免独自承担。这有助于防止问题复发，并提升整体系统的健壮性。
预防优于补救：提前规划
作者强调不要等到数据丢失才备份、宕机才规划高可用、膨胀才调优autovacuum、十亿行才分区、云账单吓人才优化。提前规划这些方面，能避免陷入被动应对的困境，减少未来继承“坏数据库”的可能性。
Q&A
为什么会出现糟糕的数据库？
糟糕的数据库通常源于历史原因，如没有DBA、赶工、自然增长，或架构师的傲慢（即“架构病”），他们忽视最佳实践而设计出难以维护的系统。
继承糟糕的数据库后，第一步应该做什么？
不要恐慌，要认识到这些问题是可以解决的，并视之为修复问题的机会。
如何了解用户对数据库的真实需求？
询问用户痛点，让他们抱怨，但要注意避免XY问题，即用户提出的解决方案可能不是真正的问题，要挖掘其背后的真实需求。
检查糟糕数据库时应该关注哪些方面？
应该全面检查：用pg_dump、pgAdmin或DBeaver检查schema，用探索性查询检查数据，通过日志、pg_stat_activity和pg_stat_statements检查配置和行为。
修复糟糕数据库时，如何确保改进有效且可维护？
采用小步快跑的方式，一次只改一个地方，设定可衡量的目标，并记录文档。同时，自动化高可用、灾难恢复和维护，并与团队共享准则，避免独自承担。
如何避免未来再次出现糟糕的数据库？
预防胜于补救，应提前规划备份、高可用、自动vacuum调优、分区和成本优化，而不是等到问题发生后再应对。
