1. MySQL 8.0值得关注的几个变化写这篇博文之前我刚好帮一个朋友处理了他那边测试环境MySQL性能摸底的需求。他的场景很典型新购置了几台物理服务器打算从旧版本数据库迁移到MySQL 8.0但团队里没人正经跑过基准测试对8.0的性能心里没底。安装、初始化、压测、看结果这一套流程走下来踩了一些坑也沉淀了不少经验。先说说为什么选MySQL 8.0而不是继续用5.7。这个问题的答案直接决定了后续安装和测试的路线。我自己的看法是如果项目是从零开始、没有历史包袱那8.0应该是当下的默认选项。官方对5.7的延伸支持已经进入倒计时这意味着安全补丁和关键bug修复会越来越滞后对生产环境是实打实的风险。从功能层面看8.0做了两个特别影响日常使用的改动。第一个是默认字符集变成了utf8mb4。这意味着建表时不用再显式指定CHARSETutf8mb4从源头避免了emoji、生僻字存不进去的尴尬问题。第二个是默认身份认证插件换成了caching_sha2_password。老版本的mysql_native_password在8.0里降级成了兼容选项。这个变化对老客户端影响很大比如Python 3.x里某些旧版本的pymysql、Java里老版本的Connector/J如果不做兼容处理连库时直接报认证失败。还有一些容易被忽略但实际影响操作的细节系统表结构和数据字典全面重构。mysql.user表不再直接存储密码散列用户权限信息从数据字典读取导致以前那种改密码字段的骚操作彻底失效。想重置密码只能走官方推荐的ALTER USER语法或skip-grant-tables流程。参数命名更规范。比如query_cache_size被彻底移除因为查询缓存这个特性在8.0里被删掉了。同步binlog相关的expire_logs_days改名为binlog_expire_logs_seconds很多从5.7迁移过来的配置文件直接启动失败报Unknown system variable原因就在这。InnoDB的性能优化。底层改了预读策略、自适应哈希索引的触发逻辑、redo log的子信道并发写入等。官方自己的测试数据显示高并发读写场景下吞吐量比5.7有明显提升但具体能提升多少还得看硬件和实际负载特征这也是我们做基准测试的原始动力——不看自己机器上的真实数据心里永远没底。这也引出了这篇文章的主题从零开始在一台干净的Linux服务器上装好MySQL 8.0完成初始化配置然后分别用数据库圈子里用得最多的两个基准测试工具把机器的性能底摸清楚最后教大家如何看穿测试报告里的数字判断机器真正的负载能力。2. 安装方式对比与选型建议MySQL 8.0的安装方式非常多官方提供二进制tar包、RPM包、APT源第三方还提供Docker镜像。对生产环境而言我的建议从高到低排序是操作系统官方源、MySQL官方Yum/Apt源、二进制tar包。Docker方式不是不能用但至少不适合作为物理机部署的主力方案性能和运维习惯上都有一些别扭的地方。拿我这次实际操作的环境举例一台CentOS 7.9的机器8核16线程CPU、32GB内存、两块NVMe SSD做软RAID 1。这个配置不算高档但很符合一般中型业务测试环境的底子跑基准测试具备一定的参考意义。2.1 操作系统自带源与官方源的区别CentOS 7自带的AppStream源里通常只有MySQL 5.7在CentOS 8上才有MySQL 8.0的rpm包。如果你不想折腾又想用8.0最省事的办法是配置MySQL官方Yum仓库。配置过程就三步下载官方仓库rpm包安装该rpm包它只负责写入Yum源定义不实际安装MySQL用yum install mysql-community-server装服务端官方源的好处是版本跟进快安全补丁发布后能第一时间拉取到。社区版和企业版二进制兼容将来如果购买了商业订阅切换也很平滑。缺点是官方源在国内某些网络环境下速度不太稳定这时候可以考虑换国内镜像。2.2 二进制tar包方式适合特殊场景的灵活方案为什么还需要单独讲二进制tar包因为有些场景根本没法走Yum比如内网环境与外界隔离yum源拉不通比如系统是精简版没有配置任何第三方仓库再比如你想同时跑多个MySQL实例不同版本独立部署。tar包的安装逻辑本质上就是解压即用。官网下载mysql-8.0.x-linux-glibc2.12-x86_64.tar.xz解压到指定目录然后手动创建数据目录、初始化、配置启动。整个过程不依赖系统的rpm数据库完全可控。我第一次尝试这个方案的时候就遇到一个典型的坑CentOS 7自带的glibc版本是2.17官方README里写的glibc2.12说明最低兼容到2.12但实际运行中还是提示缺少libaio和libnuma两个动态库。原因在于8.0的二进制默认链接了libaio不装的话mysqld --initialize直接报错。2.3 我推荐的安装路径如果你跟着这篇文章走环境是CentOS 7.x或Rocky Linux 8.x建议直接采用官方Yum源方案步骤最少、依赖问题最少、最接近生产环境操作的普遍习惯。我这次实际用的就是官方Yum源。补充一个在新装系统上特别实用的小技巧装完系统后先执行一次yum install -y epel-release把EPEL源加上再安装MySQL官方源。EPEL里有个叫percona-toolkit的包后面做测试和排查时经常用到提前装好省得后面临时补。3. 安装全流程与初始化中的关键细节3.1 用官方Yum源完成服务端部署这部分的命令序列我再完整走一遍并标注每一步的意图# 1. 下载并安装MySQL官方Yum仓库配置文件 wget https://repo.mysql.com/mysql80-community-release-el7-7.noarch.rpm rpm -ivh mysql80-community-release-el7-7.noarch.rpm # 2. 检查仓库是否生效 yum repolist enabled | grep mysql # 3. 安装服务端这一步会自动安装mysql-community-client等依赖 yum install -y mysql-community-server # 4. 启动服务并设置开机自启 systemctl start mysqld systemctl enable mysqld装完以后用systemctl status mysqld或者直接mysql -uroot -p登录会发现问题8.0首次启动时会自动生成一个临时密码位置在/var/log/mysqld.log里用grep temporary password可以捞出来。这是MySQL 8.0做得比较贴心的设计避免安装后空密码裸奔。拿到的临时密码先别急着用因为默认的密码策略比较严格至少8位、必须包含大小写字母、数字和特殊字符。第一次登录后系统会强制你先改密码否则任何操作都做不了。mysql -uroot -p # 输入临时密码 ALTER USER rootlocalhost IDENTIFIED BY Your_Strong_Passwd_2024!;3.2 数据目录初始化的两种方式对比官方Yum源安装路径下数据目录默认是/var/lib/mysql服务启动时如果发现目录为空会自动完成初始化。这种方式叫自动初始化对新手最友好但对生产环境来说不够精细。如果想自己控制初始化过程可以用手动初始化方式# 先停止服务清空数据目录注意备份 systemctl stop mysqld rm -rf /var/lib/mysql/* # 手动初始化--user指定运行用户--basedir指定安装目录 mysqld --initialize --usermysql --basedir/usr --datadir/var/lib/mysql两种方式生成的数据字典结构完全一样差异主要在于对初始化日志的理解——手动方式可以更清楚地看到初始化过程有没有警告。我遇到过一次因为/etc/my.cnf里配了过时的参数导致初始化失败的情况手动方式下错误信息直接打印到终端排查起来比翻日志快得多。同时也建议在初始化时用--log-error参数把错误日志单独指到自己的目录别混在系统日志里。3.3 刚装完必调的5个参数安装完成、能登录、能建库建表这只是能用的状态。好用还需要在配置文件/etc/my.cnf里调几个参数。这些参数如果装完不动跑基准测试的时候性能会打很大折扣。下面是我这次的最终配置标注了每个参数的用途[mysqld] # 数据文件路径 datadir/var/lib/mysql socket/var/lib/mysql/mysql.sock # InnoDB缓冲池大小决定热点数据的装载能力设为物理内存的60%-70% innodb_buffer_pool_size20G # 日志文件大小8.0里redo log默认由innodb_log_file_size控制 innodb_log_file_size1G # 事务提交刷盘策略追求最高性能可设为2但存在崩溃丢1秒数据风险 innodb_flush_log_at_trx_commit2 # 连接数上限压测并发数高时这个值太大会导致连接数不足 max_connections2000 # 默认字符集与排序规则 character_set_serverutf8mb4 collation_serverutf8mb4_0900_ai_ci # 关闭符号链接安全加固 symbolic_links0innodb_buffer_pool_size为什么这么重要简单理解InnoDB读取数据时优先在内存里找找不到才去磁盘内存命中率直接决定随机读的性能。缓冲池设置过小热点数据频繁被淘汰磁盘IO会成为瓶颈。一次压测下来如果iostat里%util一直满载而TPS上不去八成是缓冲池不够用或者没预热。这里补充一个细节innodb_log_file_size在8.0里虽然还能用但官方更推荐用innodb_redo_log_capacity来管理redo log总容量默认值是100M线上环境建议调到1G以上。innodb_flush_log_at_trx_commit这个参数值得单独讲讲。它控制的是事务提交时redo log的刷盘策略。取值1意味着每次事务提交都强制把日志刷到磁盘最安全但最慢适合对数据安全要求高的场景取值2意味着先写入操作系统缓冲区每秒刷一次盘性能好很多但数据库进程崩溃时可能丢最近1秒的已提交事务取值0则是交给系统自己决定刷盘时机性能极好但崩溃丢失窗口更大。基准测试场景下用2比较合理既贴近很多互联网生产环境的实际选择又能反映相对真实的性能上限。如果你压测时用的是默认值1得到的TPS数字会明显偏低不能作为容量规划依据。改完配置要重启服务systemctl restart mysqld重启后可以用SHOW VARIABLES LIKE innodb_buffer_pool_size;确认参数生效。生产环境加参数时还有一个细节——最好先SET GLOBAL动态调整观察一段时间再写进配置文件避免改错导致实例起不来。按上面配置测试环境重启时出现过一次失败排查后是my.cnf里配了不存在的query_cache_size参数导致的改成去掉后启动正常。MySQL 8.0删除的特性参数配置文件里残留了就会报启动失败所以从5.7迁移配置时一定要清理过时参数。4. 基准测试前的环境检查与测试库准备安装和基础参数调完之后可以开始做准备工作了。这一步很多人会跳过我觉得是不对的。测试环境没校准压测出来的数字是垃圾。这里的校准不是特别玄乎的东西就是确认操作系统层面的几个状态。用Linux的vmstat、iostat、perf简单看一眼系统有没有异常负载之前没跑过业务的测试机上这一步问题一般不大。更关键的是文件系统挂载参数。MySQL默认数据目录在/var/lib/mysql如果这是一个独立分区且没加noatime挂载参数每次读都会触发atime更新增加额外的IO开销。查看方式df -h /var/lib/mysql mount | grep /var/lib/mysql没有noatime的话在/etc/fstab里加上重启生效。操作不复杂但很多人确实不知道等压测完对比别人同配置机器的数字发现比人家低到头来才发现是这个细节很浪费时间。4.1 创建压测专用账号与数据库MySQL的root账号权限太大压测时最好单独建一个专用账号一方面防止误操作另一方面也贴近生产环境的最小权限原则CREATE DATABASE sbtest DEFAULT CHARACTER SET utf8mb4; CREATE USER sbtest% IDENTIFIED BY Sbtest_2024!; GRANT ALL PRIVILEGES ON sbtest.* TO sbtest%; FLUSH PRIVILEGES;注意到我特意指定了utf8mb4字符集。MySQL 8.0默认就是它这里再显式指定一遍是为了保险同时也能排除字符集不同导致的排序开销差异。有前辈做过测试latin1和utf8mb4在大量字符串排序场景下性能差距能到10%以上测试库既然是为了测性能就不该让字符集成为干扰因素。4.2 压测工具的选型逻辑市面上最常见的MySQL压测工具有两个sysbench和mysqlslap。sysbench是开源界的事实标准由Percona团队长期维护支持自定义lua脚本、多线程压测、多种测试模式oltp_read_only、oltp_read_write、oltp_write_only等能输出非常细致的TPS、QPS、延迟分位数数据做容量评估和硬件摸底都靠它。Percona的分支版本还额外支持从测试结果里自动生成图表报告。mysqlslap则是MySQL官方自带的客户端工具装完mysql-community-client就有优点是零额外安装成本能模拟并发加载但功能比较基础输出维度少不适合做精细化压测和分析。我的建议性能摸底以sysbench为主mysqlslap作为补充验证两个工具的结论交叉比对。原因很简单sysbench的报告更贴近生产环境真实负载特征mysqlslap更像是一个冒烟测试工具。等下我会给出两个工具的具体用法和结果解读。4.3 sysbench的安装sysbench的安装我用的是EPEL源yum install -y epel-release yum install -y sysbench sysbench --version版本是1.0.x就够用了。注意某些镜像源的sysbench版本可能比较旧如果输出的--version是0.4.x建议直接卸载后从源码编译不然很多参数对不上。0.4和1.0的语法差别非常大网上很多教程是0.4的写法照着抄容易翻车。5. 用sysbench跑正式的基准测试5.1 数据准备阶段的参数设计压测的第一步是准备测试数据。sysbench用oltp_common脚本在目标库里生成指定数量的表和指定行数的数据。我的测试配置如下sysbench /usr/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest_2024! \ --mysql-dbsbtest \ --tables10 \ --table-size1000000 \ --threads16 \ --time300 \ --report-interval5 \ prepare参数含义拆解--tables10 --table-size1000000生成10张表每表100万行。数据量不是越大越好太大会让prepare阶段耗时过长太小又可能全部命中内存测不出磁盘真实能力。1000万行在32GB内存的机器上配合20G缓冲池是一个相对合理的量级。--threads16压测线程数通常建议等于或略大于CPU核心数。准备数据阶段也用16线程是为了和后续压测保持一致节奏。--time300压测持续时间300秒。时间太短预热不充分数据不稳定太长浪费测试时间且容易把磁盘写到过热。5分钟是我习惯的中庸值。--report-interval5每隔5秒打印一次实时统计可以看到性能是否波动、有没有周期性抖动。prepare过程会跑一阵1000万行普通机械盘可能要十几分钟NVMe上会快很多。如果中途报table already exists说明之前有残留可以用sysbench ... cleanup清理后重新prepare。5.2 正式压测与输出解读数据准备好以后把prepare改成run就开始正式压测sysbench /usr/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest_2024! \ --mysql-dbsbtest \ --tables10 \ --table-size1000000 \ --threads16 \ --time300 \ --report-interval5 \ --rand-typeuniform \ run这里我额外指定了--rand-typeuniform意思是随机数的分布模式采用均匀分布。sysbench默认是special模式会让热点集中在少量数据行上测出来的TPS会虚高。改成uniform更接近真实业务的随机访问特征。如果你测试的是偏向最近热数据的业务可以试--rand-typepareto模拟二八分布两种结果差异很大选型时要明白自己到底在模拟什么。压测结束后的输出是下面这个结构SQL statistics: queries performed: read: 3258406 write: 930974 other: 465487 total: 4654867 transactions: 232741 (776.00 per sec.) queries: 4654867 (15519.80 per sec.) ignored errors: 0 (0.00 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 300.0242s total number of events: 232741 Latency (ms): min: 0.97 avg: 20.60 max: 391.42 95th percentile: 31.58 sum: 4794652.62 Threads fairness: events (avg/stddev): 14546.3125/344.63 execution time (avg/stddev): 299.6656/0.05重点看三个指标transactions (776.00 per sec.)TPS每秒处理的事务数。这台8核16线程、NVMe盘、20G缓冲池的机器在16线程混合读写下跑到776 TPS属于正常偏好的水平。queries (15519.80 per sec.)QPS每秒查询次数。读写混合模式下QPS和TPS的比例关系取决于每条事务包含的SQL数量这个值也可以作为后端应用容量规划的一个参考。Latency 95th percentile: 31.58ms95%请求的延迟都低于31.58ms。这代表绝大多数请求的响应体验比平均值更有参考价值平均值容易被极端值拉偏。可以从两个角度判断这台机器的性能好坏。一是纵向看趋势多次压测的TPS是否稳定波动大说明系统存在不稳定因素比如IO抖动或CPU降频。二是横向看基准同样的机器装MySQL 5.7并调相同参数跑同一套测试得到的数字对比。8.0相对5.7在混合读写场景粗略来看通常能提升15%-30%。但是这句话仅供参考每台机器、每个负载特征都不同只有自己跑出来的数据才是决策依据。5.3 阶梯式并发测试的意义上面那次只测了16线程这一个点。生产环境往往需要知道系统在8线程、32线程、64线程下的表现才能找到最佳并发度区间。通常的处理方式是从小到大递增跑每次只改--threads参数其他保持一致for t in 8 16 32 64; do sysbench /usr/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-usersbtest \ --mysql-passwordSbtest_2024! \ --mysql-dbsbtest \ --tables10 \ --table-size1000000 \ --threads$t \ --time120 \ --report-interval5 \ --rand-typeuniform \ run done测试中每完成一次run建议用cleanupprepare重新准备数据不然前面测试留下的递增/递减索引页碎片会影响后续测试的公平性。确保每次压测的数据页都处于同一状态结果才具有可比性。把TPS和平均延迟以并发数为横轴画成曲线你会看到一种典型形态并发数上升初期TPS快速增长达到一个临界点后增速放缓甚至下降延迟开始明显抬升。那个拐点就是这台机器在实际负载下最合理的并发承受区间。配套压测过程中可以另开一个终端跑top和iostat对照CPU使用率和磁盘IO负载可以更清楚地看出瓶颈到底在哪个维度。6. 结果解读、瓶颈排查与值得收藏的优化清单6.1 压测结果不理想时先别急着调参数很多人在压测结果不理想时第一反应是继续往my.cnf里加参数我的建议是先确认瓶颈在哪再动手调参否则可能白忙活。排查顺序如下CPU维度跑top看us和sy的比例。sy内核态开销过高说明系统调用、上下文切换太频繁常见原因是连接数过多或网络中断频繁。内存维度跑free -h看available是否充足。如果频繁swap缓冲池配置再大也白搭。磁盘维度跑iostat -x 1看%util和await。%util持续100%但TPS不高说明磁盘跟不上await高但%util不高可能存在IO队列排队问题。网络维度本机压测时基本不涉及但跨机器压测时iftop观察网卡流量是否打满。我用这套思路排查过一次某次在8核VM上压测TPS始终上不了500top显示sy占用超过60%。最后发现是虚拟机CPU资源被限制导致的不是MySQL配置问题。这类环境瓶颈如果不检查调参数调一晚上也调不出来。6.2 MySQL参数优化的常见误区和有效手段推荐几个在8.0里效果显著且不容易踩坑的优化方向第一个方向调整innodb_io_capacity和innodb_io_capacity_max这两个参数控制InnoDB后台刷脏页的IO速率上限。默认值是200而现在的NVMe SSD轻松能到几千甚至上万IOPS。刷脏页速率不够会导致脏页堆积最终在前台产生卡顿效应表现为压测中延迟突然飙高。建议把innodb_io_capacity设为磁盘IOPS的80%左右innodb_io_capacity_max设为上限值。用fio之类的工具先测一下磁盘基准IOPS再填参数别拍脑袋。第二个方向合理设置innodb_buffer_pool_instances这个参数决定缓冲池被分成多少个实例每个实例独立管理内存块能减少并发访问时的内部锁竞争。建议值是innodb_buffer_pool_size / 1G比如20G缓冲池可以分成8个实例官方上限是64。压测验证一下高并发下有时能带来5%左右的提升。第三个方向暂时关闭或调低binlog相关开销如果测试环境不要求数据恢复和主从同步可以先把sync_binlog0和innodb_flush_log_at_trx_commit2搭配使用能显著提升读写TPS。但这只适合测试环境或对数据安全要求极低的场景。生产环境永远优先考虑数据不丢性能差那么一点是可以接受的。6.3 用mysqlslap做快速冒烟验证sysbench跑完以后可以再用mysqlslap补充验证一轮。mysqlslap的优势在于它是官方自带的不用额外装东西语法也简单mysqlslap --host127.0.0.1 --port3306 --usersbtest --passwordSbtest_2024! \ --concurrency32 \ --iterations10 \ --number-int-cols5 --number-char-cols5 \ --auto-generate-sql \ --engineinnodb \ --number-of-queries10000这条命令的意图是模拟32个并发连接执行总共10000条自动生成的查询重复10轮取汇总数据。输出会给出每轮的平均耗时。mysqlslap的脚本逻辑比sysbench简单很多测试出的数据仅可作参考。一个实操技巧把sysbench跑出来的TPS作为Capacity Planning数值把mysqlslap的结果当作确认没有明显配置错误的冒烟测试。两者结合使用既能评估极限性能又能快速判断配置是否健康。6.4 我留下的一个扩展建议压测完你以为就结束了吗其实还有一件事值得做——收集MySQL本身的内部状态指标。压测过程中开另一个会话执行SHOW GLOBAL STATUS LIKE Innodb%;重点关注Innodb_buffer_pool_read_requests缓冲池逻辑读次数和Innodb_buffer_pool_reads物理读次数两者的比例就是缓冲池命中率。高命中率说明内存配置合理低命中率说明innodb_buffer_pool_size偏小或者测试数据量太大。这个指标比单纯看TPS更能说明你的配置和你的数据是否匹配。7. 遇到过的典型报错与处理方法最后把这次安装和压测中遇到的几个典型报错记录下来给同行们做一个排查索引。这些错误都很有代表性遇到了能快速定位。7.1 认证插件导致的客户端连接失败错误信息Authentication plugin caching_sha2_password cannot be loaded场景老版本客户端mysql-connector-java 5.x、pymysql 0.9.x等连接MySQL 8.0时报错。原因8.0默认的认证插件是caching_sha2_password老客户端不支持。处理办法建议优先升级客户端库版本。如果实在无法升级可以在MySQL里将该用户的认证插件修改为老式插件ALTER USER sbtest% IDENTIFIED WITH mysql_native_password BY Sbtest_2024!;但要注意这是向后兼容的操作能不用就不用。8.0后续版本对mysql_native_password的兼容迟早要收紧趁早升级客户端是正道。另外即使升级了客户端也要确认连接串里没有写死useSSLfalse之类的旧选项SSL相关的握手失败报错也很常见。7.2 内存配置过高导致启动失败错误信息InnoDB: Cannot allocate memory for the buffer pool场景把innodb_buffer_pool_size配置得很大比如机器只有8G内存却配了16G。原因MySQL实例在初始化缓冲池时需要一次性申请对应大小的内存映射内存不足直接启动失败。处理办法按物理内存的60%-70%规划即可比如8G内存配置5G缓冲池。另外注意如果机器上还跑了其他应用比如Java服务或Redis要预留它们的空间。7.3 大事务提交时磁盘满导致崩溃错误信息InnoDB: Error number 28 means No space left on device场景压测过程中写入量巨大数据目录所在分区被写满。原因测试数据加上redo log、binlog、undo log把磁盘写爆了。处理办法压测前务必确认df -h /var/lib/mysql至少留有测试数据量2倍以上的剩余空间。另外注意8.0的redo log可以动态调整容量同时确保binlog有合理的max_binlog_size限制和expire_logs_days清理策略别让日志无限增长把磁盘挤爆。7.4 超过最大连接数限制错误信息Too many connections场景压测并发数超过max_connections。处理办法测试前把max_connections调大比如2000同时留意操作系统的ulimit -n文件描述符限制也要同步抬高否则MySQL进程会因为句柄不够而提前拒绝连接。检查命令ulimit -n # 看当前限制 ulimit -n 65535 # 临时调高或写入/etc/security/limits.conf8. 写在最后的一点体会整个安装、配置、压测流程走完我个人最大的感受是MySQL 8.0的部署门槛其实比5.7更低安装流程不会更复杂真正的难度在于新特性带来的心智模型变化。字符集、认证插件、参数体系这些默认值的变化会让一些老手在初次接触时觉得不顺手但适应之后会发现它其实更规范、更安全。基准测试这件事本质上是在回答一个问题我的机器和我的MySQL配置到底能扛住多少业务量。这台测试机最终在16线程混合读写下稳定跑到776左右的TPS95%延迟31ms多对这个配置级别的物理机来说是个健康的数据。如果你照着本文的流程在自己的机器上跑得到的数字和我的有出入先不要怀疑操作出了问题——检查硬件配置、参数调优、磁盘类型逐一对比下来答案自会出现。最后提醒一个很多教程不会写到的细节压测结束后记得跑一次sysbench ... cleanup把测试数据清理干净别把一堆sbtest表留在库里影响后续使用。如果你打算把测试数据库保留下来做调优的对照组那也要有个清晰的归档和命名习惯别等三个月后跑业务发现库里有几千万行压测垃圾数据那滋味可不好受。数据库性能摸底这种事情没有标准答案只有相对合理的数据。希望这篇记录能帮你少踩几个坑省下排查的时间静下心来好好分析那一串串数字背后的真实含义。