如何在Shopware 6中获取适用于开发场景的SQL转储文件

别直接全量导出生产库，光历史订单、日志、队列表就能攒几个G，导入本地要半小时，对开发完全没用，针对不需要全量用户、订单类业务数据的场景，按以下步骤操作即可：

1. 生成符合开发要求的SQL转储文件 #

• 先在待导出的源环境（生产/预发布）执行bin/console cache:clear、bin/console messenger:stop-workers，清空队列表、日志表、缓存表里的无效运行时数据，从源头减少冗余内容。
• 导出全库表结构：用mysqldump的--no-data参数导出所有表的结构，保证本地不会缺表，命令参考：
  mysqldump -u<源库账号> -p<源库密码> <源库名> --no-data --skip-triggers --set-gtid-purged=OFF > dev_dump_structure.sql
• 单独导出开发必需的配置类数据：只导系统配置、商品、品类、CMS布局、主题配置、支付/配送方式规则、销售渠道基础配置这类开发必须依赖的表数据，完全跳过用户、订单、支付记录、收件地址、新闻订阅、日志、队列、缓存、API凭证类表的数据，导出时加--complete-insert --skip-triggers --set-gtid-purged=OFF参数，避免跨版本导入的兼容问题。
• 做一次脱敏校验：如果导出的配置数据里混了少量真实用户相关的测试数据，统一把手机号、邮箱、收货地址替换成虚构的测试值，别把真实用户信息带到开发环境。
• 嫌手动写表过滤参数麻烦的，直接用Shopware后台自带的数据库导出工具，勾选「排除业务交易数据」选项就能自动生成符合要求的转储文件，不用自己挨个核对表名漏导错导。

2. 导入精简SQL转储文件 #

按顺序操作基本不会出兼容问题：

• 本地先新建空数据库，字符集选utf8mb4，排序规则用utf8mb4_unicode_ci，和源环境配置保持一致，避免特殊字符、字段长度类的报错。
• 把本地项目.env文件里的数据库连接信息改成你本地新建库的账号密码，别先执行shopware:install命令，不然会直接覆盖转储里带的系统配置。
• 可以在转储文件最顶部加一行SET FOREIGN_KEY_CHECKS=0;，末尾加一行SET FOREIGN_KEY_CHECKS=1;，避免因为表导入顺序不对触发外键约束报错。
• 按顺序导入文件：先导表结构文件，再导配置数据文件，如果是提前合并好的单转储文件直接导入即可，命令参考：
  mysql -u<本地库账号> -p<本地库密码> <本地库名> < dev_dump_final.sql
• 导入完成后依次执行几个初始化命令适配本地环境：
  • bin/console database:migrate --all：跑完本地代码版本新增的数据库迁移，保证表结构和本地代码完全匹配
  • bin/console cache:clear：清空所有系统缓存
  • bin/console user:create --admin dev：创建本地专用的管理员账号，按提示设置密码即可，不需要从源环境导入管理员账号
  • 本地调试需要用到媒体资源的话，再跑bin/console media:generate-thumbnails生成缩略图，不需要可以直接跳过。

3. 转储文件的团队共享管理 #

核心原则是安全、不折腾开发人员：

• 绝对不要把SQL转储文件提交到Git等代码版本库，哪怕是脱敏后的文件也不行，一方面文件体积大diff完全不可读，另一方面很容易误提交未脱敏的敏感数据造成安全问题。
• 存储选团队内部的私有受控存储就行，比如内部NAS、私有对象存储、企业内部文件服务，严格配置访问权限，仅项目相关开发人员可下载，禁止放到公网可访问的位置。
• 文件命名统一带版本标识，比如sw6-dev-dump-20240620-v2.sql.gz，标注清楚生成日期、适配的Shopware版本、包含的数据范围，每次系统大版本更新、商品/CMS配置大改后重新生成新的转储文件，历史版本保留最近3份即可，不用冗余存储占空间。
• 可以在项目代码库的dev/目录下放一个一键初始化shell脚本，脚本内置最新转储文件的拉取地址、自动导入、自动执行后续初始化命令的逻辑，新同事搭环境或者老开发重置本地环境的时候，只需要跑这一个脚本就能完成所有操作，不用手动找文件、敲零散命令。
• 每次更新转储文件在团队内部同步下更新说明，比如本次补全了之前缺失的支付方式配置、更新了最新的商品数据就行，避免大家用旧转储踩没必要的坑。

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