数据库迁移
无需高昂的数据清洗成本，自动打包迁移。
设计原则
G3-Web 数据库表设计，遵循以下原则：
- 保持业务数据纯净性
- 保持数据查询高效性
- 保证数据模型的基础单元完整
- 保证支持未来可能的系统升级与迁移
Meta 诟病
WP Meta 表设计初衷是为了提供极高的灵活性，允许开发者无需修改数据库结构即可为文章或用户附加任意数据。
然而，随着网站规模的增长和复杂查询需求的增加，这种设计暴露出了严重的性能和架构缺陷。
1. 垂直存储结构导致的性能瓶颈
Meta 表采用的是 键值对 (Key-Value) 的垂直存储结构。这意味着，如果你为一个用户或一篇文章添加 10 个自定义字段，Meta 表中就会增加 10 行记录。通常业务中，各类 meta 数据轻易地便超过 30 甚至 50 个。
- 数据膨胀：这种结构会导致表体积呈指数级膨胀。例如，一个拥有 1000 个用户、每人 30 个自定义字段的网站，wp_usermeta 表将包含 30,000 行数据。如果扩展到数万用户，数据量将极其庞大。
- 全表扫描噩梦：当执行复杂的过滤查询（如搜索特定价格范围的商品，或筛选特定属性的用户）时，由于 meta_value 字段通常被定义为 LONGTEXT 类型，MySQL 无法对其进行完整的默认索引。这会导致数据库被迫执行
全表扫描 (Full Table Scan)，在百万级数据下，查询耗时可能高达数秒。
2. 复杂查询与多表 JOIN 的灾难
Meta 表的设计极不适合用于搜索和过滤。
- JOIN 操作代价高昂：每次使用 meta_query 查询自定义字段时，WP 都必须在底层执行复杂的数据库表 JOIN 操作。在少量数据时可能不明显，但当文章或用户数量达到数千甚至数万时，这种多表 JOIN 会严重拖慢页面加载速度，甚至导致服务器崩溃。
- 缺乏原生索引优化：Meta 主要是为了通过 meta_key 快速提取数据而设计的，而不是通过 meta_value 进行搜索。如果强行通过值进行筛选，查询效率低。
3. 架构设计的局限性
- 缺乏预定义结构（Schema-less）：由于没有预定义的表结构，无法强制保证数据完整性。这使得基于 Meta 值进行排序、聚合或复杂关系建模（如一对多、多对多关系）变得非常困难且低效。
- 生态与插件的连锁反应：许多开发者误将自定义字段作为万能存储，导致 wp_postmeta 中充斥着大量垃圾数据。当安装多个使用 Meta 表的插件（如 Pods 等）时，表记录会迅速突破数万条，导致后台编辑表单或前端列表加载极其缓慢。
数据规范
在 G3-Web 中，禁止使用 postmeta 或 usermeta 表。
而是推荐把业务关联的扩展数据存储在独立数据表中。目的：
- 防止 meta 表过于臃肿，降低数据清理的管理成本。
- 随时断舍离：确保 meta 表无重要数据，不会为未来可能的系统升级与迁移造成数据负担。
- 提高查询效率：为复杂数据模型提供完整独立的支持。
- 根本保障：从数据源层，对中后期的系统无缝升级或迁移提供保障。
无缝迁移
当系统升级与迁移时，数据库无需任何变动，不需要服务暂停，无缝迁移。