不少团队在服务器上装好MySQL之后，直接改个root密码就投入使用，结果业务量一上来就出现连接被拒、查询缓慢、内存告警等各种问题。MySQL的默认配置是为了在最低配置的机器上也能跑起来而设计的，与生产环境的实际硬件能力相差甚远。安装阶段的每一个选择，以及安装完成后的参数调整，都会直接影响数据库的稳定性和性能表现。本文将从安装方式、核心参数、系统层面三个角度，完整讲解如何在服务器上完成一次面向生产环境的MySQL安装优化。
安装阶段的选择：版本、方式与初始配置
安装MySQL的第一步是选对版本。目前主流选择是8.0系列，相比5.7在查询优化器、JSON处理和并行能力上有明显提升，同时8.0已经进入成熟稳定期，生产使用没有问题。如果是新项目，建议直接使用8.0的最新小版本，避免早期版本的已知缺陷。需要注意的是，MariaDB与MySQL虽然同源，但在部分特性与配置参数上已经分道扬镳，两者不要混用配置文件。
安装方式上，生产环境推荐使用官方yum源或apt源安装，而不是源码编译。包管理器安装的好处是升级路径清晰、服务脚本齐全、目录结构规范，出问题时排查成本低。以CentOS为例，安装前可以先禁用系统自带的mariadb相关包，避免依赖冲突。安装命令执行完成后，第一次启动会进行数据目录初始化，这个阶段务必确认数据目录放在合适的磁盘分区上，而不是默认的/var/lib/mysql一装了事。如果服务器有多块磁盘，把数据目录放在性能最好的SSD上，是零成本就能获得的性能提升。
安装完成后还有几件必须立刻做的事：运行安全初始化脚本移除匿名账户和测试库、为root设置强密码、创建业务专用账户而不是让应用直接用root连接、确认字符集设置为utf8mb4。utf8mb4不仅支持emoji存储，也是MySQL 8.0的默认字符集，老版本升级时要特别注意统一character_set_server参数，避免出现乱码或索引失效的隐性问题。
核心参数优化：让MySQL真正用上硬件资源
MySQL安装后的优化重点在my.cnf配置文件（部分发行版为mysqld.cnf）。默认配置中最需要调整的是InnoDB缓冲池大小。这个参数决定了多少数据和索引可以常驻内存，是MySQL性能的第一影响因素。经验值是设置为服务器物理内存的50%到70%，例如一台16GB内存、只跑数据库的服务器，可以设置为10GB到12GB。设置过小会导致大量磁盘IO，设置过大则可能与其他进程争抢内存，触发swap反而更慢。8.0版本还建议开启缓冲池的自动预热参数，重启后能快速恢复性能。
连接相关参数同样重要。max_connections默认值只有151，对于有一定并发的Web应用远远不够，通常建议设置为500到1000，但不要盲目调到几万，因为每个连接都会消耗内存和线程资源，连接数过高往往是应用层连接池配置不当的信号，应该优先修复应用而不是硬扛。同时配合调整thread_cache_size，让线程可以复用，减少频繁创建销毁的开销。wait_timeout默认8小时，容易导致大量空闲连接长期占用资源，生产环境建议缩短到600秒左右，并要求应用侧使用连接池管理连接生命周期。
下面给出一套适用于中等配置服务器（16GB内存、4核CPU、SSD磁盘）的参考配置：
[mysqld] # 基础设置 user = mysql port = 3306 basedir = /usr/local/mysql datadir = /data/mysql socket = /data/mysql/mysql.sock character-set-server = utf8mb4 collation-server = utf8mb4_general_ci # 内存与缓冲池设置 innodb_buffer_pool_size = 11G innodb_buffer_pool_instances = 8 innodb_log_file_size = 1G innodb_flush_method = O_DIRECT max_connections = 800 thread_cache_size = 64 wait_timeout = 600 interactive_timeout = 600 # 慢查询与日志 slow_query_log = 1 slow_query_log_file = /data/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = 1 # 临时表与排序 tmp_table_size = 64M max_heap_table_size = 64M sort_buffer_size = 4M join_buffer_size = 4M
这套配置中有几个点值得展开说明。innodb_flush_method设置为O_DIRECT，可以让InnoDB跳过操作系统缓存直接写磁盘，避免双重缓冲浪费内存，前提是磁盘本身有较好的性能。innodb_log_file_size关系到崩溃恢复时间和写入吞吐，写入密集的业务建议设置为512MB到2GB之间。slow_query_log务必在生产环境开启，long_query_time设为1秒起步，后续根据业务特征逐步收紧，这是后续所有SQL优化的数据来源。tmp_table_size和max_heap_table_size控制内存临时表的上限，过小会导致临时表落盘，多表关联查询时性能会断崖式下跌。
系统层面配合：文件句柄、磁盘与安全加固
MySQL的优化不只停留在配置文件内，操作系统层面的配合同样关键。首先是文件句柄数限制，Linux默认的1024对于数据库服务来说太低，表数量一多或连接一密集就会报错。需要在systemd服务单元或/etc/security/limits.conf中将打开文件数提升到65535以上，同时MySQL内的open_files_limit参数也要相应调大。其次是swap策略，数据库服务器建议将vm.swappiness调整为1或0，尽量不使用交换分区，内存不足时宁可让它报错告警，也不要让数据库在swap中缓慢挣扎。
磁盘IO调度策略也会影响写入性能。对于SSD设备，建议将调度器设置为none或noop，减少不必要的排队重排开销；机械硬盘则保持默认的mq-deadline即可。可以临时通过sysfs修改验证效果，例如向对应设备的调度文件写入none，确认有效后再写入开机自动执行。数据目录所在分区建议使用XFS文件系统，它在高并发写入场景下的表现比ext4更稳定，且注意在挂载参数中加上noatime，减少无意义的访问时间写入。
安全加固方面，生产服务器上的MySQL应该关闭3306端口对公网的暴露，只监听内网地址或通过bind-address限定访问来源；账号权限按最小化原则分配，应用账户绝不授予ALL PRIVILEGES；定期使用mysqldump或更高效的物理备份工具做全量备份并验证可恢复性。此外建议开启performance_schema，它带来的开销很小，却是定位性能问题的重要抓手。最后，所有参数调整后务必观察一周以上的监控数据，包括TPS、连接数、缓冲池命中率、慢查询数量，用数据验证优化效果，而不是改完就当万事大吉。数据库优化是一个持续迭代的过程，安装阶段的良好配置只是打下了地基，后续还需要结合慢查询日志和业务变化不断微调。