数据量过大该如何分表比较合适

说实话 几百万的数据 压根用不到分表

就是目前的话已有10个工地 卖打卡考勤设备装置的 理论上不是10个工地随着销售额会一直上涨

如果打卡仅仅是插入而没有查询的话那瓶颈应该不在数据库上面，可以考虑从以下方面排查：

• 网络带宽，打卡时间段是不是带宽一直处于满载状态，如果是可以考虑提升带宽。

• 如果是运行在 PHP-FPM 下瞬时流量激增会因为文件 IO 次数过多从而严重影响性能 ，调整 PHP-FPM 参数不能解决问题，可以试试加入 Swoole 等组件来托管运行 Laravel，能够大大减少文件 IO，性能应该能提升一大个台阶；当然加服务器使用负载均衡是最简单的办法。

• 典型的写多读少的场景，应该优先考虑使用缓存组件来实现功能。

几百万数据确实不需要分表，特别是这种签到数据，存进去了基本不会用到

一个工地一张表吧，省心一整年。

有很多种方案，例如上面有的老哥说的，一年一张表，省心好维护，也可以按照工人信息的id者求余，然后分到不同的表；还可以把打卡记录放在非关系型数据库mongodb、redis里，不走数据库，然后做好统计表，减少数据库读写，也能提升速度，然后再加上队列走异步，不要太爽！

打卡没必要实时存数据库，可以将数据先存redis，再异步或者定时，将数据根据（用户ID或者工地ID--那个方便后续操作用哪个）取模存进对应的表。

可以参考redis的setbit 博客：如何利用 Redis 快速实现签到统计功能

非得分的话，比较惯例的做法是一天一个表，不管几个工地。 这应该能支撑到业务足够大了。