在我的模式中，我已经规范化了我的数据库，并且到处都有FKs，因为在一个社交网络中有太多的链接关系，esp将用户链接到所有东西。
现在很明显，在社交网络中的表现将决定成败。这意味着“读”的时间比“写”的时间更重要。我的数据库是MySQL，所有表都是InnoDB。所以问题是：
1）我认为我的设想是读比写更好是社交网络所需要的？
2）有许多FKs（我估计每个表中有30%的列有FKs），这会影响读性能还是写性能，或者两者都有，或者都没有？
3）最好为每个表设置两组表—一组用于选择（读取）和一组用于插入（写入），使用不同的模式，以便可以相应地设计它们以获得更好的性能？
4）如果我把80%的colunms说成fks有什么坏处吗？（请记住，这是一个社交网络，以后可能会或不会有大量流量）
最佳答案
1）我认为我的设想是读比写更好是社交网络所需要的？
一般来说，内容读得比写得多。但听起来你做了很多过早的优化。
2）有许多FKs（我估计每个表中有30%的列有FKs），这会影响读性能还是写性能，或者两者都有，或者都没有？
声明外键与性能几乎没有关系。
要么你的数据库是标准化的，要么不是。在你知道你的表现有问题之前，不要试图打破正常化。
3）最好为每个表设置两组表—一组用于选择（读取）和一组用于插入（写入），使用不同的模式，以便可以相应地设计它们以获得更好的性能？
你是说在这里执行materialized views吗？听起来像是过早的优化-如果您认为它可能会使用视图访问当前的数据，那么在将基础实体替换为具体化视图之前，请等到您知道存在性能问题。
4）如果我把80%的colunms说成fks有什么坏处吗？（请记住，这是一个社交网络，以后可能会或不会有大量流量）
不-和上面一样-把你的数据正常化。声明你的FKs，等到你遇到性能问题之后再尝试修复它。