简介：这是一份面向ECSHOP电商系统开发及二次开发人员的完整版数据库字典文档，覆盖v3.6/v3.0版本。文档从数据库字典角度，系统梳理商品分类、商品资料、商品相册、关联文章等模块的表结构设计，逐字段列出字段名、字段描述、字段类型、默认值、索引等关键属性，并针对关键字段补充语义说明，如上下架标识、供货商审核标识、促销价格处理规则等。资源共1个Word文档（docx），压缩包仅324KB，文档按业务模块组织，总页数36页，目录结构清晰，便于按需速查。目前已有233人浏览学习，适合ECSHOP使用者、PHP电商开发者及数据库维护人员作为日常参考手册。借助字段级说明，可快速掌握商品分类层级、价格区间、库存预警、促销周期、红包类型等业务在数据库中的落表方式，为二次开发、数据迁移与性能优化提供扎实基础。
1. 这份 ECSHOP 数据字典，到底能帮你省多少事
接手 ECSHOP 老项目做二次开发，最怕的不是 PHP 代码烂，而是打开数据库一脸懵：上百张表、几千个字段，不知道ecs_goods和ecs_order_goods之间到底靠什么关联，更不知道is_real、is_shipping这些字段什么时候该置 0 什么时候该置 1。ECSHOP-v3.6--3.0-完整版数据字典-数据库结构.docx 这份文档，就是用来治这个毛病的。它把 ECSHOP 3.6 / 3.0 全系列的数据库表结构、字段含义、默认值和关联关系整理成了一份可检索的离线手册，你做迁移、做二次开发、做报表统计前花半小时翻一遍，后面少走两三天弯路。
这份文档适合三类人：刚接手 ECSHOP 项目还摸不清表结构的初级开发、正在规划从旧版升级到 3.6 的迁移工程师、以及需要基于订单和商品数据做定制报表的运维或数分。说白了，它是把数据库这块“黑匣子”强行掀开，让你在写 SQL 之前就知道每一张表是干嘛的、每一个字段该不该用。有了它，你不再需要凭猜和试错去连表查询。
2. 拿到 docx 先别急着翻：从文档结构反推 ECSHOP 的库表设计思路
2.1 文档里最常见的内容组织方式：按模块分组，按表逐条拆
ECSHOP 数据字典类文档的常规写法是：先列一张“表清单”，把所有数据表按前缀ecs_或ecs_加模块名（如ecs_users、ecs_order_info）统一编号，再逐个对每张表给出字段明细，包括字段名、数据类型、是否允许 NULL、默认值、键类型和备注。v3.6 和 3.0 版本的字典目录结构大体一致，差异主要体现在几个关键表上：
ecs_goods增加了is_xiuxian、is_virtual等虚拟商品和扩展属性相关字段；ecs_order_info的支付和配送状态字段在 3.6 里做了补全，比如pay_status和shipping_status的枚举值说明更详细；ecs_admin_user的权限字段action_list在 3.6 中改成了序列化存储的富文本字符串。
拿到文档后，不要从头到尾线性阅读。我一般先打开“表清单”那一页，用荧光笔圈出自己业务涉及的表组，再跳到对应表页精读。比如做的是商城前台，重点关注ecs_goods、ecs_category、ecs_products（货品表）这三张；做订单流程，只看ecs_order_info、ecs_order_goods、ecs_order_action。文档不是教材，是手册，定位到具体表再去查字段，效率高得多。
2.2 用字段命名规律快速圈定业务表：前缀和动词后缀
ECSHOP 的表名和字段名有一个明显的规律：动词放后、模块放前、状态用短单词。比如is_on_sale表示是否上架，is_delete表示是否逻辑删除，is_best表示是否精品推荐。这些字段全部是is_开头的布尔开关，值是 0 或 1。文档里对这种命名方式通常不会重复解释，你需要自己总结规律：前缀is_是开关、goods_是商品维度、order_是订单维度、user_是会员维度。
这个规律还有一个实用场景：当你不知道某张表属于哪个业务模块时，直接看表名前 10 个字符。ecs_virtual_card一看就是虚拟卡券，ecs_snatch_log是夺宝奇兵活动的日志。文档的表清单里，每张表都带了一个备注列，写的是“商品活动表”“红包类型表”这类中文说明。把这个备注和你的业务场景映射起来，就能避免把活动日志当成订单表去解析的错误。
2.3 大表优先读结构，小表直接看内容
数据字典里表有大小之分。像ecs_goods、ecs_order_info、ecs_users这种单表字段超过 30 个的表，属于“大表”，你需要重点看字段名、类型和注释，不看具体数据。像ecs_cart（购物车）、ecs_collect_goods（收藏）这种只有十来个字段的小表，我反而建议直接联库看几条记录，配合字典确认字段的实际取值格式。
为什么这样分？大表字段多，枚举值说明散落在注释里，一条条看容易走神；小表字段少，逻辑简单，连库 SELECT 几条数据能加速理解。比如ecs_cart里的rec_type字段，字典里写的是“商品类型”，不看数据你根本不知道 0 是普通商品、1 是团购、2 是夺宝。翻库才能见到真实取值。
3. 用数据字典把 ECSHOP 表结构反推成实战 SQL：连表、分组、统计的三板斧
3.1 先确认主键和逻辑外键：没有物理外键，全靠字典里的说明
ECSHOP 的 MyISAM/InnoDB 表结构里，大多数表没有物理外键约束。表之间的关联是靠“业务主键字段”完成的，比如ecs_order_info.order_sn关联到ecs_order_goods.order_id其实用的是整型order_id，而ecs_goods.goods_id关联到ecs_order_goods.goods_id。这套逻辑关联通常不会在数据库层面强制，但数据字典会用“对应表”或“关联字段”的方式标注出来。你在拿它设计查询时，务必将这些逻辑外键当成物理外键对待，否则连表会出现一对多放大。
举个例子，统计“每个订单实际商品件数和金额”：
SELECT oi.order_id, oi.order_sn, COUNT(og.goods_id) AS goods_count, SUM(og.goods_number) AS total_number, SUM(og.goods_price * og.goods_number) AS total_goods_amount FROM ecs_order_info oi LEFT JOIN ecs_order_goods og ON oi.order_id = og.order_id WHERE oi.order_status NOT IN (2, 3) GROUP BY oi.order_id, oi.order_sn;这里LEFT JOIN的关键是oi.order_id = og.order_id，字段名和类型在两表都一致，文档里ecs_order_info.order_id和ecs_order_goods.order_id都是 int(10) unsigned，不会出现隐式转换问题。order_status NOT IN (2, 3)是排除已取消和已完成订单的统计口径，具体枚举值以字典说明为准。
3.2 商品与货品（SKU）的关联：goods_id 和 product_id 的嵌套关系
做电商开发绕不开 SKU。ECSHOP 主表ecs_goods存商品基础信息，ecs_products存货品（比如红色、XL 码这种具体规格组合）。字典里ecs_products的字段goods_id和product_sn是核心。在 3.6 版本中，ecs_products增加了bar_code（条形码）和is_promote（是否促销）字段，这就会影响你的库存同步脚本。
一个常见的错误写法是查销量只关联ecs_goods，而忽略了ecs_products，导致开了多规格的商品销量统计被压缩成单品维度。正确做法是先关联到货品表，再汇总：
SELECT p.goods_id, SUM(p.product_number) AS total_stock FROM ecs_products p LEFT JOIN ecs_goods g ON p.goods_id = g.goods_id WHERE g.is_delete = 0 GROUP BY p.goods_id;注意这里用的是LEFT JOIN ecs_goods并过滤掉is_delete = 1的逻辑删除商品，因为订单明细里可能有一批货品早已在后台被删，但历史订单还需要显示。数据字典的价值就在于告诉你product_number这个字段控制库存，is_promote控制促销价生效，两者都是数值类型，别拿字符串拼 SQL。
3.3 订单状态机：把字典里的状态字段拼成完整业务流
ECSHOP 的订单状态不是单一字段，而是order_status、pay_status、shipping_status三个字段的组合，这是数据字典里最容易被低估的内容。字典对每个字段的枚举值单独列出了说明，但没告诉你它们怎么组合。实际开发中，统计“有效订单”或“待发货订单”，必须对三字段做联合判断。
SELECT order_status, pay_status, shipping_status, COUNT(*) AS order_count FROM ecs_order_info GROUP BY order_status, pay_status, shipping_status ORDER BY order_count DESC;这条 SQL 的作用是：先把订单表的所有状态组合拉出来，结合字典的定义把每个组合翻译成业务含义。比如order_status=1, pay_status=2, shipping_status=1表示“已确认、已付款、部分发货”。你可以通过这一条命令彻底摸清线上环境跑着的订单状态分布，而不是靠猜。
4. 字典落不了地？把 ECSHOP-v3.6 字段类型、默认值和索引约定一次讲清
4.1 字段类型选择背后的潜规则：int 存时间戳，decimal 存金额，tinyint 存开关
ECSHOP 3.6 的表中，add_time和update_time都是 int(10) 类型，存的是 Unix 时间戳，不是 datetime。这个细节在数据字典里会明确标注，但很多从 WordPress 转过来的开发者容易忽略。你用FROM_UNIXTIME(add_time)转格式是常规操作，但做范围查询时要注意：别在函数上建索引，直接比较时间戳整数。
金额字段一律是 decimal(10, 2)，比如goods_price、market_price、pay_points。不要用 float，因为浮点比较和聚合会有精度误差。在字典里你会看到integral_money这类字段注释是“积分抵扣金额”，它的值可能是零，但数据类型仍是 decimal。为了安全，我一般把所有金额字段的运算都用ROUND(x, 2)包一层。
布尔开关字段统一用 tinyint(1)，别写BOOL。比如ecs_goods.is_on_sale，字典里注释就是“是否上架 1 上架 0 下架”。这没有歧义，但你在拼写 SQL 时别漏掉WHERE is_on_sale = 1，否则默认把下架商品也拉出来了。
4.2 默认值设计：NULL 和空串的边界
数据字典里有一列专门标“默认值”。ECSHOP 表设计习惯是：数值型字段默认 0，字符型字段默认空串''，时间字段默认 0（即 1970 时间戳）。这个约定和很多现代框架的“字段默认 NULL”不同。你在写代码时,要用COALESCE(column, 0)或IFNULL(column, 0)把它们统一，否则SUM聚合时 NULL 会导致结果异常。
比如订单表中pay_time字段默认 0，表示未支付。当你写统计：
SELECT COUNT(*) AS total_orders, SUM(IF(pay_time > 0, 1, 0)) AS paid_orders FROM ecs_order_info WHERE add_time >= UNIX_TIMESTAMP('2024-01-01 00:00:00');这里的IF(pay_time > 0, 1, 0)就是把默认 0 当成“未支付”来处理，而不是检查 IS NULL。数据字典里的默认值列,看起来不起眼，实际排查数据差异时是最先怀疑的对象，比如客户说“后台显示 300 单，你的报表只有 200 单”，八成是状态字段取 NULL 还是取 0 的口径不一致。
4.3 索引约定：哪些字段自带索引、哪些别乱加
字典里每张表会有 KEY 或 INDEX 标注。ecs_order_info的主键是order_id，通常还有order_sn的唯一索引。ecs_goods有cat_id和brand_id的普通索引。做高性能查询时，索引是很重要的参考：如果字典里一张表的查询字段没有索引，你还经常要用，那就得自己在上线前补上。
典型的踩坑点：ecs_order_goods在order_id上有没有索引？有，但在goods_id上没有。而很多报表会按商品维度去聚合订单明细，这样就会全表扫描，几万条订单明细就被拖慢。我的建议是：按字典的索引设置为底表，自己额外加两到三个高频查询索引，比如idx_goods_id、idx_order_sn。注意不要盲目加，一个表超过六个索引写入性能就会明显下降。
5. 实战排雷：使用 ECSHOP 数据字典最容易踩的四个坑
5.1 坑一：表前缀不一致，导致字典和线上库对不上号
现象：拿字典里的ecs_order_info去查询线上数据库，报错“Table doesn't exist”。
原因：字典默认前缀是ecs_，但很多部署环境为了安全或者多租户隔离，把前缀改成了shop_、sites_之类的自定义值。字典文档本身不会覆盖这种情况。
解决：先查实例里到底有哪些表：
SHOW TABLES LIKE '%order%';如果返回结果是shop_order_info，那就把字典里所有ecs_前缀在头脑里替换成shop_，或者直接用文本编辑器批量替换一遍。前缀确认是第一步，别上来就复制文档里的建表语句，那在多数线上库跑不通。
5.2 坑二：v3.0 和 v3.6 的字段差异，把代码写错了版本
现象：按文档查询ecs_goods的is_virtual字段，报错 Unknown column。
原因：手里这份字典标的是 3.6，但线上库是 3.0。3.0 的ecs_goods里根本没有is_virtual，虚拟商品字段是后来加的。文档封面写的“3.6/3.0 完整版”，很容易让人误以为两个版本字段完全一样。
解决：开发前先确认线上库的 ECSHOP 版本，用一条 SQL 验证字典里的“新字段”是否存在：
SHOW COLUMNS FROM ecs_goods LIKE 'is_virtual';返回空结果，就说明线上是旧版，字典里带版本差异的字段都不能用。我在做 3.0 升 3.6 前会把字典里注释带“版本”两字的字段全部筛出来，逐个比对线上库。
5.3 坑三：逻辑删除和数据字典的“物理删除”误解
现象：写统计类报表时，发现ecs_order_info里查出了大量order_status = 2（已取消）的单子，导致销售额虚高。
原因：ECSHOP 的订单取消是逻辑删除，数据行还在表里，只是状态位被置成2。数据字典通常不会特别强调“这是软删除”，它只会写着“order_status 订单状态”，但代码里取消订单动作对这个字段做了更新，没有真正 DELETE。
解决：所有涉及订单统计的 SQL，默认加上状态过滤条件：
WHERE order_status NOT IN (2, 3)2代表已取消，3代表已完成。根据业务需要，已完成订单是否计入销售额要单独拧清楚，不要混在一起。这条血泪经验是从报表取数翻车中得来的，字典只给你结构，口径要靠自己定义。
5.4 坑四：把备注里带“冗余”的字段当成独立业务字段
现象：ecs_order_info里有goods_amount和total_amount，字典注释分别是“商品总金额”和“订单总金额”，不了解的人会认为两者独立统计。
原因：实际上total_amount是在goods_amount基础上加上shipping_fee、insure_fee、pay_fee、pack_fee、card_fee，再减去bonus、integral_money、discount之后算出的最终金额。它是冗余字段，用于订单列表页免计算展示。
解决：做报表时直接用total_amount作为订单实付金额，不重复再算一遍。如果要排查“为什么后台订单金额和财务对不上”，优先怀疑discount和integral_money这两个字段是否被正确扣减。字典里字段注释短，你需要结合 ECSHOP 的结算逻辑去理解，而不是孤立地看每个字段。
6. 把数据字典吃到肚子里：一套不用写代码的库表结构校验流程
光看不练，数据字典是“死”的。把它和线上库做一次比对，才能确认文档的可信度和覆盖度。做法分三步。第一步，核对表数量：用SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = '你的库名'拿到实际表数量，和字典表清单的数量对比，差数通常就是插件或二次开发加的表。第二步，对一个核心表抽查字段：挑ecs_goods，执行SHOW FULL COLUMNS FROM ecs_goods，把输出结果和字典里的对应页逐条比对，重点看字段注释、类型和默认值。第三步，如果发现字典里有但库表里没有的字段，用前面SHOW COLUMNS LIKE确认版本差异即可。
这套流程做完，你对这份字典的信任度会从“大概齐”变成“能用”。真正上了项目，我的习惯是：在 Navicat 里把核对过的表结构导出成一份带注释的 HTML 或 Markdown，替换掉原始 docx，作为后续团队协作的数据库基线。哪怕团队换人，新来的兄弟照着这份结构文档就能写查询，不用反复去数tinyint到底是 0 还是 1。
最后的验证建议是拿一个真实业务问题走一遍：比如“统计上月已付款且未发货的订单总额”。打开字典定位到ecs_order_info的pay_status和shipping_status，确认 3.6 版分别用2表示已付款、1表示未发货，再写一条 SQL 跑通，业务方认了，这套字典方法论就真正落地了。数据库结构这东西，就怕“用着用着发现表对不上”，提前做一次库表结构校验相当于给项目吃了一颗后悔药，等出问题再回头翻文档，成本高得多。希望帮到你。
本文还有配套的精品资源，点击获取
