上周帮一个创业公司装数据库，对方技术负责人拍着胸脯说“这活儿我熟”，结果装到一半，服务器直接卡死，数据全丢了。后来我花了整整一个通宵，从备份里一点点捞回来。这哥们儿蹲在旁边，脸都绿了，嘴里反复念叨一句话：“我以为装个数据库就跟装个软件一样简单。”其实这种想法，我见过太多次了。
数据库安装部署看着简单，真上手就知道坑有多深。很多人第一步就栽在环境准备上。你打开官方文档，上面写着“推荐操作系统版本XX”，可你偏觉得自己服务器上那个老版本 CentOS 挺稳，结果装到一半，依赖包缺了一堆，报错信息满屏飞。更别提那些动不动就要求内核参数调优的数据库了，像 Oracle，一个 shmmax 没设对，装完跑起来性能直接打五折。我见过最夸张的一次，有人为了省事儿，直接在 Windows 上装了个 MySQL，结果生产环境一上线，连接数一上来，系统直接蓝屏。环境这事儿，真不能凭感觉来，得老老实实对着官方清单一项项过，哪怕觉得多余的配置，也得先确认清楚再动。
下载安装包这一步，看着最没技术含量，却翻车概率最高。官方下载链接藏得深，像 Oracle，你得先注册账号，填一堆表单，才能拿到几 GB 的压缩包。有人图省事儿，从第三方网盘下载，结果包里被植入挖矿脚本，装上后服务器 CPU 直接飙到 100%。还有更离谱的，下载到一半网络断了，包没下完整，安装时提示校验失败，又得重来。我的习惯是，永远只从官网下，下载完第一件事就是核对 MD5 或 SHA256 校验码，这个步骤虽然麻烦，但能挡掉 90% 的坑。另外，数据库版本也得仔细挑，别一上来就追最新版，那些刚发布的大版本，Bug 往往还没修完，生产环境用了就是给自己找麻烦。
解压和目录规划这块，很多人觉得无所谓，随便扔个目录就行。但等你真正跑起来，就知道这有多要命。数据库的日志、数据文件、配置文件、备份文件如果全堆在一个盘里，哪天磁盘满了，系统直接崩溃，你想清理都不知道从哪下手。我见过最乱的情况，有人把 MySQL 的数据目录直接放在系统盘，结果系统日志一膨胀把磁盘塞满，数据库挂了不说，连 SSH 都登不上去。正规的做法应该是，提前规划好数据盘、日志盘、备份盘，挂载到不同目录，每个目录留出足够的冗余空间。而且目录命名也要规范，别用 “test”“tmp” 这种名字，项目交接时，新来的运维一看目录名就懵了。
配置文件修改是技术活，也是最容易出幺蛾子的环节。很多人装完数据库，直接用默认配置就跑，结果性能惨不忍睹。比如 MySQL 的 innodbbufferpoolsize，默认才 128 M，你服务器内存有 64 G，这不是暴殄天物吗？但反过来，有人一上来就把这个值设到 50 G，结果系统内存不够，Swap 开始狂用，数据库直接变蜗牛。配置调优得根据实际场景来，OLTP 和 OLAP 的配置思路完全不同。而且每改一个参数，都得搞清楚它到底影响什么，别光看网上那些“十大优化配置”照抄，很多参数在不同版本里含义都不一样，抄错了反而适得其反。我的习惯是，每改一个参数，都写一句注释，记录修改时间和原因，方便以后排查。
初始化数据库和启动服务这步，看着顺理成章，但坑也不少。比如 MySQL 初始化后，默认有个 root 账号，密码是空的，很多人忘了设密码就直接上线，结果被黑客扫到，数据被勒索。PostgreSQL 初始化完后默认只监听 localhost，远程连不上，得去改配置文件里的 listenaddresses。更麻烦的是那些需要配置 SSL 或加密的数据库，像 MongoDB，默认不开启认证，装完直接能连，等被人黑了才想起来去配。所以初始化完成后，第一件事就是设密码、关掉不必要的端口、开启审计日志，这些安全措施必须在服务启动前就做好，别等出了事再补。
验证部署成功这步，很多人只跑个 “select 1” 就完事了。但真正靠谱的验证，需要覆盖几个维度：连接测试，确认客户端能正常连上；权限测试，确认不同账号的权限隔离没问题；压力测试，确认数据库能扛住预期负载；容灾测试，确认备份和恢复流程能跑通。我见过最惨的一次，有人装完 Oracle 后跑了个简单查询，结果正常就走了，结果上线第一天，业务一跑复杂 SQL，数据库直接挂了，发现是 SGA 配置太小，导致大量磁盘 I/O。验证这事儿，得模拟真实业务场景来测，别图省事儿。
备份和恢复策略，很多人觉得这是上线后才需要考虑的事，但部署阶段就得把方案定下来。想想，万一装到一半服务器断电，或者配置文件改错了，数据库起不来了，你怎么办？没有备份，只能从头再来。我的做法是，部署完成后第一件事就是做一次全量备份，然后模拟一次恢复流程，确认备份文件可用。而且备份策略必须自动化，别指望每天手动跑脚本，人总会忘。备份文件还得异地存储，别和数据库放同一服务器，不然服务器挂了，备份也一起没了。
聊聊文档和交接。很多人装完数据库，拍拍屁股就走，留下一堆“我装的，有问题找我”的口头承诺。结果三个月后系统出问题，新人一看，目录结构乱七八糟，配置文件没有注释，日志路径也不清楚，根本无从下手。正规的做法是，部署过程中每一步都记录下来，包括环境配置、参数调整原因、踩过的坑、恢复步骤。这些文档不需要写得华丽，但要让一个没装过该数据库的人，照着文档能完整复现整个流程。而且文档最好放在代码仓库里，和数据库配置一起管理，这样版本变更也能追溯。数据库部署这事儿，说到底是给人用的，不是给神用的，把经验沉淀下来，才是真正对团队负责。
