动态创建每个帐户或几个大表的mysql表

Question

什么是更优化的数据库设计方式？

我正在构建一个应用程序，其中不同的公司注册并添加其用户并使用该应用程序。每个帐户最多需要10个表。 e.g

table1, table2, table3..table10

这就是我目前正在做的事情，有10个表并将所有帐户的所有信息存储到这些表中。但我有一个想法，它可以横向扩展我的数据库设计。因此，这个想法是每当有人创建公司帐户时，我的应用程序将动态创建这些表，如下所示：

c_31_table1, c_31_table2, c_31_table3...c_31_table10

31是加入公司的例子吗？我的假设是因为SQL只是垂直增加，否则随着时间的推移它会变慢，将来每个表大约有4万条记录或更多。因此，这种方法将保持数据库的垂直长度，并水平缩放。

这种技术是一种很好的优化技术吗？

Answer 1

通常不是一个好主意。每种情况都不同。有了这个，你就不会受益于查询缓存（同样多）。您的查询需要预先做更多的工作（不多）。并且存储的proc，func和事件需要CONCAT，PREPARE，EXECUTE和DEALLOCATE PREPARE。

正确的索引和多租户应该是您的焦点，直到您遇到问题，这可能需要很长时间。我会专注于此处，并在您开发时使用EXPLAIN输出。描述您的代码。总是在剖析。找出例程慢的地方并修复它们。

你的拟议解决方案会有一个笨重的家务管理混乱。他们不容易清理自己。此外，即使有时，DDL电话也不便宜。

如果我在一个突然想要命名表的地方工作，比如

c_31_table1, c_31_table2, c_31_table3...c_31_table10

我会放弃。

Answer 2

我认为这种方法可以作为早期优化的一种情况＆＃34;。

只有4万行，个别＆＃34;公司本身不会造成任何重大负担。你会＆＃34;毒害＆＃34;您的应用程序代码具有优化效果，即使当前负载不需要它。

当公司的数量增长时（可能在您远远超过1000家公司之前），您可能需要引入一些优化。然后你可能会例如考虑将分区视为减少＆＃34;垂直＆＃34;长度。

但请保持您的应用程序免受此类优化。否则，您将在申请的整个生命周期内付出高昂的代价。

另一方面：

允许DDL调用会暴露您可能不希望暴露的特权。