数据库服务器部署这事儿，听着挺唬人，其实拆开来看，就是一步步把硬件、系统、软件、配置串起来。很多新手一上来就想着“高性能”，结果连基本的磁盘分区都没规划好，上线三天就卡成PPT。我见过最典型的翻车现场：有人买了两块SSD，没做RAID，日志和数据塞同一块盘，一个月后IO等待时间直接飙到30%。所以别急着炫技，先老老实实把地基打牢。
先说硬件选型。CPU核心数别迷信“越多越好”，数据库处理SQL语句时，单核主频比核心数更关键。比如你跑一个复杂的JOIN查询，12核2.0GHz的CPU可能还不如8核3.5GHz的CPU快。内存容量有个黄金公式：数据量×1.5倍。比如你预计存500GB数据，配750GB内存比较稳，因为内存不光要缓存数据，还要给排序、连接操作留空间。磁盘这块，NVMe SSD是首选，SATA SSD只能当备胎。千万别用机械盘做主存储，除非你想体验“查询一次，喝完一杯咖啡”的酸爽。RAID级别建议RAID10，读写性能均衡，坏两块盘还能扛住。RAID5虽然利用率高，但写操作有性能损耗，重建时还容易翻车。
操作系统选型，很多人纠结CentOS还是Ubuntu。说实话，对于数据库服务器，稳定压倒一切。CentOS 7在2024年停服了，但它的商业版Rocky Linux或AlmaLinux可以无缝接盘。Ubuntu LTS版本更新，软件包新，但如果你团队习惯用yum，硬切apt-get会踩坑。系统安装时，磁盘分区要提前规划。建议分三个区：/boot给500MB就够了，swap分区按内存大小来，如果内存超过64GB，swap设成8GB足够。剩下的空间全给根分区，但千万别把所有数据都塞进根分区。最佳实践是把数据库数据目录（比如MySQL的/var/lib/mysql）单独挂载一块盘，这样系统盘坏了数据还在，扩容也方便。内核参数要调一下：vm.swappiness改成1，避免系统频繁用swap；net.core.somaxconn改成65535，应对突发连接；还有文件系统，XFS比ext4更适合大文件场景，数据库日志和表空间文件动辄几十GB，XFS的分配效率明显高。
数据库软件安装，别用系统自带的yum源，版本太老。比如MySQL 5.7已经停止更新，但很多教程还在教装它。建议直接上MySQL 8.0或Percona Server，或者PostgreSQL 16。安装方式推荐用官方二进制包，或者用Docker跑。Docker的好处是环境隔离，但注意磁盘IO问题，要把数据目录通过volume挂载到宿主机，别用虚拟文件系统。配置参数是重头戏。InnoDB缓冲池大小设为物理内存的70%-80%，比如64GB内存设48GB。日志文件大小设成1GB，太小的话频繁切换日志，影响写入性能。查询缓存一定要关掉——MySQL 8.0直接移除了这个特性，因为它在高并发场景下反而拖慢速度。连接数上限设成500-1000，但需要配合操作系统文件描述符限制，先执行ulimit -n 65535把上限提上去。
数据目录管理是门学问。很多人直接把数据盘挂载到根目录下的某个文件夹，结果磁盘满了系统直接宕机。正确做法是：数据盘单独分区，比如/dev/sdb，格式化成XFS，挂载到/data/mysql。然后把MySQL的数据目录软链接过去。这样系统盘和数据盘物理隔离，就算数据盘满了，系统盘还能正常写日志，至少能让你远程连上去处理。日志目录也要分开，二进制日志、慢查询日志、错误日志各放各的文件夹。我见过最惨的案例：有人把错误日志和binlog放一起，结果binlog暴涨把磁盘撑爆，连错误日志都写不进去，排查问题全靠猜。
安全加固这块，很多人觉得“内网环境不用太紧张”，结果被挖矿脚本扫到怀疑人生。第一件事：改默认端口。3306这个端口是黑客的“必扫门牌号”，改成63306或者自定义端口，至少能过滤掉90%的自动化攻击。第二件事：创建独立用户。别用root直连业务，给每个应用分配专用账号，权限按最小化原则给。比如一个只读报表应用，只给SELECT权限，连INSERT都不给。第三件事：启用SSL连接。虽然会带来5%-10%的性能损耗，但能防止数据在传输中被抓包。第四件事：配置防火墙。只允许应用服务器的IP访问数据库端口，其他IP全部拒绝。云服务商的安全组规则也要同步设置，别只依赖服务器上的iptables。
性能压测和调优是必经之路。别等到上线才发现慢，用sysbench或HammerDB先跑一轮。压测时重点关注三个指标：QPS（每秒查询数）、TPS（每秒事务数）、响应时间。如果QPS上不去，先看磁盘IO是否饱和，用iostat看%util指标，超过70%就说明磁盘是瓶颈。如果TPS低，调整innodblogfilesize和innodbflushlogattrxcommit参数，前者设大点减少日志切换，后者设成2（每秒写一次）提升性能，但注意会丢1秒数据。还有连接数问题：如果业务突发请求量很大，配连接池组件（比如ProxySQL或PgBouncer），防止数据库被突发连接打崩。
备份和容灾策略，是一道防线。很多人觉得“每天备份一次就够了”，结果磁盘坏道导致数据全毁，恢复时才发现备份文件也损坏了。建议用“3-2-1”备份策略：至少3份副本，2种不同存储介质，1份异地存储。比如每天凌晨用XtraBackup全量备份到本地NAS，同时通过rsync同步到对象存储。增量备份每2小时做一次，用binlog来补全时间点。容灾方面，主从复制是基础，但别只做异步复制，半同步复制能保证主库挂了后从库数据不丢。如果预算够，再搭一个异地灾备节点，延迟控制在100ms以内，主库机房停电时能秒级切换。
说一个很多人忽略的点：监控和告警。部署完不管就等于裸奔。Prometheus+Grafana是目前主流方案，用mysqld_exporter采集数据库指标，重点监控：连接数使用率（超过80%告警）、慢查询数量（超过阈值就排查）、磁盘空间（低于20%告警）、复制延迟（超过10秒告警）。告警别用邮件，现在谁天天查邮箱？直接推送到钉钉或企业微信。我见过最离谱的案例：某公司数据库挂了4小时，运维说“没看到邮件”，后来换成电话告警，15分钟就响应了。数据库部署从来不是“装完就完事”，它是一个动态的、需要持续维护的过程。从硬件选型到监控告警，每个环节都踩过坑、流过泪，才会真正理解“从零搭建高性能系统”这句话的分量。
