我刚入行那会儿，最怕听到的一句话就是“去把数据库装一下”。倒不是数据库难装，而是每次装完，总有人跳出来骂：“你这配置不对啊”“权限怎么这么设”“跑个压测就崩了”。后来我才慢慢明白，数据库安装看似简单，实际上是个深坑。就像装修房子，贴壁纸谁都会，但墙没找平，壁纸早晚会裂。
很多人装数据库，第一反应就是下载个安装包，一路点下一步，默认选项全点过去。这样确实能跑起来，但跑得稳不稳、快不快，就看运气了。我见过一个团队把 MySQL 装在 Windows 服务器上，数据盘还和系统盘共用，结果三个月后硬盘满了，整个系统直接宕机。他们这才发现，安装时没人考虑数据放哪、日志放哪、归档放哪。这种坑，踩一次就够了，却总有人前赴后继地去踩。
安装前的规划其实比安装本身重要得多。你要想清楚几件事：这台机器是生产环境还是测试环境？预期并发有多大？数据量大概多少？要不要做主从复制或集群？这些问题不搞清楚，装出来的数据库就像一艘没有导航的船，看着完整，一开动就会迷路。我习惯先画一张架构图，把网络、存储、备份、监控等环节都标清楚，然后再动手。别嫌麻烦，这一步省了，后面补坑的时间足够你哭好几回。
操作系统层面的准备也容易被忽略。很多人不知道，Linux 内核参数对数据库性能影响巨大。比如 ，默认是 60，意思是内存不足时会优先使用 swap。但对数据库来说，频繁换页等于自杀。我一般会调到 1 或 10，让内存尽量撑住。还有 、 等，都要按数据库厂商的建议调。别相信“默认就是最优”，那是给通用场景准备的，不适用于 MySQL 或 PostgreSQL。
磁盘是重灾区。我用过一台机器，RAID 卡缓存策略没改，写操作走的是直通模式，结果数据库写吞吐量掉了八成。后来发现 RAID 卡默认是 “Write Through”，必须改成 “Write Back”。这种细节文档上写得很清楚，但很少有人逐条去看。还有文件系统，XFS 和 ext4 选哪个？我更倾向 XFS，尤其是大文件场景，它分配空间更高效。但前提是格式化时把 block size 和 inode ratio 算对，否则后面扩容会受限。
数据目录和日志目录最好分开。有人图省事，全部塞在一个分区，结果日志把空间吃光，数据写不进去，整个库就卡死了。更麻烦的是恢复时分不清哪些是数据，哪些是日志。我一般会给数据目录单独挂一块 SSD，日志目录放另一块，或者至少用不同的分区。备份目录更不能和数据目录放一起。把备份写在同一块硬盘上，那算备份吗？那只是心理安慰。
权限设置是技术活，也是出事最多的地方。数据库的 root 账户默认就是“上帝视角”，谁拿到都能删库跑路。我见过有人图方便，所有开发都用同一个高权限账号，结果某段代码里出现 SQL 注入，整个库的表被清空。事后查日志，分不清是谁干的。正确的做法是遵循最小权限原则：一个应用一个账号，只授予它需要的表权限。别嫌麻烦，权限控制越严，出事的概率越低。
安装过程中的日志输出，很多人直接关掉，觉得占地方。但数据库启动失败时，那些日志是唯一的救命稻草。我装 Oracle 时遇到过一件事，安装进程卡在 85% 不动，查了半天才发现是 空间不足。要是没开详细日志，你根本不知道问题所在。所以我的习惯是：安装时把日志级别调到最高，文件存到固定目录，装完也别删，留着后面排查用。那些“安装成功”的提示，有时是骗人的。
安装完成后的验证不能只看进程是否在跑。你得连上去执行几条 SQL，看看能否正常读写。最好再模拟一下并发，检查连接池是否有问题。我有个同事装完 MySQL 后很开心，结果第二天应用连不上，原因是 设得太小，默认 151，而应用框架的连接池需要 200。这样的情况，装完跑个压测就能暴露，但很多人懒得做这一步。
安全配置也是安装的一部分，绝不是可有可无的彩蛋。默认端口最好改掉，3306、5432 这些太容易被猜。远程访问权限要关紧，除非真的需要从别的机器连。还有 SSL/TLS，虽然配置麻烦，但数据传输加密不是锦上添花，而是底线。我见过一家公司，数据库直接暴露在公网上，密码还是 123456，被黑客拖库后才发现。这种悲剧，装数据库时多花半小时完全可以避免。
文档化是一环，也是最容易被跳过的。装完数据库后，把配置参数、目录结构、账号权限、备份策略都记录下来。下次别人接手或你自己半年后回来看，都能快速了解。我见过太多人装完后拍拍屁股走人，留下一个“黑盒”。后来出问题，没人知道当初怎么配的，只能重装。写文档不费多少时间，却能救命的次数远超想象。
数据库安装说到底是一个系统工程。它不是“点几下鼠标”那么简单，也不是“跑个脚本”就完事。每一步都藏着细节，每个细节都可能变成明天的灾难。但好消息是，这些坑大部分是可预见的，只要愿意多花时间准备、测试、验证。装好一个数据库，就像养一盆花，前期土壤、光照、浇水都弄对了，后面才会长得稳当。别急着跑，先走稳。
