我的数据库设计不佳。最重要的表之一有 11,000 多个条目。我们想扩展我们的系统，我想知道如果这个表增长到它的 5 倍大小，这会是一个问题吗？它的大小为 15360 kB……如果这很重要的话。
我用的是phpMyAdmin，服务器是Fedora Linux box（没什么花哨的），负载很轻。它存储了我们系统使用的几乎所有内容。
【问题讨论】：
标签： database database-design performance size
什么数据库管理系统？什么服务器？什么负载？什么应用？
此外：11.000 条记录真的不算什么。即使在 MS Access 中。 :-)
编辑： 所以我假设你使用一个相当新的 MySQL 和 MyISAM 表。理论上，您可以继续将表格填充到数百万条记录中。根据您使用它们的方式（是否有很多连接，是否有很多查询/更新/删除/不），您不需要做任何特别的事情。在桌子上放一个适当的索引，你应该没问题。
【讨论】：
我了解您担心如果将“设计不佳的数据库”中的记录数增加到 55.000 左右会影响性能。
如果您的系统现在按预期工作，我认为您应该可以处理 50.000 条记录，除非您已经有一些轻微的性能问题。
正如大多数人提到的，50k 记录相对于数据库表大小来说是一个非常小的数字，即使没有规范化的数据库也不应该存在性能问题。
如果您打算扩展系统的功能，那么也许现在也是查看数据库设计的好时机，否则保持原样应该是相当安全的。
【讨论】：
我认为您提供的信息不足以让某人给出答案。为什么设计不好？不是标准化了吗？你没有任何索引吗？它是什么数据库？它在什么操作系统上运行？现在从相关表中查询记录需要多长时间？
【讨论】：
11k 条目并不多。 50K也不大。
在表上放置索引（针对您将在其上运行的查询进行了优化）将获得比您预想的更大数量的良好性能。
如果设计不够糟糕，您可能会考虑重新设计的成本。
【讨论】：
“设计不佳的数据库”是什么意思？
如果设计不当，请重新设计，将信息从当前表格中拖出，然后填充新表格。
如果您关心性能，11000 个条目并不大。按照 db 标准，15 MB 的数据库非常小。
【讨论】：
桌子的大小不是很重要。键、索引和关系的设计与设计质量的关系远大于其中包含的数据大小。对此显然有一些警告；但是优化表的大小几乎是我在处理性能或设计问题时所做的最后一件事。
您可能想进一步解释为什么您认为这是一个设计不佳的数据库，以及您可以（轻松）采取哪些措施来纠正这些问题。除此之外，您还应该详细说明 DBMS 的类型和用途（Web 应用程序、自定义应用程序、报告等）。
【讨论】：
15MB 不算什么。 11k 行也是如此。我有超过 2 GB 数据的数据库，其中一些表包含超过 100 万行，我认为这介于中小型之间。
【讨论】：
您确实没有提供任何证据来支持您声称这是一个设计不佳的数据库。是什么让它设计不佳？表有 876 列吗？列是否命名为 Col1、Col2、Col3 ...？它是否使用浮点数和日期时间作为复合主键？归一化不好？我们唯一知道的是它的记录数。
【讨论】：
11K 记录在数据库方面通常不算什么。
除了一张表中的记录数之外，还有什么让您认为数据库设计不佳？
【讨论】：
您需要提供有关表结构的更多信息。
一般来说，一个表中的 15,000 行会被认为很小，实际上是如此之小，以至于一些设计人员甚至可能不会费心为其编制索引。
【讨论】：
糟糕的基础将是您最昂贵的错误。如果桌子很重要，那么您需要确定修复它的重要性。表中的行数只会影响您从中提取内容的速度。但是，如果您一开始就有一个糟糕的数据库设计，那么您的双手将在未来的某些地方束手无策。
【讨论】：
如果您谈论的是 SQL Server 2005，请查看 SQL Server profiler 并使用索引调整向导。
如果您需要额外的性能，某些数据库还支持将表固定到内存。
【讨论】：
记录的组成比表中有多少记录更重要。
在我工作的地方，我们的数据库中有许多表，记录数达到数万或数十万。在大多数情况下，我们的数据库都被认为很小。
【讨论】：
如果您要扩展系统，现在是时候重新设计（如果需要）了。拥有 11,000 条记录时重新设计比拥有 1000 万条记录时要轻松得多。但是，您所说的任何内容都没有向我表明您需要重新设计。拥有连接本身并没有错（事实上，一个设计良好的数据库应该拥有它们）。发布有关结构的一些详细信息，我们可以帮助您决定是否需要重新设计。
问题可能在于您和您的同事根本没有数据库访问经验，也不知道如何有效和轻松地查询它们。或者问题可能是设计不好，没有结构细节，很难说。
【讨论】：