MariaDB使用mysqldump导出含VIRTUAL虚拟列表格时报连接中断错误求助

有一个大小约4GB的数据库，使用版本为Ver 10.19 Distrib 10.4.21-MariaDB, for Linux (x86_64)的MariaDB版mysqldump工具导出时，每次执行到AffiliateProgramsCampaigns表就失败，报错信息如下：

mysqldump: Couldn't execute 'SHOW CREATE TABLE `AffiliateProgramsCampaigns`': Lost connection to MySQL server during query (2013)

经过测试确认问题根源是该表包含VIRTUAL虚拟列，移除该列后即可正常完成导出。检索相关资料未找到同类报错，添加--verbose参数执行导出也未得到更多有效信息。
额外特征：报错出现在SHOW CREATE TABLE执行阶段，但仅导出该库表结构时一切正常；手动在phpmyadmin、命令行mysql界面执行该SHOW CREATE TABLE语句均可正常返回，切换root等不同用户执行导出操作仍会在同一位置报相同错误。

1. --verbose模式下的导出日志末尾内容：

-- Retrieving view structure for table ActionLogReferences...
-- It's base table, skipped
-- Retrieving view structure for table ActionLogs...
-- It's base table, skipped
-- Retrieving view structure for table AffiliatePrograms...
-- It's base table, skipped
-- Retrieving view structure for table AffiliateProgramsCampaigns...
mysqldump: Couldn't execute 'SHOW CREATE TABLE `AffiliateProgramsCampaigns`': Lost connection to MySQL server during query (2013)

2. 问题表的CREATE TABLE语法：

CREATE TABLE `AffiliateProgramsCampaigns` (
 `AffiliateProgramsCampaignId` bigint(20) NOT NULL AUTO_INCREMENT,
 `Name` varchar(255) NOT NULL,
 `Description` tinytext NOT NULL,
 `StartDate` datetime NOT NULL,
 `EndDate` datetime NOT NULL,
 `IsActivated` tinyint(1) NOT NULL DEFAULT 0 COMMENT 'This column shows if this campaign was manually activated.',
 `Status` tinyint(4) GENERATED ALWAYS AS (if(`IsActivated`,if(curdate() between `StartDate` and `EndDate`,1,0),0)) VIRTUAL COMMENT 'The final, computed status of the campaign. When querying, you should use this to check the status.',
 `affiliatePrograms_AffiliateProgramId` mediumint(9) NOT NULL,
 `images_ImageId_BaseImage` bigint(20) DEFAULT NULL COMMENT 'The id of the base image.',
 `images_ImageId_CoverImage` bigint(20) DEFAULT NULL COMMENT 'The id of the cover image.',
 PRIMARY KEY (`AffiliateProgramsCampaignId`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1

• 调整mysqldump运行参数
  执行导出时额外添加--max-allowed-packet=1G --net-read-timeout=7200 --net-write-timeout=7200参数，增大数据包允许上限与网络超时阈值，该场景下虚拟列的元数据读取可能触发隐性的超时截断。也可以尝试添加--skip-opt参数后搭配--create-options --quick --extended-insert参数单独导出该问题表，再合并全量导出结果，--quick参数会强制mysqldump逐行读取表数据而非加载全表到内存，可降低虚拟列计算带来的内存与超时风险。
• 更换兼容性更好的导出工具
  优先使用MariaDB官方推出的mariadb-dump工具，该工具对MariaDB的虚拟列、生成列等专属特性兼容性优于通用mysqldump。如果是全库备份场景，也可以使用Percona XtraBackup做物理备份，物理备份无需执行表结构查询与数据逻辑导出，完全规避虚拟列带来的逻辑导出兼容性问题。
• 临时兼容处理
  全库导出时添加--ignore-table=你的数据库名.AffiliateProgramsCampaigns参数跳过该表，单独处理该表的导出：先手动导出该表的结构，再使用SELECT ... INTO OUTFILE语句导出该表的非虚拟列数据，导入时先重建表结构（含虚拟列）再导入数据即可。

• 查看MariaDB服务端错误日志，定位执行SHOW CREATE TABLE时服务端抛出的具体错误，确认是服务端内部崩溃、信号中断等隐性问题，还是单纯的客户端连接中断导致的报错。
• 对比mysqldump会话与手动执行语句的会话参数差异，分别导出两种场景下的SHOW SESSION VARIABLES结果，重点核对max_allowed_packet、wait_timeout、interactive_timeout等参数的配置差异。
• 尝试升级MariaDB到10.4分支的最新稳定版，10.4.21属于较旧的维护版本，该分支后续版本已修复过多个生成列相关的隐性BUG，升级后再测试导出是否正常。

内容的提问来源于stack exchange，提问作者Adam Baranyai