.
现在面对一个相当复杂的业务逻辑，所以试图用中间表切割掉它——
初步估计，这个中间表有120万条数据，但为了业务需要，这个表其实存储了两类数据：每个用户有一条、每周/月/季度的统计数据为一条，status鉴别类型。（见下方表结构）
故而，绝大多数数据的后一类（三个字段），都是空的。（我看数据库内的其他表，有相当多的字段的值都是0或者null，才出此下策）
大致的表结构（不严谨）：
| userid | groupid | status | sales(99%为空) | createtime(99%为空) | lasttime(99%为空) | endtime(99%为空) |
想了解：
这个数据量的空字段，是否会对效率形成影响？
除了分表之外，还有什么解决方案吗？
这种设计表的活，需要后端程序来做吗？无力感满满的。
回复内容： .
现在面对一个相当复杂的业务逻辑，所以试图用中间表切割掉它——
初步估计，这个中间表有120万条数据，但为了业务需要，这个表其实存储了两类数据：每个用户有一条、每周/月/季度的统计数据为一条，status鉴别类型。（见下方表结构）
故而，绝大多数数据的后一类（三个字段），都是空的。（我看数据库内的其他表，有相当多的字段的值都是0或者null，才出此下策）
大致的表结构（不严谨）：
| userid | groupid | status | sales(99%为空) | createtime(99%为空) | lasttime(99%为空) | endtime(99%为空) |
想了解：
这个数据量的空字段，是否会对效率形成影响？
除了分表之外，还有什么解决方案吗？
这种设计表的活，需要后端程序来做吗？无力感满满的。
如果字段不会用到就把他去掉吧
如果有可能会用到留着问题也不大，查询的时候指定需要的字段去查询也没有影响