一张 user_addresses 表，必须带 is_default 布尔字段（tinyint(1) default 0）和 user_id 索引，并用 unique index (user_id, is_default) 约束确保每用户至多一个默认地址。
收货地址表怎么建才不翻车
直接说结论：一张 user_addresses 表，必须带 is_default 布尔字段 + user_id 索引，且默认地址只能有一个——这个约束不能靠应用层“自觉”，得用数据库逻辑兜底。
常见错误是只加个 is_default TINYINT(1)，然后在代码里查 SELECT * FROM user_addresses WHERE user_id = ? AND is_default = 1，看似没问题。但并发新增/切换时，可能两个地址同时被标为 1，导致数据不一致。
- 用
UNIQUE INDEX (user_id, is_default)配合is_default只允许 0 或 1（不是 NULL），就能让数据库自动拒绝第二个is_default = 1的插入/更新 -
is_default类型建议用TINYINT(1) DEFAULT 0，别用BOOLEAN（MySQL 本质还是 TINYINT） - 别把“默认地址”单独抽成一张
user_default_address表——多一次 JOIN、多一次事务协调，还容易出现地址已删但默认记录残留
切换默认地址的 SQL 怎么写才安全
核心是原子性：把旧的设为 0，新的设为 1，必须在一个事务里完成，且要防止竞态。最简方案是用两行 UPDATE，但得加 WHERE 条件避免误清。
错误写法：UPDATE user_addresses SET is_default = 0 WHERE user_id = ? —— 这会清掉用户所有地址的默认标记，哪怕新地址还没设上。
- 正确做法分两步（放在同一事务中）：
UPDATE user_addresses SET is_default = 0 WHERE user_id = ? AND is_default = 1UPDATE user_addresses SET is_default = 1 WHERE id = ? AND user_id = ? - 第二条 UPDATE 必须校验
user_id，防止越权操作（比如 A 用户传了 B 的地址 ID） - 如果用 ORM，别依赖“先查再改”的链式调用，查和改之间可能被其他请求插队
查询用户默认地址时为什么总查不到
不是逻辑错，大概率是索引没起作用或数据状态异常。
典型现象：执行 SELECT * FROM user_addresses WHERE user_id = 123 AND is_default = 1 返回空，但手动检查发现确实有一条 is_default = 1 的记录。
- 检查
is_default字段是否允许 NULL —— 如果某条记录是NULL而不是0，那= 1就永远不匹配（NULL != 1） - 确认有没有联合索引：
INDEX idx_user_default (user_id, is_default)，否则单列索引在高并发下可能走全表扫描，还容易被优化器忽略 - 注意字符集/排序规则影响（极少，但若表用 utf8mb4_0900_as_cs，而应用传参用了不同 collation，也可能隐式转换失败）
MySQL 8.0+ 可以用生成列简化吗
可以，但没必要。有人想用 GENERATED ALWAYS AS (CASE WHEN is_default = 1 THEN user_id END) 再建唯一索引，试图“强制单默认”。实际踩坑不少：
- 生成列必须是 STORED 才能建索引，增加存储开销
- MySQL 对生成列的 UPDATE 支持有限，某些 ORM 会绕过生成逻辑直接写值，导致索引失效
- 不如老老实实用
UNIQUE (user_id, is_default)直观可靠
真正值得升级的是用 MySQL 8.0 的 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY is_default DESC, updated_at DESC) 做兜底查询——当默认标记异常时，至少能取最新一条当 fallback，但这属于应用层容错，不是建表逻辑本身。
