自从使用docker以来，就经常听说MySQL数据库最好别运行在容器中，性能会损失很多。一些之前没使用过容器的同事，对数据库运行在容器中也是忌讳莫深，甚至只要数据库跑在容器中出现性能问题时，首先就把问题推到容器上。

那么到底会损失多少，性能损失会很多吗？

装了两个MySQL，版本都是8.0.34。一个用官网二进制包安装，另一个用docker hub的MySQL镜像安装。两个MySQL都运行在同一台机器，但不同时运行，先后运行测试。测试工具用的sysbench，运行在另一台机器。

提前声明：测试流程比较简单，只是用sysbench测了混合读写场景，测试次数也较少，不具有权威性。感兴趣的话，可以自行完善测试流程。

如果对后文没什么兴趣，这里也可以直接说结论：单表百万级以下时，非容器和容器的性能差异并不多。单表千万级时，容器MySQL大概会损耗10% ~ 20%的性能。

应用	版本	备注
Debian	12.0	操作系统。4C16G
docker	20.10.17	容器运行时
MySQL（非docker）	8.0.34	基于官方的二进制安装包
MySQL（docker）	8.0.34	使用docker hub的镜像
sysbench	1.0.20	压测工具

MySQL配置

MySQL安装后创建测试用的sysbench用户和sysbench数据库，调整innodb_buffer_pool_size为2GB。

docker容器的网络配置为bridge，挂载数据目录。

sysbench命令

• 准备数据

sysbench --db-driver=mysql --mysql-host=192.168.3.21 --mysql-port=3306 --mysql-user=sysbench --mysql-password=123456 --mysql-db=sysbench --table_size=10000000 --tables=20 --threads=4 oltp_read_write prepare

• 执行测试

sysbench --db-driver=mysql --mysql-host=192.168.3.21 --mysql-port=3306 --mysql-user=sysbench --mysql-password=123456 --mysql-db=sysbench --time=300 --threads=8 --report-interval=10 oltp_read_write run

• 清理测试数据

sysbench --db-driver=mysql --mysql-host=192.168.3.21 --mysql-port=3306 --mysql-user=sysbench --mysql-password=123456 --mysql-db=sysbench --table_size=10000000 --tables=20 --threads=4 oltp_read_write cleanup

测试结果

单表1000w数据，20张表，测试4次。

MySQL运行环境	测试序列	总SQL执行数	每秒SQL数	每秒事务数	延迟时间（平均）	延迟时间（95%）
非容器	1	3798093	12658.84	632.78	12.64	20.00
非容器	2	3914578	13047.91	652.28	12.26	17.01
非容器	3	4059867	13531.79	676.46	11.82	15.55
非容器	4	3772390	12574.00	628.58	12.72	19.65
容器	1	3230678	10768.41	538.28	14.86	26.20
容器	2	3538573	11794.68	589.62	13.57	19.29
容器	3	3567943	11892.56	594.50	13.45	17.63
容器	4	3616204	12053.53	602.58	13.27	17.32

平均统计：

MySQL运行环境	总SQL执行数	每秒SQL数	每秒事务数	延迟时间（平均）	延迟时间（95%）
非容器	3,886,232	12,953.14	647.53	12.36	18.05
容器	3,488,350	11,627.3	581.25	13.79	20.11
环比	-10.24%	-10.24%	-10.24%	+11.57%	+11.41%

在测千万级数据量之前，测过几轮几十万级的数据量，非容器和容器版的MySQL并没有多大区别。当数据量逐渐增多时，差异就愈加明显。目前测单表1000w已经出现10%左右的性能损耗，如果单表数据继续增大，性能损耗应该也会更多。