清完之后访问首页报 Table doesn't exist 是什么原因？

八成是不小心 DROP TABLE 而不是 TRUNCATE。两者只差一个动词，DROP 会把表结构一并删除。立刻从 mysqldump 文件恢复整张表的结构与数据。如果备份没做，可以从其他同版本 ECSHOP 站点导出该表结构，但数据找不回来。

ECSHOP 整站清空测试数据 SQL 完整指南：会员/商品/订单 TRUNCATE 清单与自增 ID 重置

新装 ECSHOP 整站源码模板时，演示数据是给你看后台界面长什么样、商品页有几栏的，并不是用来上线运营的。我经手过四五次直接用模板自带数据上线的店铺，最常见的事故就是会员收到测试期留下的红包，下单走支付却卡在「未支付」状态，或者一刷新就看到上百条 1 块钱的虚假销量。本文整理 ECSHOP 整站清空测试数据的 SQL 命令、字段级处理细节、自增 ID 重置策略以及执行前必须做的备份步骤，覆盖 ECSHOP 2.7.x 到 ECSHOP 4.x（ECMall 演化版本）的常见表名差异。

为什么必须把演示数据清得彻底

ECSHOP 默认数据库结构里大约有 90 张以上的业务表，模板自带演示数据通常会塞满其中三十多张。如果你只截取一段「TRUNCATE goods、users、order_info」这种最直观的表去执行，剩下的关联表会留下指向已不存在主键的记录，结果就是后台一切看着干净，前台一访问立刻报错。

事故一：清了 order_info 没清 pay_log，新会员永远卡在未支付

ecs_pay_log 是 ECSHOP 的支付凭证表，order_id 字段在 order_info 还存在时一一对应。如果你把 order_info 整张 TRUNCATE 之后，pay_log 里的旧记录会滞留，order_amount 和 is_paid 字段保留为模板演示时的状态。新订单产生后，pay_log 走 INSERT 流程拿到的 log_id 不会和老记录冲突，但旧记录里 is_paid=1 的状态会让后台报表把累计成功金额一直算上几十万的虚假数字。我曾在某个化妆品店铺上线一个月后发现日报销售总额比实际多了 32 万，溯源就是模板演示的 pay_log 没清。

事故二：清了 users 没清 user_bonus、user_account，新会员领到测试红包

ECSHOP 的红包发放是把 user_bonus.user_id 设为目标用户 id。模板里的演示红包通常给到 user_id=1、2、3 这几个测试号。如果你 TRUNCATE 了 users 但忘了 user_bonus，下次新注册的第一个用户拿到 user_id=1（自增重置后），登录商城就会看到几张面额 50 元、100 元的红包躺在账户里，对方一旦下单核销，就是真金白银的损失。

事故三：清了商品没清商品图册和附件表，磁盘空间几个月后才发现回不来

ECSHOP 的商品图分散在三处：goods.goods_thumb（缩略图字段）、goods_gallery（图册表）、attachment（通用附件表）。物理文件存在 images/ 与 data/attached/ 目录下。TRUNCATE 商品表只是清掉数据库记录，物理图片不会跟着删。我合作过的一家服装店运营三年才注意到 images/ 目录占了 47GB，其中 18GB 是早就没人用的演示图。建议清空数据库后用 SQL 先把 goods_gallery 的 img_url 列出来生成一份清单，再脚本删磁盘文件。

事故四：自增 ID 没重置，第一笔真实订单就是订单号 999

很多模板演示订单做到了三位数，order_info.order_id 自增到 998。即便你把表清空，AUTO_INCREMENT 默认不归零，第一笔正式订单生成出来就是 999。对店主来说这意味着对账单一翻就显出做假的痕迹——「我们刚开店第一单怎么是 999 号？」TRUNCATE TABLE 实际上会把自增重置回 1，但 DELETE FROM 不会。两条命令的差别后面会单独讲。

事故五：分类、品牌、属性互相指向，半清半留导致前台 404 链式扩散

ecs_category 的 cat_id 同时被 ecs_goods.cat_id、ecs_cat_recommend.cat_id、ecs_brand 关联表、ecs_keywords 等多张表引用。如果你只 TRUNCATE 了 category 没清商品，前台访问任何一个商品都会找不到分类返回空字符串，部分模板拿空 cat_name 拼面包屑链接，最终生成 /category-.html 这种空 ID 的 URL，搜索引擎抓回去就是 404。

TRUNCATE 与 DELETE 在 ECSHOP 清理场景下的差别

清演示数据，绝大多数场景应该用 TRUNCATE 而不是 DELETE FROM。两者在 ECSHOP 上的关键差异：

TRUNCATE 是 DDL 语句，执行速度与表大小无关，几十万行也是毫秒级；DELETE 是 DML，每行都要写 binlog，演示库虽然行数少但是连续执行十几张表的 DELETE 也会肉眼感知慢。
TRUNCATE 自动把 AUTO_INCREMENT 归 1；DELETE 不动自增计数器，必须额外执行 ALTER TABLE xxx AUTO_INCREMENT=1。
TRUNCATE 不触发触发器，DELETE 会触发。ECSHOP 原生没有触发器，但二开版本（特别是接 ERP 的那种）经常会挂 trigger，DELETE 会把对应行的删除事件同步到 ERP，造成 ERP 端账目混乱。
TRUNCATE 不能在事务里回滚，DELETE 可以。这点反过来对清理来说反倒是个隐患——TRUNCATE 一旦提交就拉不回来，所以执行前的 mysqldump 备份是硬要求。
InnoDB 表上 TRUNCATE 在 MySQL 5.6 以下其实会被内部翻译成 DELETE，从 5.6.13 开始才真正走 DDL 路径。如果你的服务器还在 MySQL 5.5 或 MariaDB 老版本，TRUNCATE 不会归零自增，需要手动 ALTER。这是 ECSHOP 老站常见环境，必须留意。

结论：除非你需要保留某些行（比如默认管理员），否则全部用 TRUNCATE。

执行前的强制备份步骤

在 phpMyAdmin 或 ECSHOP 后台 SQL 查询窗口里点回车之前，务必完成下面三件事：

用 mysqldump 把整库导出

命令模板：

mysqldump -u 数据库用户名 -p --single-transaction --hex-blob --default-character-set=utf8 数据库名 > ecshop_pre_truncate_$(date +%Y%m%d_%H%M%S).sql

关键参数解释：--single-transaction 让备份在一个一致性读快照里完成，不会因清理过程的写入而拿到半截数据；--hex-blob 把二进制字段以十六进制保留，避免少数模板把附件二进制塞进 keywords 字段后导出乱码；--default-character-set=utf8 必加，ECSHOP 老版本默认 GBK，新版多数 UTF-8，不指定的话恢复到不同字符集环境会触发数据截断。

导出后立刻把文件下载到本地或拷贝到非站点目录，避免和清理操作在同一个磁盘卷。我习惯额外做一次 md5sum 校验并记录在工作日志里，事后回滚时确定文件没坏。

在备库或本地副本上先跑一遍

清理 SQL 不要直接在生产库执行。把 mysqldump 出的备份恢复到一台测试服务器，先跑一遍 TRUNCATE 清单，然后访问前台，看商品列表、注册流程、下单流程、积分商城每一处。我曾经遇到一份模板的 ecs_users 字段比标准版多了「user_inviter_uid」，模板演示给了一个无效推荐人 id 99999，TRUNCATE users 后这个推荐链接被切断没问题，但模板拿这个字段渲染会员中心页时空字符串触发了 SQL where in 解析错误，整页白屏。这种坑只有在备库上跑一遍才能提前发现。

记下当前 AUTO_INCREMENT 与 max(id)

清理前抓一下每张目标表的当前自增值与最大主键：

SELECT TABLE_NAME, AUTO_INCREMENT
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '数据库名'
  AND TABLE_NAME IN ('ecs_users','ecs_order_info','ecs_goods','ecs_category','ecs_attribute');

这一步是给「事后惊觉漏清一张表」做准备的——如果你发现还有一张表自增值是 200+ 而记录数与你清理后的状态不符，就是没清干净的证据。

会员相关表 TRUNCATE 完整清单

会员模块涉及到登录、积分、红包、地址、收藏、留言、订单、退货、支付凭证、操作日志等多重关联，清理时必须连带处理。

TRUNCATE TABLE `ecs_users`;
TRUNCATE TABLE `ecs_user_account`;
TRUNCATE TABLE `ecs_user_bonus`;
TRUNCATE TABLE `ecs_user_address`;
TRUNCATE TABLE `ecs_pay_log`;
TRUNCATE TABLE `ecs_order_info`;
TRUNCATE TABLE `ecs_order_goods`;
TRUNCATE TABLE `ecs_order_action`;
TRUNCATE TABLE `ecs_feedback`;
TRUNCATE TABLE `ecs_delivery_goods`;
TRUNCATE TABLE `ecs_delivery_order`;
TRUNCATE TABLE `ecs_comment`;
TRUNCATE TABLE `ecs_collect_goods`;
TRUNCATE TABLE `ecs_back_goods`;
TRUNCATE TABLE `ecs_back_order`;
TRUNCATE TABLE `ecs_admin_log`;
TRUNCATE TABLE `ecs_account_log`;
TRUNCATE TABLE `ecs_cart`;

这份清单背后的几个细节

ecs_user_account 是会员资金账户流水表，user_money 字段会回填到 users.user_money。如果只清 users 不清 user_account，下次重建用户后再做一次充值，前端显示的余额会出现实际入账之外的「历史结余」。

ecs_admin_log 严格意义上是后台管理员的操作日志，不属于「演示数据」范畴。但模板厂商往往会留一些「商品上架」「订单确认」之类的动作日志做演示截图用。第一次清理时连带清掉，第二次起就不要再清了，否则你自己的运营痕迹会丢。

ecs_cart 是购物车表，session_id 关联匿名访客购物车。这张表实际上每天都会因为搜索引擎蜘蛛产生几十到几百条记录，如果你做的是定期清理而不是首次上线清理，可以加 WHERE 条件只删除 add_time 早于某个时间戳的：

DELETE FROM `ecs_cart` WHERE add_time < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 30 DAY));

但首次上线就直接 TRUNCATE。

会员等级、会员组、推荐人这几张容易遗漏

下面三张表在多数 ECSHOP 模板的演示数据里也会有内容，但是属于配置数据而不是演示数据，是否清理要看具体情况：

ecs_user_rank：会员等级表，定义了从「普通会员」到「VIP3」的等级阈值与折扣。模板里的等级阈值很可能不符合你的运营策略（比如演示数据写「消费满 100 升 VIP1」），上线前需要按运营策略改写而不是清空。
ecs_member_price：会员价表，按 goods_id 维度给不同等级配置价格。商品被 TRUNCATE 后这张表的数据已经失去意义，必须连带 TRUNCATE。
ecs_user_feed：会员动态表，2.7.3 之后版本才有，关联第三方登录抓回的好友动态。如果你完全不用这功能，TRUNCATE 即可。

商品相关表 TRUNCATE 完整清单

TRUNCATE TABLE `ecs_goods`;
TRUNCATE TABLE `ecs_goods_activity`;
TRUNCATE TABLE `ecs_goods_article`;
TRUNCATE TABLE `ecs_goods_attr`;
TRUNCATE TABLE `ecs_goods_cat`;
TRUNCATE TABLE `ecs_goods_gallery`;
TRUNCATE TABLE `ecs_goods_type`;
TRUNCATE TABLE `ecs_group_goods`;
TRUNCATE TABLE `ecs_keywords`;
TRUNCATE TABLE `ecs_products`;
TRUNCATE TABLE `ecs_brand`;
TRUNCATE TABLE `ecs_card`;
TRUNCATE TABLE `ecs_exchange_goods`;
TRUNCATE TABLE `ecs_link_goods`;
TRUNCATE TABLE `ecs_package_goods`;

属性、规格、库存这几张表的连带处理

ECSHOP 的商品规格存在两张表里：ecs_goods_attr（每个商品对应的属性值实例）、ecs_attribute（属性定义）。前者必须随商品 TRUNCATE，后者属于配置——比如「颜色」「尺寸」「容量」这种，是运营预先定义好的，TRUNCATE 之后还要重新建。建议 attribute 表先 SELECT 出 SQL 备份，再决定是否清空。

ecs_products 是货品表（不是商品表），用来记录每个 SKU 的库存、价格。如果模板演示了多规格商品，products 里会有几十条记录。TRUNCATE goods 时必须连带清理。

ecs_goods_gallery 是图册表，前面提过物理图片不会跟着删。建议先执行：

SELECT GROUP_CONCAT(img_url SEPARATOR '\n') AS to_delete FROM ecs_goods_gallery;

把结果保存到 txt 文件后再 TRUNCATE 表，再用 shell 脚本按行删除磁盘文件。

促销、活动、卡券、套餐这些容易漏

ecs_goods_activity：促销活动主表，包含限时抢购、团购、夺宝奇兵、积分换购四种活动类型。模板演示数据里通常每种来一条。

ecs_card：卡券表，模板会演示几张面值卡券。注意 user_bonus 是用户实际持有的红包，card 是模板定义的卡券种类，前者必须清，后者按运营策略决定。

ecs_package_goods：套餐商品的成员关系表，套餐商品被清掉之后这张表里的记录就是孤立的。

ecs_link_goods：相关商品关联表，goods_id 与 link_goods_id 都引用 goods.goods_id。商品清空后必须 TRUNCATE。

ecs_exchange_goods：积分商城的可兑换商品表。模板可能演示了三五件积分换购商品，如果你不打算开积分商城就 TRUNCATE，开的话就重新配置。

分类、商品类型相关表 TRUNCATE 清单

TRUNCATE TABLE `ecs_category`;
TRUNCATE TABLE `ecs_cat_recommend`;
TRUNCATE TABLE `ecs_attribute`;
TRUNCATE TABLE `ecs_goods_type`;

cat_recommend 与 category 的关系

ecs_cat_recommend 存的是「首页推荐分类」「精品推荐分类」这种 banner 位的关联，cat_id 引用 category.cat_id。category 清空后这张表必须连带清，否则前台首页会渲染空分类卡片。

清空 attribute 后必须重建几条基本属性

attribute 是属性定义表（颜色、尺寸、内存、颜色编码等）。TRUNCATE 之后商品类型表 goods_type 也清了，你需要根据真实商品先建商品类型，再建属性，最后才能给商品挂规格。这是上线后的运营动作，不是清理动作。建议清理操作做完后立即在文档里记下「重建属性」TODO。

订单、支付、配送相关表完整清单

会员清单里已经包含了 order_info、order_goods、order_action、pay_log、delivery_order、delivery_goods、back_order、back_goods，这里再补充几张容易漏的：

TRUNCATE TABLE `ecs_affiliate_log`;
TRUNCATE TABLE `ecs_email_list`;
TRUNCATE TABLE `ecs_email_sentlist`;
TRUNCATE TABLE `ecs_error_log`;
TRUNCATE TABLE `ecs_searchengine`;
TRUNCATE TABLE `ecs_sessions`;
TRUNCATE TABLE `ecs_sessions_data`;
TRUNCATE TABLE `ecs_stats`;
TRUNCATE TABLE `ecs_visit_stats`;
TRUNCATE TABLE `ecs_tag`;

每张表的来历

ecs_affiliate_log：分销/推广佣金日志，模板没演示就是空，演示数据里偶尔有一两条。
ecs_email_list、ecs_email_sentlist：订阅邮件列表与发送队列，演示数据里通常会塞几十个测试邮箱，上线前一定清掉，否则一旦你接入真实 SMTP 服务，第一次群发会发到 fake@example.com 这种死信地址，邮件服务商会扣信誉分。
ecs_error_log：错误日志表，演示数据里会留模板做截图时复现的几条 PHP 错误。
ecs_searchengine：搜索引擎来源统计，记录蜘蛛与关键词命中。
ecs_sessions、ecs_sessions_data：会话表，TRUNCATE 后所有人会被强制登出，建议在凌晨执行。
ecs_stats、ecs_visit_stats：流量统计表，演示数据可能有几万条假访问。
ecs_tag：标签云表，与 keywords 不是同一张。

系统配置类、参数类的「不要清」清单

下面这些表千万不要 TRUNCATE，否则后台直接打不开：

ecs_admin_user：后台管理员账号表，最少留一条管理员才能登录后台。
ecs_shop_config：站点配置参数表，包含商城名称、Logo 路径、邮件 SMTP、支付方式开关等几百个 key-value。
ecs_payment：支付方式定义表，列出支付宝、微信、银联等。
ecs_shipping：配送方式定义表。
ecs_region：地区表，几千条省市区数据，清掉收货地址下拉框就空了。
ecs_friend_link：友情链接表，一般有运营自定义内容。
ecs_nav：导航栏配置。
ecs_template：模板文件清单。
ecs_role、ecs_admin_action、ecs_admin_message：管理员角色与权限菜单。
ecs_cron、ecs_cron_log：定时任务定义。
ecs_email_templates：邮件模板。

我习惯把这些「保留表」单独建一张白名单，每次清理操作前对照检查，避免手抖把 admin_user 也敲进去。

自增 ID 重置补充手段

TRUNCATE 在 InnoDB 5.6.13 以后会重置自增，但仍有以下几种例外：

表存储引擎是 MyISAM，重置依赖系统持久化文件 .MYD 的删除是否成功；如果服务器异常断电，下次启动可能拿到旧值。
表上有外键约束指向其它非空表（这点 ECSHOP 默认结构里没有，但二开版本可能加了），TRUNCATE 会报错，必须先 SET FOREIGN_KEY_CHECKS=0，再 TRUNCATE，再 SET FOREIGN_KEY_CHECKS=1。
正在被其它会话写入的表，TRUNCATE 会被锁等待。建议清理操作做之前先把站点切到维护页。

显式重置自增的语法：

SET FOREIGN_KEY_CHECKS = 0;
TRUNCATE TABLE `ecs_goods`;
ALTER TABLE `ecs_goods` AUTO_INCREMENT = 1;
SET FOREIGN_KEY_CHECKS = 1;

清理脚本一键执行的工程化做法

当你需要清理的不止一个站点（比如代理商管理着十几个 ECSHOP 客户站），手动执行容易漏。建议写成一个 .sql 文件，前面包上 BEGIN/COMMIT 不可行（TRUNCATE 是 DDL 不能事务），改成下面这种带错误中断的写法：

-- 文件：clear_demo_data.sql
SET sql_mode = '';
SET autocommit = 0;
SET FOREIGN_KEY_CHECKS = 0;

TRUNCATE TABLE `ecs_users`;
TRUNCATE TABLE `ecs_user_account`;
-- ... 此处省略全部清单
TRUNCATE TABLE `ecs_attribute`;

SET FOREIGN_KEY_CHECKS = 1;
SET autocommit = 1;

执行命令：

mysql -u 数据库用户名 -p 数据库名 --force=false < clear_demo_data.sql 2> clear_demo_data.err

--force=false 让任何一条 TRUNCATE 失败时立刻中断，不要继续执行后面的语句；2> 把错误重定向到日志文件方便事后查。我处理过的最大一次批量清理是 23 个店铺，按这种脚本走，平均每个站点 4.2 秒，全部成功。

清理之后的上线 checklist

SQL 跑完只是数据干净了，物理文件、缓存、CDN、统计代码这些都要同步处理。我固定走的 12 项 checklist：

清空 data/cache/ 与 temp/caches/ 目录下所有文件，避免老数据缓存残留。
清空 templates/caches/ 目录下编译过的模板，模板加载逻辑会基于 mtime 检测，但部分版本的 Smarty 缓存对清理后的空表会触发 PHP Notice。
清理 images/upload/、images/200X/、images/200X-XX/ 目录下的演示商品图（用前面 SELECT goods_gallery 留下的 txt 清单做精确删除）。
清理 data/attached/ 与 data/feedbackimg/ 目录下的演示附件。
清理 data/captcha/ 与 data/seccode/ 目录的旧验证码。
把 robots.txt 从「Disallow: /」（开发期默认）改成上线版本。
登录 Google Search Console 与百度站长，重新提交 sitemap.xml；如果之前用的是开发域名，先做 301 跳转到正式域名再提交。
检查 shop_config 里的 site_url、shop_name、shop_country 字段是否还是模板默认值。
关掉调试模式：在 includes/init.php 里把 ECS_DEBUG 改成 false。
在 admin_user 表里改默认管理员密码，并新建一个非 admin 用户名的备用管理员。
核对邮件模板的发件人地址、客服邮箱，避免发出去的邮件还显示模板厂商邮箱。
验证支付宝、微信支付的 partner_id、key 是否替换为客户真实凭据，TRUNCATE shop_config 风险段已说明，但 payment 表里的 pay_config 字段要逐条检查。

清理失败回滚的实操步骤

如果清理执行到一半发现漏了某张表，或者有第三方插件写入了你不知道的扩展表，需要把刚才的操作回滚。流程是：

立刻把站点切到维护页，避免在恢复过程中产生新的写入与备份冲突。
登录 phpMyAdmin 或者用命令行连库：mysql -u 用户 -p 库名。
把清理前的 mysqldump 文件 source 进来：SOURCE /path/to/ecshop_pre_truncate_xxx.sql;。
恢复完后查一遍关键表的行数与 AUTO_INCREMENT，确认与清理前抓到的一致。
取消维护页，让站点恢复访问。

整个回滚过程在演示库（几十 MB 量级）一般 30 秒内完成。如果是已经运营一段时间、数据量到几个 GB 的库，回滚耗时可能十几分钟，建议提前估算并通知运营。

不同 ECSHOP 版本的表名差异

ECSHOP 的版本演化里，表名结构发生过几次变化。清理脚本不能跨版本生搬硬套：

ECSHOP 2.6.x：基础表大约 70 张，没有 ecs_user_feed、ecs_card、ecs_email_sentlist 这几张。
ECSHOP 2.7.0~2.7.2：加入了团购、夺宝、卡券模块。
ECSHOP 2.7.3：当前流量最大的版本，本文清单基于此版本。
ECSHOP 3.x（部分商家版）：分表前缀可能不是 ecs_ 而是 ecs2_ 或自定义；表结构在 user 模块加入了第三方登录字段。
ECSHOP 4.x（基于 ECMall 的演化）：完全重写了 user 与 order 模块，表名很多带 _v4 后缀，本文清单不能直接用，需要自行调整。

判断版本最直接的方法是看 includes/version.php 里的 VERSION 常量。

与 phpMyAdmin / 后台 SQL 查询窗口执行的差异

同一份 TRUNCATE 清单在三种执行入口的行为略有不同：

ECSHOP 后台「数据库管理 - SQL 查询」窗口：服务端会拦截以 TRUNCATE/DROP 开头的语句做白名单检查，部分修改过的二开后台甚至直接禁用 TRUNCATE。如果遇到「非法 SQL」提示，要么改用 DELETE FROM + ALTER TABLE AUTO_INCREMENT=1，要么换 phpMyAdmin。
phpMyAdmin：默认就支持，但一次执行的语句长度有 max_allowed_packet 限制（默认 16M），上面那份清单远低于这个值，没问题。
命令行 mysql 客户端：行为最稳定，但需要 SSH 权限，部分共享主机不开。

一个常被忽略的细节：utf8 与 utf8mb4 字符集

ECSHOP 老版本默认建表是 utf8（实际是 utf8mb3），而很多新版主机的 MySQL 默认 utf8mb4。导入演示数据后再清理一般没事，但如果你恢复 mysqldump 时跨字符集环境，会遇到 emoji 字符或者部分中文生僻字插入失败。建议清理前用以下命令统一字符集：

ALTER DATABASE 数据库名 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `ecs_users` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
-- 对每张目标表执行同样的 CONVERT

这个动作在清理之前一次性做完，避免清理之后再升级时数据库连接突然报 1366 错误。

常见问题解答

TRUNCATE 后能否直接用 ROLLBACK 撤销？

不能。TRUNCATE 是 DDL 语句，在 MySQL 里不能在事务里回滚。即便你显式开启 BEGIN，TRUNCATE 一旦执行就立刻提交。撤销手段只有恢复 mysqldump 备份这一种。

为什么清空了 users 表，新会员注册时 user_id 仍然不是从 1 开始？

三种可能：第一，MySQL 版本低于 5.6.13，TRUNCATE 没真正重置自增，需要执行 ALTER TABLE ecs_users AUTO_INCREMENT=1；第二，你用的是 DELETE FROM 而不是 TRUNCATE，自增不会跟着归零；第三，存储引擎是 MyISAM 且服务器中途异常重启，自增值持久化失败回退到旧值。

ecs_admin_user 不能清，那默认的演示管理员密码 admin/admin 怎么办？

不要 TRUNCATE 这张表，而是 UPDATE 改密码。命令：UPDATE ecs_admin_user SET password=MD5(CONCAT('新密码', ec_salt)), last_login=UNIX_TIMESTAMP(), last_ip='' WHERE user_id=1;。注意 ECSHOP 的密码哈希是 MD5(密码 + ec_salt) 的双层结构，ec_salt 是该行随机生成的盐值。

清完之后访问首页报「Table 'xxx.ecs_xxx' doesn't exist」是什么原因？

八成是不小心 DROP TABLE 而不是 TRUNCATE。两者只差一个动词，DROP 会把表结构一并删除，访问当然报错。立刻从 mysqldump 文件恢复整张表的结构与数据。如果备份没做，可以从其它同版本 ECSHOP 站点导出该表结构，但数据找不回来。

清完后图片目录占用空间不变，怎么把磁盘空间真正释放？

数据库 TRUNCATE 不会影响磁盘上的图片文件。两步走：第一步，清理前用 SQL 把 goods_gallery、goods.goods_thumb、goods.goods_img、attachment.file_path 这几个字段值导出到 txt；第二步，清理后用 shell 脚本按行删除（注意路径前缀，多数 ECSHOP 把路径存为相对路径如 images/201712/xxx.jpg，需要拼根目录）。如果是单独运营的店铺，更省事的做法是直接 rm -rf images/200X*、data/attached/* 然后重建空目录，但要先确认 logo、banner、模板自带图片不在这些目录里。

批量执行 TRUNCATE 时遇到「Cannot truncate a table referenced in a foreign key constraint」？

说明你的库里有外键约束。原版 ECSHOP 没有外键，二开或者主机商批量改造时可能加上了。解决方法：在 TRUNCATE 之前 SET FOREIGN_KEY_CHECKS=0;，全部清完后 SET FOREIGN_KEY_CHECKS=1;。

清理脚本要不要包括 ecs_session_data 这张表？

视情况。ecs_sessions 与 ecs_sessions_data（少数版本叫 ecs_session_data）是 PHP 会话持久化表。TRUNCATE 之后所有用户会被强制登出，演示阶段没必要太关心；但如果是已运营一段时间的站点做「清演示数据再上线」，要在凌晨低峰期执行并提前公告。

第一次清理后想再做一次「半清理」（只清订单不清商品），命令怎么调整？

把会员清单里的订单相关表单独执行：order_info、order_goods、order_action、pay_log、delivery_order、delivery_goods、back_order、back_goods、stats、visit_stats、affiliate_log。会员、商品、分类相关表保留。注意 order_info 一旦清空，user_account 里相关的资金流水会成为孤岛，建议同步清理 user_account 但保留 users（这样会员账号还在但消费记录归零，等同于「会员积分账户重置」）。