设计一个游戏用户系统的数据库表结构（如用户表、角色表、等级表），考虑高并发下的读写分离、分库分表策略，以及索引优化。请说明每个表的设计思路（如用户表的主键选择、角色表的索引设计），以及如何通过数据库分片（如Sharding）提升查询性能。

游卡Golang开发难度：中等

答案

1) 【一句话结论】
游戏用户系统数据库设计需结合全局ID（雪花算法）、分库分表（哈希分片+时间分区）、读写分离及索引优化，通过主键、索引、分片策略应对高并发，提升读写性能与数据一致性。

2) 【原理/概念讲解】

主键设计：避免自增ID分片倾斜，采用雪花算法（时间+机器ID+序列号）生成全局唯一ID，确保数据均匀分布。
读写分离：主库（写）与从库（读）通过主从复制，路由服务分发请求，提升读吞吐量，类比“总账与分账”，读操作去分账，写操作去总账。
分库分表：水平切分（按用户ID哈希分库）与垂直切分（按字段拆分），解决单库容量与性能瓶颈。分库分表通过数据分散提升并发处理能力。
索引优化：根据查询场景选择索引类型（B树索引用于范围查询，哈希索引用于等值查询），减少全表扫描，但需权衡索引维护成本（写性能）。

3) 【对比与适用场景】

对比项	读写分离	分库分表
定义	主库写+多从库读的复制架构	水平/垂直切分数据库，分散数据
特性	读高并发，写集中；延迟低（从库同步）	扩展性（容量/性能），跨库事务复杂
使用场景	读多写少（如用户查询、日志）	写多读多（如游戏用户、交易）
注意点	从库延迟、数据一致性	分片键选择、跨库查询、事务一致性

4) 【示例】

用户表（user）：

CREATE TABLE user (
  user_id BIGINT PRIMARY KEY,  -- 雪花算法生成的全局ID
  username VARCHAR(50) UNIQUE NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

主键：雪花算法ID，避免自增ID分片倾斜。

角色表（role）：

CREATE TABLE role (
  role_id BIGINT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  role_type ENUM('player', 'vip', 'admin') NOT NULL,
  create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE CASCADE
);

索引：按user_id建主键（关联用户表），按user_id+role_type建复合索引（加速按用户查询角色）。

等级表（level）：

CREATE TABLE level (
  level_id BIGINT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  level_num INT NOT NULL,
  exp INT NOT NULL,
  create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (user_id) REFERENCES user(user_id) ON DELETE CASCADE
);

索引：按user_id+level_num建复合索引（加速按用户和等级查询）。

分库分表策略：
- 分库：按user_id哈希（如user_id % 8）分配到8个库（库1-8），每个库独立部署。
- 分表：按create_time分区（如user_2023_01、user_2023_02），role表按create_time分区，level表按create_time分区。
- 分片查询：通过路由服务（如ShardingSphere）根据user_id哈希定位库，再根据分区规则定位表，合并结果集。

5) 【面试口播版答案】
“面试官您好，针对游戏用户系统，我设计表结构时，核心是解决高并发下的读写与扩展问题。首先，用户表用雪花算法生成全局ID作为主键，避免自增ID分片倾斜。然后采用读写分离，主库写，从库读，通过路由服务分发请求，提升读性能。分库分表上，按用户ID哈希分库（比如8个库），按时间分区（月/年），解决单库瓶颈。索引优化方面，用户表主键建索引，角色表按用户ID+角色类型建复合索引，等级表按用户ID+等级数建索引，减少全表扫描。分片策略通过路由服务，根据用户ID哈希定位库和表，合并结果，提升查询性能。这样既能应对高并发，又能保证数据一致性和扩展性。”

6) 【追问清单】

问题1：分片键选择依据？
回答要点：用户ID哈希分片，均匀分布数据，适合写多读多的场景，但需注意数据迁移困难。
问题2：跨库事务处理方案？
回答要点：通过分布式事务（如两阶段提交、Saga模式）解决，或限制事务范围（如只涉及单库）。
问题3：索引过度优化的风险？
回答要点：索引维护成本高（写操作慢），需平衡查询性能与写性能，避免冗余索引。
问题4：分片后查询性能？
回答要点：通过路由服务合并结果集，但跨库查询可能影响性能，需优化分片键设计。

7) 【常见坑/雷区】

主键选自增ID：导致分片不均（如ID连续，分片倾斜），建议用UUID+时间戳（雪花算法）或全局ID生成器。
分片键选用户ID但活跃度不均：部分库压力过大，需结合用户活跃度（如按用户ID哈希+活跃度加权）。
索引设计错误：未考虑查询场景（如按用户ID查询角色，未建索引），导致全表扫描。
读写分离延迟忽略：未考虑从库延迟，导致读操作超时。
分片后跨库查询复杂：未优化分片键，导致跨库查询性能下降。