背景介绍： 阿里的mysql服务确实很贵，而且任务编排服务下架开始推收费服务来替代，于是决定自建mysql。 由于服务器是ubuntu24直接安装原来的mysql5.7.4有兼容问题，mysql8又不兼容之前的服务部分sql语句，最终选择docker安装mysql5.7。 数据迁移与导入: mysqldump数据导出的时候发现部分日志表异常庞大，于是用了--ignore="数据库.忽略的表"，大致语句 <code> mysqldump -h远程地址 -u数据库账户名 -p数据库密码 --ignore-table=database_name.table_name database_name > backup.sql </code> -要限定where条件则加上了 --where="datetime>yyyy-mm-dd"，后来发现--where作用域是所有表，所以只能把有条件限定的表单独导出。 -如果触发器报错要加上--skip-triggers 导出数据还算顺利，导入的时候发生了错误。 导入命令: <code> mysql -u数据库账户名 -p数据库密码 数据库名 < backup.sql </code> 结果报错ERROR 2006 (HY000) at line 896: MySQL server has gone away。开始以为数据太大了服务崩溃，因为sql数据有5个多G，于是尝试先导入一些小的表，报错依然存在。 改为mysql -u数据库账户名 -p数据库密码 登录到本地数据库内然后执行sorce backup.sql 结果提示ERROR 1231 (42000): Variable 'time_zone' can't be set to the value of 'NULL'，问了下AI跟我说是导出的数据头部信息问题，折腾了好半天一直不成功。 找到问题： 由于删光了导出的sql额外信息只留了insert语句报错依然存在，开始怀疑是数据本身的问题。最终发现由于项目早期数据结构设计不合理，有个超大blob字段单个数据超过了30M引发了一系列问题。 解决方案： 修改了数据库配置文件 mysql/conf/mysqld.cnf，加了max_allowed_packet=256M，重启数据库后导入成功！ 另外发现mysql -u数据库账户名 -p数据库密码 数据库名 < 数据库文件.sql 的导入方式比登录数据库后用sorce 数据库文件.sql的方式快很多。 导出的时候加上 --set-gtid-purged=off参数可以减少一些奇怪的额外信息导出，避免奇怪报错。 导出的时候加上 -d参数可以只导出表结构不导出数据，加上 -t 则只导出数据不导出建表语句。 还有一个需要注意的是，docker exec 执行mysql容器数据导入导出的时候要加-i参数，不是-it。完整语句应该类似: docker exec -i 容器名称 mysqldump -u账户名 -p密码 --single-transaction --quick 数据库名 表名 > 自定义导出文件名.sql 由于 > 符号执行优先级问题，最终数据是导出在宿主机的而不是容器内。