战斗数据（角色属性、技能参数）如何存储？请说明数据库设计（如表结构、索引、分库分表策略），并解释如何保证数据一致性和查询效率。

1) 【一句话结论】战斗数据存储以关系型数据库为核心，通过合理设计表结构（角色、技能、属性表）、索引优化查询效率，并采用分库分表策略应对数据量增长，结合事务机制保证数据一致性。

2) 【原理/概念讲解】
老师：咱们先说表结构设计，战斗数据通常拆分为角色表、技能表、属性表等。比如角色表存基础属性（角色ID、等级、生命值hp等），技能表存技能参数（技能ID、伤害值damage、冷却时间cooldown等），属性表关联角色和技能（如角色使用技能后的额外属性值）。
索引是加速查询的关键，比如给角色ID、技能ID建主键索引（B+树结构），能快速定位数据。
分库分表是为了应对数据量爆炸，水平分库按角色ID范围拆分数据库（如库1存ID1-1000，库2存1001-2000），水平分表按技能类型拆分表（如攻击技能表、辅助技能表）。
数据一致性用事务（ACID），比如修改角色生命值和技能冷却时，用事务保证原子性，避免数据不一致。

3) 【对比与适用场景】

策略	定义	特性	使用场景	注意点
水平分库	按数据范围（如角色ID）拆分到不同数据库实例	每库数据量可控，独立扩容	角色数量百万级（如大型MMO）	跨库查询复杂，需分布式事务
垂直分库	按业务模块拆分（如战斗数据、技能数据）	模块独立，减少耦合	多业务模块，数据量差异大	模块间数据关联需跨库操作
水平分表	按数据范围或时间拆分表（如技能表按类型分表）	单表数据量可控，查询范围缩小	技能类型多，单表数据量大	分表后查询需处理分片键
索引类型	B+树索引（如MySQL InnoDB）	支持范围查询，查询效率高	通用查询场景（如按ID、范围查询）	存储空间稍大，更新时维护成本高
哈希索引	哈希表结构（如Redis Hash）	等值查询效率极高	精确匹配查询（如按技能ID查）	不支持范围查询，数据倾斜风险

4) 【示例】

• 表结构：
  role（角色表）：role_id INT PK, name VARCHAR, level INT, hp INT, mp INT, attack INT
skill（技能表）：skill_id INT PK, name VARCHAR, damage INT, cooldown INT, type ENUM('attack','heal')
attribute（属性表）：attribute_id INT PK, role_id INT FK, skill_id INT FK, value INT
• 分库分表示例：
  水平分库：库1存role_id 1-1000，库2存role_id 1001-2000；
  水平分表：技能表按type拆分，skill_attack（攻击技能）、skill_support（辅助技能）。

5) 【面试口播版答案】
“战斗数据存储以关系型数据库为核心，表结构设计上，角色表存基础属性（ID、等级、生命值等），技能表存参数（伤害、冷却等），属性表关联角色和技能。索引方面，给角色ID、技能ID建主键和索引，加速查询。分库分表的话，水平分库按角色ID范围拆分数据库，水平分表按技能类型拆分表，比如攻击技能单独一个表。数据一致性用事务，比如修改角色生命值和技能冷却时用事务，保证原子性。查询效率通过索引和分表优化，避免全表扫描。总结来说，通过合理设计表结构、索引和分库分表，结合事务保证一致性，提升查询效率。”

6) 【追问清单】

• 问：分库分表后，跨表查询（如角色技能数据）怎么处理？
  答：用分布式事务（如两阶段提交）或微服务架构，将查询拆分为多个子查询，通过服务间调用获取数据。
• 问：索引选择上，为什么用B+树而不是哈希？
  答：B+树支持范围查询，技能参数可能需要按冷却时间排序或范围查询，哈希只能等值查询。
• 问：数据量增长时，分库分表如何扩展？
  答：水平分库按角色ID范围动态扩容，水平分表按技能类型新增表，保持分片键一致。
• 问：事务隔离级别如何选择？
  答：用读已提交（Read Committed），避免脏读，同时保证并发性能。
• 问：如果角色数据频繁更新（如战斗中实时修改生命值），如何优化？
  答：用缓存（如Redis）缓存热点数据，减少数据库压力，数据库只写缓存数据。

7) 【常见坑/雷区】

• 分库分表导致跨表查询复杂，需额外设计分布式事务或微服务，否则影响性能。
• 索引选择不当，如为非查询字段建索引，导致存储空间浪费和更新性能下降。
• 事务隔离级别过高（如串行化），导致并发性能下降，影响游戏体验。
• 分库分表后，分片键设计不合理，导致数据倾斜（如所有角色都存入同一个库或表）。
• 缺少缓存策略，数据库压力过大，导致查询延迟。