84669 人学习
152542 人学习
20005 人学习
5487 人学习
7821 人学习
359900 人学习
3350 人学习
180660 人学习
48569 人学习
18603 人学习
40936 人学习
1549 人学习
1183 人学习
32909 人学习
我的思路是 商铺 shop 是一个表，用来保存商铺的信息。然后一个交易表，存在字段shop_id,存储所有商铺的交易记录信息。
这样的表设计在数据量大的时候是否会有影响，有没有更好的办法，例如每个商铺的交易记录都是一个表，但是感觉不好实现，因为商铺是可以动态添加的。
Mysql 在上千上万条记录中表现很好，这种设计可以跑的同，但是一个商铺有十个订单平均，那么商铺和订单数据是10倍映射，当订单数量相当大的时候影响性能。数据库表也可以动态添加啊。所以你可以对订单记录进行分表处理。但是不能用自增的shop_id 作为外键，因为你分表后，自增的id 基数回到零，就算可以手动设置，这样很不方便，所以外键最好自己生成，方便分表。生成唯一id的方法很多，你可以自己设计一套。
纠正一下我上面说的，其实我在开发中很少用到外键，外键这个东西是一个双刃剑，建议看一下为什么在开发中尽量避免用外键
Mysql 在上千上万条记录中表现很好，这种设计可以跑的同，但是一个商铺有十个订单平均，那么商铺和订单数据是10倍映射，当订单数量相当大的时候影响性能。数据库表也可以动态添加啊。所以你可以对订单记录进行分表处理。但是不能用自增的shop_id 作为外键，因为你分表后，自增的id 基数回到零，就算可以手动设置，这样很不方便，所以外键最好自己生成，方便分表。生成唯一id的方法很多，你可以自己设计一套。
我的理解就是设计一个商铺表，还有一个交易表，交易表的外键是商铺表的主键，总的来说，MySQL还是可以抗住很大的压力的，再就是可以利用一些开源的解决方案，或者订单表做定期分表，关键看你怎么实现。
纠正一下我上面说的，其实我在开发中很少用到外键，外键这个东西是一个双刃剑，建议看一下为什么在开发中尽量避免用外键