前两天帮一个创业团队搭数据库，对方技术小哥上来就问：“MySQL装哪个版本靠谱？”我愣了一下，反问他：“你数据库要跑什么业务？”他挠挠头说：“就几个用户的小项目，随便装一个就行吧。”我心想，这种“随便”的心态，往往是后面踩坑的起点。MySQL 安装看着简单，几步就能搞定，但真正的问题不在安装过程本身，而在于你装之前有没有想清楚：这台服务器要干什么？数据量大不大？读写频繁不频繁？有没有备份策略？这些如果没想透，装出来的数据库就像盖房子没打地基，后面加索引、调参数，都是缝缝补补。
选版本就是典型的例子。很多人一上来就奔着最新版去，觉得新版本功能多、性能好。但 MySQL 8.0 刚出时，不少企业升级后遇到兼容性问题，尤其是老项目的字符集从 utf8 变成 utf8mb4，直接导致程序报错。反过来，如果业务简单到极致，MySQL 5.7 已经足够稳定，社区支持也成熟。我见过一个做电商的朋友，用 5.6 跑了三年，数据量才几百兆，却硬要升级到 8.0，结果改了一周代码。版本不是越新越好，关键是匹配你的场景。如果业务涉及复杂查询、JSON 数据或窗口函数，8.0 的优势就很明显；如果只是存日志、跑博客，5.7 甚至更老的版本都绰绰有余，别为了“时髦”给自己找麻烦。
安装方式的选择同样藏着坑。Linux 下用 apt‑get 或 yum 一键安装最常见，省事，但默认配置往往是个“通用模板”。比如 MySQL 的默认内存分配很小，适合开发机，却在生产环境里查询稍密集就会卡死。另一个常见误区是自行编译源码。我有个同事非要自己编译，觉得这样性能最好，结果编译花了三小时，中间缺了三个依赖库，折腾到凌晨两点。后来发现，用官方二进制包安装，性能几乎没有差别。编译安装适合需要定制内核参数的大厂，普通场景下，官方二进制包或包管理器安装就足够。关键是把安装后的配置调对，而不是在安装方式上炫技。
配置文件的调整才是真正考验人的地方。很多新手装完 MySQL，连参数都没改就上线，结果跑了两天发现内存飙到 90%。默认配置里，innodbbufferpoolsize 通常设得很保守，比如 128 MB，这对 64 GB 内存的服务器来说是种浪费。我一般建议把这个值调到物理内存的 70% 左右，但要留出系统和其他进程的余量。另一个容易被忽略的参数是 maxconnections。默认值 151 听起来够用，但如果有几十个应用同时连接，每个连接开几个线程，很快就会撑爆。我见过一个案例，某 SaaS 平台高峰期连接数冲到 500，MySQL 直接拒绝新连接，用户端疯狂报错。后来把 maxconnections 调到 1000，配合连接池，问题才解决。
数据目录和日志的分离也是安装时容易忽略的细节。很多人图省事，把所有东西都放在默认的 /var/lib/mysql 里。但生产环境里，数据盘和系统盘最好分开。系统盘一般用 SSD，容量小，主要跑操作系统；数据盘可以用更大的 HDD 或混合存储。把 MySQL 的数据目录挂载到独立的数据盘上，既能避免系统日志撑爆磁盘导致数据库崩溃，也方便后续扩容。我有一个做游戏运维的朋友，他们的 MySQL 数据目录和系统盘混在一起，有一次系统日志写爆磁盘，MySQL 直接宕机，玩家数据丢了半小时。后来他痛定思痛，重新规划分区，还加了独立的日志目录，定期清理归档。
安全配置很多人觉得是“额外步骤”，其实应该在安装时就搞定。MySQL 默认的 root 账户没有密码，或者密码太简单，这是最致命的漏洞。前两年有个小公司数据库被勒索，就是因为 root 密码是 123456，黑客直接登录删了所有表。安装后第一件事就是运行 mysqlsecureinstallation 脚本，它会强制你改密码、删除匿名用户、禁止 root 远程登录。另外，监听地址也很关键。默认 MySQL 监听 0.0.0.0，意味着任何 IP 都能尝试连接。如果服务器有公网 IP，就等于把数据库暴露在全世界的扫描器面前。我一般建议只监听内网 IP，或者干脆绑定 127.0.0.1，通过应用服务器转发请求。
备份策略必须在安装时就想好，而不是等数据丢了再慌。很多人装完 MySQL 就以为万事大吉，觉得“数据不会丢”。但硬盘会坏，机房会断网，人为误操作更是防不胜防。最简单的备份方案是用 mysqldump，每天凌晨跑一次全量备份。但这种方法对大数据量不友好，几 GB 的表导出要半小时。更专业的做法是结合 binlog 做增量备份。安装时把 logbin 参数打开，这样每天全量备份一次，加上 binlog 的连续记录，即使某天凌晨三点误删了数据，也能恢复到误操作之前的时间点。我认识一个 DBA，他们团队用这种方案，有一次程序员手滑删了生产表，花了 20 分钟就恢复了，老板差点给他涨工资。
说说安装后的验证。很多人装完 MySQL，跑个 SELECT 1 就以为万事大吉，但实际业务跑起来后，各种诡异问题才浮出水面。比如字符集没设对，中文存进去变成乱码；时区默认是 UTC，应用层和数据库时间对不上；sqlmode 太严格，某些 SQL 执行报错。我习惯装完后走一遍检查清单：字符集改成 utf8mb4，时区设为 Asia/Shanghai，sqlmode 去掉 ONLYFULLGROUP_BY 等容易出问题的选项。然后建一个测试表，插入几行中文数据，确认读写正常。再用 sysbench 跑个简单的压力测试，看看 CPU 和内存占用是否合理。这些步骤加起来也就十几分钟，却能省掉后面无数排查问题的精力。数据库安装从来不是“装完就结束”的事，它更像是一个起点，后面还有配置调优、监控告警、灾备演练这些更重的活等着你。但第一步走对了，后面的路就好走很多。
