1. 设计目标与原则
1.1 数据完整性与规范化
在买菜系统中，用户的收货地址需要保证完整性与一致性，避免重复数据，同时支持多地址、默认地址等场景。
在测试阶段，可以把 temperature=0.6 作为数据生成的温度参数，用来控制地址字段的分布与多样性。
采用严格的数据类型与约束，确保每条地址记录都具备唯一性和可追溯性；并且通过软删除标记、时间戳等机制，保证历史变更可审计与回滚。
1.2 性能与扩展性考量
考虑到查询常聚焦某个用户的地址集合，按 user_id 建立索引，并在地理信息字段上使用数值外键引用区域表以减少重复文本。
未来扩展，可以通过区域表（region 表）实现地区数据的分层管理，从而提升数据一致性与查询性能。
2. 数据库表结构概览
2.1 架构设计要点
系统将收货地址设计为独立表，与用户表通过 user_id 外键关联，便于扩展多地点、跨商家场景。
为未来扩展提供空间，例如通过 region_region 表 或区域表进行分级管理，提升数据一致性。
3. 用户收货地址表的字段设计
3.1 字段清单与数据类型
核心字段包括 地址标识、用户标识、收货人、手机、地区 ID、详细地址等，并用时间戳记录创建与更新时间以便追溯。
另外，常用字段如 是否默认地址、邮编、地址标签，帮助前端快速渲染与排序。
CREATE TABLE user_address (id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,user_id BIGINT UNSIGNED NOT NULL,recipient_name VARCHAR(64) NOT NULL,phone VARCHAR(20) NOT NULL,province_id INT NOT NULL,city_id INT NOT NULL,district_id INT NOT NULL,detail_address VARCHAR(255) NOT NULL,postal_code VARCHAR(20),is_default TINYINT(1) NOT NULL DEFAULT 0,address_label VARCHAR(32),created_at TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),updated_at TIMESTAMP(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),deleted_at TIMESTAMP(6) NULL,PRIMARY KEY (id),KEY idx_user_id (user_id),KEY idx_default (is_default),KEY idx_region (province_id, city_id, district_id),CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
以上字段设计确保了地址数据的完整性、可检索性以及对前端展示的友好性。时间戳字段能够帮助实现历史追踪与变更审计。
3.2 进阶字段与约束
为了避免同一用户存在重复地址，增加唯一性策略或软删除字段，在查询时排除 deleted_at IS NULL 的记录。
同时，对 province_id/city_id/district_id 使用区域表引用，以实现地区数据的一致性与可维护性。
4. 关系建模与数据完整性
4.1 外键与级联策略
通过 外键约束 将 user_address 与 users 表关联，ON DELETE CASCADE 确保用户删除时地址也删除，避免孤儿记录。
对于区域表，若采用区域表 regional(id, name, parent_id, level)，可以通过外键约束连接 province_id、city_id、district_id。
4.2 去重与唯一性约束
实现去重策略时，考虑在应用层校验和数据库唯一性约束的组合，如（user_id, province_id, city_id, district_id, detail_address）组合的唯一性。
如果采用逻辑唯一性，可以添加一个 联合唯一索引，以避免同一用户重复添加同一地址。
5. 常见查询与索引策略
5.1 常用查询模板
查询某用户的全部地址时，以 user_id 为筛选条件，并按 is_default DESC, created_at DESC 排序，方便默认地址优先展示。
按区域筛选地址时，可以使用区域表的 id 与路径进行连接查询，以实现模糊或精确匹配。
5.2 索引设计要点
对于高并发的买菜场景，主键写入之外的查询要有覆盖索引，如 idx_user_id、idx_region，以及必要的覆盖字段。
对于经常更新的 is_default 字段，避免引起大范围的行锁，可以优先让默认地址通过筛选单独缓存。
6. 兼容性与扩展性策略
6.1 地区数据表分离与区域表
建议把地区信息拆离到独立的 regionRegion 表，通过 region_id 进行外键引用，方便日后多语言或跨区域扩展。
对于跨商家场景，可以通过 商家地址域 表实现地址的域级隔离。
6.2 跨版本演进
在表结构变更时，采用 向前兼容的字段默认值，以及通过 版本表 跟踪 schema 演进。
对于历史记录，需要考虑 软删除标记，以便回滚和审计。
7. 数据迁移与版本控制
7.1 备份与回滚
在实现收货地址表变更前，执行数据备份，以防回滚；同时保留 旧字段的兼容性处理，直到迁移完成。
回滚策略应包括 DROP/ADD COLUMN 的原子性和事务性处理。
7.2 在线迁移策略
在线迁移时，采用 非阻塞的表改造，通过添加新字段、创建新临时表以及无痛 data copy，降低上线风险。
8. 安全与隐私
8.1 数据脱敏与访问控制
对敏感信息如 收货人姓名、电话在前端展示时使用脱敏策略，数据库层也可实现字段级加密或掩码存储。
实行基于角色的访问控制，确保只有授权服务或人员可访问地址表数据。
8.2 审计与日志
记录地址的新增、修改和删除的 审计日志，便于问题追溯和合规要求。
