Magento 2 数据库从几十 GB 增长到数百 GB，第一反应往往是删除日志表。但真正占空间的可能是订单、URL Rewrite、索引临时表、队列消息、搜索查询、第三方审计记录或未清理的 staging 数据。没有先做归因就删除，会损失业务和审计信息。

先按数据与索引大小排序

SELECT table_name,
       ROUND(data_length/1024/1024,1) AS data_mb,
       ROUND(index_length/1024/1024,1) AS index_mb,
       table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY data_length + index_length DESC
LIMIT 30;

table_rows 对 InnoDB 可能是估算值，但足以筛选大表。再按天记录大小，增长速度比当前体积更有价值：订单表很大但稳定可能合理，一张第三方日志表每天增加 5 GB 才是紧急问题。

区分必须保留的业务数据

sales_order、invoice、shipment、creditmemo、customer 与支付相关表通常受财务、售后和合规要求约束，不能按“超过一年”直接删除。归档策略必须覆盖关联表、报表、退款和外部 ERP 引用。

Quote、Report、Search Query、Visitor、Cron Schedule、队列和日志类数据往往有可配置生命周期，但不同版本和模块的清理任务不同。先确认官方 Cron 是否运行，再决定历史保留期限。

DELETE 后文件不一定立即变小

InnoDB 删除记录会释放页供同表复用，磁盘上的表空间文件未必收缩。OPTIMIZE TABLE 或在线重建可能需要与原表接近的额外磁盘，并产生锁或复制压力。生产操作前必须在副本测量时间、空间和锁影响。

检查失败的索引临时表和队列积压

异常中断的 reindex、导入或扩展升级可能留下大型临时表。不要按名字带 tmp 就删除，先确认没有活动进程引用。消息队列 Ready/Unacked 长期增长，也会把消息数据库或相关表推大，根因是消费者故障而不是保留策略。

第三方日志最容易失控

支付、API、ERP 和调试模块可能把完整请求响应写入数据库。除了容量，还存在敏感数据风险。确认是否记录 token、客户地址或支付信息，立即调整脱敏、日志级别和保留期。不要把数据库当长期原始日志仓库，可转移到有生命周期管理的日志系统。

清理方案应包含：表级备份、精确 WHERE 条件、分批删除、复制延迟监控、回滚方法和业务验收。完成后继续监控两周，确认增长曲线改变；如果只是一次性清空但写入速度没变，数据库很快会再次膨胀。