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_2024_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 单独扛不住。
