寻找一些反馈-我正在构建一个社交网络类型的软件-该功能之一允许用户发布新闻报道并让朋友发表评论。过去，我为新闻，评论，日历事件等保留了不同的表。但是，有一位朋友将我转到了“ POSTS”和“ post_types”的wordpress类型数据库结构中，其中所有内容都在一个表中并具有一个“ post_type”。
这意味着新闻报道，评论，事件等都在同一表中。我喜欢创建更新一个表的函数的效率。但是，我的旧软件中有一个表有150万行，我希望这个新表在第一年会增长到大约1000万行。
只要索引设置正确，mysql是否可以处理这种大小的数据，或者出于这个原因将所有内容拆分到单独的表中更聪明？
答案 0 :(得分：0)
没有一般性答案。这取决于。
MySQL处理大型表没有问题。但是，它不会为您创造奇迹。最后，一切都与效率有关。这意味着您需要针对多个相互排斥的目标优化设计。您想要找到的是复杂性，性能，可扩展性和维护成本之间的最佳结合点。每个项目都不同，这是一种艺术。
通常不希望混淆太多不同的内容。这就是为什么他们几乎在每本数据库书或CS课程中都讲授数据规范化的原因。如果您的数据很小，那么这并不重要。但是，如果您有大量数据和大量请求，则几乎可以肯定，您希望从数据库中压缩性能的每一个下降。因此，您不仅要分离表，检查索引，检查执行计划，更新统计信息，对页面进行碎片整理和衡量性能，而且还将使用分区，集群，物化视图，只读副本，I / O和CPU并行性， SSD，Memcached和其他各种工具。如果您从不良的数据模型入手，这将更具挑战性。以我个人的经验，除非您能以某种方式无需交易而生活，否则锁定确实会伤及大桌子。
要进行各种估算，您需要有一些性能基准。仅知道记录数是不够的。会有多少个请求？查询将做什么？您在哪里期望最重的负载？您是否可以准备系统大多数时间将要运行的最常见查询？高峰时间呢？哪些硬件可用于运行此负载？读写比率是多少？等等
要进行优化，您需要某种目标。与往常一样，您会发现为了到达那里，您必须付出一些代价。因为您可能还没有所有这些答案，所以请尝试遵循极简主义的原则-从小处着手，进行测量，分析，改善，重复。