MySQL高尔夫成绩库回合信息存储方案咨询：单表vs分表

作为经常处理这类数据模型的开发者，我来给你拆解这两种方案的优劣，从性能、可维护性、扩展性三个核心维度说清楚：

方案一：单表存储所有球洞数据 #

优点 #

• 单回合查询速度略快：不用关联其他表，一次SELECT就能拿到该回合所有18个洞的信息，对于只看单回合详情的场景，操作简单。
• 结构直观：刚接触的人一眼就能看懂，不用理解表关联关系。

缺点 #

• 反范式设计的典型坑：18组重复字段（比如hole1_shots、hole1_stableford...hole18_putts），冗余度极高。以后要是想加一个球洞字段（比如up_and_down救球成功），你得一次性加18个新字段，维护成本爆炸。
• 存储空间浪费：如果是9洞回合，剩下9组字段全是空值，纯粹占地方。
• 统计分析噩梦：比如想查所有回合里par3球洞的平均推杆数，你得把hole1_putts到hole18_putts里对应par3的字段挨个聚合，代码又长又容易出错，后期维护根本没法搞。

方案二：分表（rounds + scores） #

优点 #

• 完全符合数据库范式设计：这才是合理的关系型数据库建模方式。rounds存回合基础信息（日期、球员ID、球场ID等），scores表每条记录对应一个球洞的成绩，通过round_id关联。
• 扩展性拉满：以后要加球洞字段，只需要在scores表加一列就行，不用动rounds表，也不用加一堆重复字段。
• 统计分析超级灵活：比如查所有回合的平均推杆数，直接写AVG(putts)；想统计某球员所有par5球洞的稳定分，只需要加个WHERE hole_par = 5的条件，轻松搞定各种复杂统计。
• 无冗余存储：9洞回合就存9条记录，18洞存18条，没有空值浪费空间。

性能分析 #

很多人担心join会影响性能，但实际情况是：只要给scores表的round_id字段加个索引，MySQL处理这种关联查询的效率极高。哪怕你的系统有几万甚至几十万条回合记录，这个join的开销几乎可以忽略不计。真到了百万级数据量，方案二的优化空间也比方案一大（比如分表、加复合索引），而方案一单表的字段冗余会让数据文件越来越大，反而影响查询性能。

最终结论 #

优先选择方案二，除非你的系统极端简单——这辈子都不会加字段、不会做任何统计分析，只需要存数据和查看单回合详情。但这种场景几乎不存在，高尔夫成绩系统肯定会涉及到各种统计（比如球员平均成绩、球场难度分析等），方案二的可维护性和扩展性完全碾压方案一，性能上的微小劣势完全可以通过索引弥补。

内容的提问来源于stack exchange，提问作者davidjh