mysql 表结构 - 一个非常大的表或单独的表？答案

【问题标题】：mysql tables structure - one very large table or separate tables?mysql 表结构 - 一个非常大的表或单独的表？
【发布时间】：2010-10-10 17:56:54
【问题描述】：

我正在从事一个与网站访问者分析性质相似的项目。它将被数百个网站使用，每个网站平均每天的页面访问量在 10,000 到 100,000 次，因此数据量非常大。

我应该使用带有 websiteid 的单个表还是为每个网站使用单独的表？

对包含 100 多个网站的实时服务进行更改，每个网站都有单独的表格，这似乎是一个大问题。另一方面，性能和可扩展性可能会成为如此大数据的问题。欢迎任何建议、cmets 或建议。

【问题讨论】：

标签： mysql performance large-data-volumes

【解决方案1】：

网站 FK 的一张表partitioned 怎么样？

【讨论】：

只是说我同意这一点，PK/FK 上的水平分区。
谢谢，我正在检查这个选项

【解决方案2】：

我会说根据您的数据使用最有意义的设计 - 在这种情况下是一张大表。

记录都是相同的类型，具有相同的列，因此从数据库规范化的角度来看，将它们放在同一个表中是有意义的。索引使选择特定行变得容易，尤其是当单个索引中的数据可以满足整个查询时（通常是这种情况）。

请注意，访问者分析必然涉及许多操作，除了一次对大量行进行操作外，没有简单的优化方法，例如：计数、总和和平均值。像这样的资源密集型统计数据通常是预先计算和存储的，而不是实时获取的。这是你想要考虑的事情。

【讨论】：

谢谢！有人知道阅读此类系统及其架构的好地方吗？
好吧，如果您想进行一些搜索，StackOverflow 可能会非常好。另外 mysqlperformanceblog.com 我认为很好，尽管您可能需要再次搜索一下。很难推荐的东西，你可以试着问另一个我猜的问题。

【解决方案3】：

如果数据是统一的，就用一张表。如果您需要在所有网站上进行选择拥有多张桌子很痛苦。但是，如果您编写了足够多的脚本，则可以使用多个表来完成。

您可以使用 MySQL 的 MERGE 存储引擎跨表执行 SELECT（但不要期望有好的性能，并注意 Windows 对打开文件数量的硬限制 - 在 Linux 中，您可能必须使用 ulimit 来提高限制。在 Windows 中没有办法做到这一点。

我将一个巨大的表分解为许多（数百个）表，并使用 MERGE 来选择。我这样做是为了可以离线创建和优化每个小表。（例如 OPTIMIZE 或 ALTER TABLE...ORDER BY）。然而 SELECT 与 MERGE 的性能使我编写了自己的自定义存储引擎。（描述 http://blog.coldlogic.com/categories/coldstore/'>这里）

【讨论】：

【解决方案4】：

使用单一数据结构。一旦你开始遇到性能问题，有很多解决方案，比如你可以通过网站 id 对表进行分区，也称为水平分区，或者你也可以使用复制。这一切都取决于读取与写入的比率。

但首先要保持简单，并使用具有适当索引的表。您还可以确定是否需要交易。您还可以利用各种不同的 mysql 存储引擎，如 MyIsam 或 NDB（内存集群）来提高性能。缓存在从数据库中卸载负载方面也起着非常好的作用。大部分只读且易于计算的数据通常放在缓存中，缓存为请求提供服务，而不是进入数据库，只有必要的查询才会进入数据库。

【讨论】：

【解决方案5】：

除非您在使用 MySQL 时遇到性能问题，否则请使用一张表。

这里没有人不能回答性能问题，你应该自己做性能测试来了解，一张大桌子是否足够。

【讨论】：