企业官网建设流程全解析

最近给公司的内部模拟项目重搭数据库环境，指定的版本是 MySQL 8.0。装完之后顺手做了一轮完整的基准测试，整个过程踩了不少坑，也把 sysbench 的常用姿势彻底捋了一遍。这篇文章就把从零安装到压测出报告的全过程记录下来，包括我试过的配置调整、最后采用的部署方案、测试结果怎么解读，以及几个最容易让人卡住的报错和处理方法。不管你是第一次装 8.0，还是想验证一下服务器性能，这篇文章应该都能给你省点时间。

1. 安装前的思路整理：选版本、定环境、避坑规划

1.1 为什么是 MySQL 8.0

MySQL 8.0 发布已经有好几年了，现在选择 8.0 基本没什么犹豫的必要，尤其是新项目。相比 5.7，8.0 在底层做了非常多关键改动，性能、安全、可用性都有明显提升。

我主要看重这几点：第一是默认的字符集已经是utf8mb4，从源头解决了中文和 emoji 存储乱码的问题，老项目还在用utf8mb3的应该都体会过那种动不动就报“字符串过长”的痛；第二是窗口函数和公用表表达式（CTE）的支持，写复杂统计分析 SQL 的时候能省掉大量临时表操作，逻辑也清晰很多；第三是数据字典变成了统一的事务字典，元数据不再散落在 MyISAM 表里，information_schema的查询速度明显变快；第四是安全这块默认启用caching_sha2_password认证插件，比 5.7 的mysql_native_password强度高不少，虽然这玩意儿也带来了一些兼容性问题，后面我会细说。

在性能层面，8.0 对 InnoDB 的优化也很实在，比如自适应哈希索引的改进、只读事务的优化、redo log 的简化处理等。实测在同配置机器上，8.0 的只读吞吐量通常能比 5.7 高出 20%~30%，这在后面的压测数据里也能体现出来。

1.2 安装方式和环境规划的选择

MySQL 的部署方式现在主要有三种：包管理器安装（yum/apt）、二进制 tar 包解压安装、Docker 容器化部署。我做这次测试的时候选的是二进制 tar 包安装，原因很简单：

• 包管理器安装通常会依赖系统自带的软件源，版本可能偏旧，而且安装目录分散，后续想清理或迁移比较麻烦；
• Docker 部署虽然省事，但网络和存储的桥接模式对基准测试结果会有影响，尤其是延迟指标不干净；
• 二进制包解压后所有文件集中在同一个目录下，路径可控、版本可控，最方便做性能调优和排查问题。

服务器的配置是 8 核 16G 的虚拟机，操作系统是 CentOS 7.9，数据盘是一块普通的 SSD，没有做 RAID。这个配置不算高，但是做基准测试和日常开发环境已经够用了，如果你的机器配置更高或者用的是云主机，整个安装步骤是完全一致的。

注意：如果你用的是 Ubuntu/Debian 系列，把后面命令里的yum换成apt，另外要考虑用ufw而不是firewalld管理防火墙，其他差异不大。

安装前的检查事项我也列一下，这几个坑基本上每台新机器都会遇到：

• 确认系统版本和架构：uname -m，如果是 arm64 架构要下载对应的 aarch64 版本；
• 检查是否已经存在 MySQL 或 mariadb：rpm -qa | grep -E 'mysql|mariadb'，有残留先装yum remove清理干净，否则端口和 socket 文件会冲突；
• 确认libaio依赖：MySQL 的初始化过程需要libaio，没有的话直接报错error while loading shared libraries: libaio.so.1，yum install -y libaio即可；
• 检查selinux状态：getenforce，如果是Enforcing状态建议临时调整为Permissive，不然 MySQL 写数据目录或者开监听端口都有可能被拦截，排查起来非常隐蔽。

系统检查和依赖处理完之后，下一步就是正式下载和解压安装。

2. 二进制部署 MySQL 8.0 的完整操作

2.1 下载与解压

MySQL 官方下载页会提供多个版本的二进制包，我这里用的是当时的最新稳定版 8.0.36。下载链接的规则比较固定，直接拼 URL 就可以，或者去官网挑对应的版本也不用花太多时间。

cd /usr/local/src wget https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-8.0.36-linux-glibc2.12-x86_64.tar.xz tar -xvf mysql-8.0.36-linux-glibc2.12-x86_64.tar.xz mv mysql-8.0.36-linux-glibc2.12-x86_64 /usr/local/mysql

提示：如果你的网速一般或者服务器在国内，直接下载速度可能很慢，可以考虑用镜像源，但要确认下载的包是官方编译的二进制包，不要随便用第三方重新打包的版本。校验方式是对比 MD5 或者 SHA256 值，下载页上都有对应哈希。

解压完之后，建议顺便把目录属主改一下，创建一个专用的 mysql 系统用户来跑服务，避免直接用 root 启动。虽然现在测试环境没那么严格，但养成好习惯能少踩很多生产环境的坑。

groupadd mysql useradd -r -g mysql -s /sbin/nologin mysql chown -R mysql:mysql /usr/local/mysql

2.2 配置文件与目录初始化

MySQL 8.0 的配置文件默认读取顺序是/etc/my.cnf、/etc/mysql/my.cnf、/usr/local/mysql/etc/my.cnf等。我习惯把配置写在/etc/my.cnf，方便统一管理。

初始化之前要先建好数据目录和日志目录。注意 MySQL 8.0 的 datadir 必须为空目录，否则初始化会报错。

mkdir -p /data/mysql/data mkdir -p /data/mysql/logs mkdir -p /data/mysql/tmp chown -R mysql:mysql /data/mysql

然后写一个最基础的配置文件，先保证能跑起来，后面再根据压测结果逐步调优：

[mysqld] user = mysql port = 3306 basedir = /usr/local/mysql datadir = /data/mysql/data socket = /tmp/mysql.sock pid-file = /data/mysql/mysql.pid log-error = /data/mysql/logs/error.log character-set-server = utf8mb4 collation-server = utf8mb4_0900_ai_ci default-authentication-plugin = mysql_native_password [client] port = 3306 socket = /tmp/mysql.sock default-character-set = utf8mb4

这里我把默认认证插件顺手改成了mysql_native_password，主要是为了兼容后续要用到的压测工具和老的客户端连接方式。caching_sha2_password更安全，但一些老版本的工具和驱动不支持，如果你确定客户端都支持 8.0 的认证方式，保持默认即可，不用专门设置这一行。

这里补充说明一下：8.0 已经明确废弃了mysql_native_password，如果将来升级到更高版本，这个参数可能会被移除。我的建议是生产环境如果客户端没有兼容问题，直接用默认的caching_sha2_password就行；测试和开发环境为了省事可以像我这样临时改掉，但要有意识哪天切回来。

配置文件写好后，执行数据目录初始化：

/usr/local/mysql/bin/mysqld --initialize --user=mysql --basedir=/usr/local/mysql --datadir=/data/mysql/data

初始化完成后，最后几行日志里会输出一个临时 root 密码，类似这样：

[Note] A temporary password is generated for root@localhost: xxxxxxxx

这个临时密码要保存好，后面首次登录强制修改密码会用到。如果初始化过程报错，优先去看 log-error 文件的内容，大部分情况下是目录权限、依赖缺失或者配置路径不对的问题。

2.3 启动服务和安全配置

为了后续方便管理，我直接把 mysqld 注册成了 systemd 服务。写一个 service 文件比每次手动敲命令靠谱得多，特别是重启机器后能自动拉起。

cat > /etc/systemd/system/mysqld.service <<'EOF' [Unit] Description=MySQL Server After=network.target [Service] Type=forking User=mysql Group=mysql ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --daemonize ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s TERM $MAINPID PrivateTmp=false [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl start mysqld systemctl enable mysqld

查看启动状态和错误日志：

systemctl status mysqld tail -f /data/mysql/logs/error.log

如果启动失败，90% 的原因都在 error log 里。常见的有[ERROR] InnoDB: Operating system error number 13 in a file operation，这是数据目录权限没给对；还有[ERROR] Another process with pid xxxx is using mysqld，说明之前有残留进程没清干净。

服务起来后，用临时密码登录，立即修改 root 密码：

/usr/local/mysql/bin/mysql -uroot -p ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的新密码'; FLUSH PRIVILEGES;

到这里装就算装完了。但注意我们只是把服务跑起来了，配置基本是默认状态，要做基准测试之前还差两步：准备专用测试账号和压测用的数据库表，以及根据测试场景调整一部分参数。这两步很关键，接下来单独说。

3. 基准测试方案设计与工具选型

3.1 为什么选择 sysbench

做 MySQL 基准测试，市面上可选的工具有不少，除了 sysbench 还有 mysqlslap、TPCC 模拟工具等。mysqlslap 是 MySQL 自带的简单压测工具，能快速测出单条 SQL 的并发性能，但它的场景太单一，生成的数据量也很小，做不了复杂的读写混合测试。TPCC 类的模拟工具更贴近真实业务，但部署复杂，参数也多，对新手不友好。

sysbench 是这几个方案里综合最合适的：内置了多种测试场景，比如纯主键查询、只读事务、读写混合、批量插入，还支持自定义 lua 脚本做更贴近业务的模拟。它的数据生成流程简洁清晰，测试结果（QPS、TPS、延迟分布）都能直接输出，而且社区活跃，遇到问题基本都能搜到答案。

我用的是 sysbench 1.0.20，通过 yum 安装：

yum install -y sysbench sysbench --version

提示：如果你机器上的源没有 sysbench，可以去官方 GitHub 下载源码编译，编译依赖缺什么装什么，过程也不复杂。但直接用包管理器安装是最省事的，省下的时间拿去跑两轮压测不香吗。

3.2 合理规划测试指标和压测场景

对于 MySQL 基准测试，我最关心的指标有四类：

• QPS（每秒查询数）：衡量数据库整体吞吐量，你的 SQL 执行得有多快；
• TPS（每秒事务数）：衡量事务处理能力，对有写操作的项目比 QPS 更真实；
• 延迟分布（avg、95%、99%）：衡量用户体验，平均延迟低但 99% 延迟很高的话，说明存在偶发慢查询或资源争抢问题；
• 并发连接数：看系统在并发升高的情况下性能曲线怎么变化，找到拐点比追求极限值更有价值。

这次测试我设计了三个场景：纯只读场景（oltp_read_only）、读写混合场景（oltp_read_write）、纯写入场景（oltp_write_only），每个场景分别用 8、16、32、64 线程压一轮，每轮跑 60 秒。这样能同时看到吞吐量的变化和延迟变化，对比调优前后的数据也更有说服力。

sysbench 压测的核心流程分三步：prepare（生成测试数据）、run（执行压测）、cleanup（清理测试数据）。这个跟跑代码很像，先造数据再跑用例最后清理环境。

注意：prepare 阶段生成的数据量要根据服务器内存来定，一般推荐测试表的大小是缓冲池的 1.5~2 倍左右。如果数据量太小全部缓存在内存里，压测结果会虚高；数据量太大磁盘 IO 会成为瓶颈，又测不出数据库本身的能力。我这边 InnoDB buffer pool 准备调成 4G，所以测试表生成到 8G 左右比较合适。

4. 基准测试实操与调优对比

4.1 创建测试库并生成压测数据

先创建专用的测试账号和数据库，压测期间用 root 登录也没问题，但更规范的做法是建一个权限受限的账号，模拟真实应用场景。同时避免把压测产生的数据和业务混在一起：

/usr/local/mysql/bin/mysql -uroot -p -e " CREATE DATABASE IF NOT EXISTS sbtest DEFAULT CHARACTER SET utf8mb4; CREATE USER IF NOT EXISTS 'sbtest'@'%' IDENTIFIED WITH mysql_native_password BY 'sbtest_pass'; GRANT ALL PRIVILEGES ON sbtest.* TO 'sbtest'@'%'; FLUSH PRIVILEGES; "

然后准备 8G 的测试数据。sysbench 的prepare阶段默认会生成十张表，每张表的大小由--table-size参数控制：

sysbench /usr/share/sysbench/oltp_read_write.lua \ --mysql-host=127.0.0.1 \ --mysql-port=3306 \ --mysql-user=sbtest \ --mysql-password=sbtest_pass \ --mysql-db=sbtest \ --tables=10 \ --table-size=1000000 \ --threads=8 \ prepare

这个命令执行完，sbtest库下会生成 10 张sbtest1~sbtest10表。如果--table-size=1000000生成得太慢，可以适当调小，但注意前面说的，数据量不要小于 buffer pool。

经验：sysbench 的 prepare 阶段在机械硬盘上会跑很久，耐心等待的同时留意一下数据目录的大小增长。如果中途 Ctrl+C 中断了，cleanup 之后再重新 prepare，否则会残留半张表影响测试结果。

4.2 初始化调优：从默认配置到合理配置

默认配置下直接压测的话，InnoDB 的 buffer pool 只有 128M，这个数字对于 16G 内存的机器来说实在太保守了。我没有做太激进的大改，只调整了几个对基准测试影响最明显的参数，改完重启服务再压一轮，用数据说话。

调整后的配置片段：

[mysqld] innodb_buffer_pool_size = 4G innodb_buffer_pool_instances = 4 innodb_log_file_size = 1G innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT max_connections = 500 innodb_io_capacity = 2000 innodb_io_capacity_max = 4000

简单说明一下每个参数的作用：

• innodb_buffer_pool_size = 4G：InnoDB 的内存缓冲池，数据读写都会经过这里。对于一台 16G 内存、主要跑 MySQL 的机器，给到 4G~8G 是合理区间，我保守选了 4G；
• innodb_buffer_pool_instances = 4：把缓冲池拆成多个实例，降低并发访问时的内部锁竞争，这个参数在innodb_buffer_pool_size大于 1G 时建议设置；
• innodb_log_file_size = 1G：redo 日志文件的大小。默认值太小，高并发写入场景下容易频繁触发刷盘，像我之前压测就遇到过每秒 2 000 多次检查点的情况，改成 1G 后明显缓解；
• innodb_flush_log_at_trx_commit = 2：事务提交时日志写入操作系统缓存，但每秒才刷一次盘。这个设置牺牲了一点持久性换性能，如果数据安全性要求高的场景应该保持默认的1；
• innodb_flush_method = O_DIRECT：绕过操作系统文件系统缓存，数据文件直接读写磁盘。对基准测试来说，减少双缓存带来的不确定性，结果更可参考；
• innodb_io_capacity：告诉 InnoDB 磁盘每秒能处理多少 IO 请求，SSD 设置 2000~5000 都合理，我选的 2000 比较保守。

注意：如果你是按照压测目标来调优，上面这套配置够用了。但真实生产环境不建议直接照搬，比如innodb_flush_log_at_trx_commit = 2在数据库异常宕机时可能会丢失近 1 秒的事务日志，这个权衡要想清楚。

改完配置重启服务：

systemctl restart mysqld

4.3 三场景压测与结果对比

重启完成后，开始跑正式的压测。前面已经准备好了数据，这里主要是执行run命令。先跑默认配置的一轮作为基线，然后跑调整后配置的一轮，通过对比差异来判断调优是否有效。

下面这个是纯只读场景的压测命令示例：

sysbench /usr/share/sysbench/oltp_read_only.lua \ --mysql-host=127.0.0.1 \ --mysql-port=3306 \ --mysql-user=sbtest \ --mysql-password=sbtest_pass \ --mysql-db=sbtest \ --tables=10 \ --table-size=1000000 \ --threads=16 \ --time=60 \ --report-interval=5 \ run

--report-interval=5表示每隔 5 秒输出一次实时指标，方便观察测试过程中有没有性能波动。跑完之后的汇总输出长这样：

SQL statistics: queries performed: read: 2437868 write: 0 other: 289044 total: 2726912 transactions: 144522 (2408.70 per sec.) queries: 2726912 (45456.20 per sec.) ignored errors: 0 (0.00 per sec.) reconnects: 0 (0.00 per sec.) Latency (ms): min: 8.41 avg: 39.92 max: 572.26 95th percentile: 77.98 sum: 5755805.73 Threads fairness: events (avg/stddev): 9032.6250/42.02

这里面重点看三个数字：TPS（2408.70 per sec）、QPS（45456.20 per sec）、95th 延迟（77.98ms）。读写混合场景和纯写入场景的跑法大同小异，只需把 lua 脚本换成oltp_read_write.lua和oltp_write_only.lua。

同一套命令、同一线程数，我把默认配置和调优后的结果整理到了一个表格里（16 线程下）：

把默认配置和调优后的结果放在一起看，差距非常明显。可见默认配置为了通用性牺牲了太多性能，如果你的 MySQL 是装完就用、没有做任何调优的话，实际能力可能只发挥了六成左右。另外值得留意的是，调优后延迟不仅平均值下降了，95 分位也从 112ms 降到了 72ms，说明不仅吞吐量提高，稳定性也同步提升了。

4.4 并发扩展性观察

单线程数的压测只能反映一个侧面的性能，我后面又跑了 8、32、64 线程的对比，确认这台机器在什么并发下开始到达瓶颈。这个“拐点测试”比极限压测更有参考价值，因为实际业务里不可能只有 16 个连接。

我只读场景下的 TPS 随线程数变化情况（调优后）：

从数据能看出，32 线程到 64 线程之间 TPS 增长已经基本停滞，但延迟却从 134ms 翻倍到了 258ms。这说明这台机器的瓶颈不在 CPU（8 核一直没跑满），更可能出在磁盘 IO 的随机读写能力上——单块普通 SSD 的 IOPS 上限就是这么多。如果想让并发能力再往上走，换更好的 NVMe SSD 或者 RAID 卡才是更直接的方案。

经验：做基准测试时不要只盯着最高 TPS，要找到“延迟和吞吐量的平衡点”。在实际生产运维中，我更关注 95th 延迟不超过 100ms 的情况下能支撑多少并发，这个指标才真正决定了用户体验。

5. 常见问题与排查技巧实录

5.1 初始化失败：libaio 依赖问题

第一次在新机器上做二进制安装，执行mysqld --initialize时报错：

mysqld: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory

这个报错信息其实非常直白，就是缺 libaio 动态库。很多精简安装的系统默认不带这个库，装上就好：

yum install -y libaio

提醒：如果你用的是 Ubuntu/Debian 系列，对应的包名是libaio1，apt install -y libaio1即可。

5.2 远程客户端连接失败：认证插件问题

MySQL 8.0 默认的认证插件是caching_sha2_password，但是像老版本的 PHP mysqli、一些旧的 Navicat 版本、部分 Python 库如果不支持这种认证方式，连接时就会报错：

ERROR 1251: Client does not support authentication protocol requested by server; consider upgrading MySQL client

这个报错不是因为密码错误，而是认证方式对不上。刚才创建测试账号时已经通过在CREATE USER或者ALTER USER里手动指定IDENTIFIED WITH mysql_native_password绕过了这个问题。如果你用的客户端工具比较旧，建账号的时候加上这段就行：

CREATE USER 'sbtest'@'%' IDENTIFIED WITH mysql_native_password BY 'sbtest_pass';

不过再次提醒一下，mysql_native_password始终是过渡方案，长远建议还是升级客户端到支持caching_sha2_password的版本。

5.3 sysbench 连接被拒绝

跑 sysbench 时如果报：

ERROR: Unable to connect to MySQL server, check if the MySQL server is running and you have network connectivity. Error: Can't connect to MySQL server on '127.0.0.1' (111)

优先排查两部分：一是 MySQL 有没有启动、3306 端口是否在监听：

ss -lntp | grep 3306

二是确认连接账号有没有远程访问权限。我用 root 跑压测的时候就在这卡过，root 默认只允许 localhost 登录，用 127.0.0.1 去连反而报错。后来建了sbtest账号指定'%'主机域才解决。

5.4 sysbench 报错 table already exists

如果在 prepare 中途中断过，或者上一次压测完没有执行 cleanup，第二次 prepare 时就会遇到大量：

FATAL: Table 'sbtest1' already exists

这个其实不怪 sysbench，是上次残留的数据没有清理干净。正确做法是先跑一次：

sysbench /usr/share/sysbench/oltp_read_write.lua \ --mysql-host=127.0.0.1 \ --mysql-port=3306 \ --mysql-user=sbtest \ --mysql-password=sbtest_pass \ --mysql-db=sbtest \ cleanup

cleanup 会把 sysbench 创建的所有表都删掉，然后再重新 prepare。

5.5 压测结果忽高忽低：先查系统层面干扰

有一轮压测数据特别怪异，TPS 从 3000 掉到 800 又弹回来，呈现明显的周期性波动。排查的时候发现两个可能原因，一是机器上还有其他进程在跑定时任务，占用了大量 IO 和 CPU；二是在测试过程中又去手动运行了一些查询，干扰了压测数据。之后我把压测时的系统负载控制住，单独跑一台干净的机器，数据就稳定多了。

另外，如果是虚拟机或者云主机，还要注意宿主机上的邻居是不是在“抢占”资源，特别是 IO 和网络这类隔得很远的资源。压测时尽量选择业务低峰期，关掉不必要的服务，让环境干扰降到最低。

5.6 打开文件数限制

压测过程中曾经出现过 mysqld 日志里报Too many open files，这通常是因为系统的ulimit限制太低。MySQL 是高并发 IO 应用，需要同时打开大量文件句柄，默认 1024 远远不够。

在/etc/security/limits.conf里增加配置（需要重新登录 shell 才生效）：

mysql soft nofile 65535 mysql hard nofile 65535

同时确认 systemd 服务文件里没有覆盖这个限制，如果有需要也可以直接在 service 文件里加：

LimitNOFILE=65535

5.7 压测结果解读容易犯的误区

很多人压测完只看一个 TPS，忽略了延迟分布和资源利用率，这是很容易误判的。我总结几个实际的解读心得：

• TPS 高但是 95th 延迟也很高：说明吞吐量上去了但系统已经出现排队，用户体验在恶化，这种状态其实不适合线上业务；
• QPS 高但磁盘 IO 已经打满：说明瓶颈在存储层，要么降低写放大，要么提升磁盘能力，单靠 MySQL 参数调整已经作用有限；
• 每次都跑出的数据都不一样很正常：基准测试追求的是“可复现的相对对比”，同一条命令至少跑三次取中间值或平均值，别拿一次数据当结论。

如果只想快速求一个参考值，可以把三条命令（只读、读写、写入）各跑 3 遍，取中间值记入结果表，再结合top、iostat和vmstat的记录综合判断。

6. 后续实战中的一点个人体会

6.1 从压测到生成环境的参数迁移

基准测试做完，调优参数也验证过了，但千万不要直接把压测机的配置搬到生产。压测环境的数据量、并发模型和真实业务有本质差异。

我习惯的做法是先记录压测时的关键指标，比如 16 线程下的 TPS 和 95th 延迟，然后在生产环境灰度验证时逐步把innodb_buffer_pool_size、innodb_log_file_size等参数调上去，每调一个观察一段时间，确认没有副作用再动下一个。特别是innodb_flush_log_at_trx_commit这种和数据安全强相关的参数，改之前必须和团队确认对数据丢失风险的容忍度。

6.2 监控体系最好在压测前就搭好

压测的价值在于发现瓶颈，但发现瓶颈的前提是能看到瓶颈在哪里。裸跑 sysbench 只能看到数字，看不到 CPU 怎么分布、IO 等待有多高、慢查询日志里有没有异常，这时候就缺一套监控体系来辅助判断。

建议在压测之前至少先把这几项监控跑起来：Prometheus + mysqld_exporter这种通用监控方案可以看数据库内部状态；Percona Monitoring and Management能看更细节的 InnoDB 层指标；如果环境比较轻量，临时用top、iostat、vmstat盯着系统资源也行，只要能积累数据，压测完分析就是有据可查的，而不是在猜。

6.3 最后补一个小技巧

sysbench 的默认 lua 脚本里的oltp_read_write混合了主键查询、范围查询、更新、插入和删除，但它的事务模型和真实业务差距不小。如果你想模拟自己的业务 SQL，可以自己写 lua 脚本，核心格式就是一个thread_init函数一个event函数，然后在event里写你要执行的 SQL。虽然没太多语法要求，但真正自定义之后压测结果对你自己业务的参考价值会大幅提升。

这次的安装和压测经验就聊到这里，希望你能少走点弯路。还是那句老话，纸上得来终觉浅，绝知此事要躬行，照着做一遍，比看十篇文档都管用。