MySQL对强关系核心数据仍是首选，但需合理设计：用户表加手机号和邮箱唯一索引并设NOT NULL；资源状态用TINYINT或ENUM+注释，配复合索引；租借表建三类复合索引，避免SELECT*和大表膨胀；高并发需应用层配合乐观锁或Redis预占。

MySQL 在共享经济平台中不是万能的，但对资源和用户这类强关系、需事务保障的核心数据，它仍是首选方案——前提是设计得当，否则容易在高并发抢购、实时状态更新等场景下出现锁表、脏读或延迟。

用户表必须用 UNIQUE 约束手机号和邮箱

共享平台常允许用户用手机号或邮箱注册，且需防止重复。仅靠应用层校验不可靠，数据库层必须加唯一索引。

• UNIQUE KEY uk_phone (phone) 和 UNIQUE KEY uk_email (email) 都要建，不能只依赖其中一个
• 注意：MySQL 对 NULL 值的 UNIQUE 索引处理特殊——多个 NULL 不冲突，若字段允许为空，建议设为 NOT NULL DEFAULT ''
• 注册接口需捕获 Duplicate entry 错误码（1062），而不是查完再插，否则存在竞态漏洞

资源表的状态字段别用字符串枚举

比如单车、充电宝、工位的状态（'available' / 'in_use' / 'maintenance'）若直接存字符串，查询慢、易拼错、难扩展。

• 改用 TINYINT UNSIGNED 或 ENUM('0','1','2')，并用注释或外部字典映射语义（如 0 → available）
• 搭配 INDEX(status, updated_at) 支持「查所有可用资源」+「按更新时间排序」这类高频查询
• 避免在 WHERE status = 'in_use' 中用字符串比较——MySQL 无法有效利用索引，尤其当表超百万行时

租借记录表必须有复合索引覆盖常用查询路径

用户查自己的历史订单、运营查某设备全部使用记录、风控查某时段异常频次……这些查询都依赖不同字段组合，单列索引效率低。

• 至少建三个索引：INDEX(user_id, created_at)（用户视角）、INDEX(resource_id, created_at)（设备视角）、INDEX(created_at, status)（运营统计）
• 不要用 SELECT * 查租借记录，尤其带 JOIN 用户/资源表时——大促期间可能拖垮连接池
• 超过 6 个月的历史记录建议归档到 rental_log_2025_q2 这类分表，避免主表膨胀影响 UPDATE 性能

CREATE TABLE rental_record (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  resource_id BIGINT NOT NULL,
  status TINYINT NOT NULL DEFAULT 0 COMMENT '0:pending,1:success,2:failed',
  created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  INDEX idx_user_time (user_id, created_at),
  INDEX idx_resource_time (resource_id, created_at),
  INDEX idx_time_status (created_at, status)
) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;

真正难的不是建表，而是当一个“可用车位”被 50 个用户同时点击时，怎么让 UPDATE ... SET status = 1 WHERE id = ? AND status = 0 不变成排队队列——这需要配合应用层的乐观锁或 Redis 预占，MySQL 单独扛不住。