我有一个现有的系统（在php上，mysql在aws ec2和rds上）。mysql（innodb）as数据库的当前统计数据总大小为600gb（来自phymyadmin），包含我的程序所需的近150个表。在这两个表（order，order\u items）中，每个表的容量都超过200gb。
在数据库不断增长的同时，我们发现了一些问题。1任何数据库架构中的更新都需要花费太多时间才能获取新功能更新。2长期保持同一种数据结构是否有好处，因为随着我们的增长，我们期望得到更大的数据（以tb为单位）？
为了解决问题1和处理问题2，我们试图找出解决办法，因此在这里张贴一个问题。
我们可能的思考方式之一如下。
我们正在考虑将order、order\u项（以及这样更大的表）分开存储每个用户的基本数据库，而不是将所有内容的当前结构存储在单个数据库中。因此，对于每个用户，order、order\u项将存储在单独的数据库中，其他表则存储在公共数据库中(一个主数据库，x个客户数据库用于这些条目。）因此数据将被隔离。
这个所谓的as-directory结构中的陷阱在存储每个用户的数据库时变得越来越大。
当数据库规模较小时，获取表示这不是一个好选择的引用。[http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html ][在mysql中可以创建的数据库的最大限制？][https://forums.mysql.com/read.php?20，7469274705#味精-74705]
当一个表中有一个较大的数据时，无法清楚地看到该怎么办。
将每个用户的表分开是一个更好的选择，还是其他任何可以满足长期数据增长的选择（上面提到的第1点和第2点）？
1条答案
按热度按时间5w9g7ksd1#
（在mysql中…）a
DATABASE更像是一个逻辑和管理结构，与性能有关。在磁盘上，数据库是一个目录；该数据库中的一个表是该目录中的1-3个文件。当您在一个目录中有成千上万个文件或子目录时，操作系统开始阻塞。但听起来你并没有达到那种程度。
在mysql中，两个表（正在连接的表等）是在同一个数据库（目录）中还是分开的，基本上没有性能差异。
至于“安全”。。。通过为每个用户提供单独的数据库，可以更容易地为不同的用户授予不同的访问权限。仅此一点，就可能是每个用户都有db的原因。
表的大小可能会对性能产生影响，但我们通常谈论的是10亿行或1 TB。即便如此，索引等也可以控制问题。应该查看一个200gb的表，看看您是否有最小大小的数据类型，是否有足够的规范化，但没有过度规范化。适当的索引，特别是复合索引，而不是额外的索引，等等（如果你想继续的话，就开始一个新的问题）
ALTER TABLE影响所讨论的一个表；数据库结构是什么并不重要。顺便说一句，MySQL8.0现在有一些“即时”改变。你的一台服务器是否会过时？那你怎么办？启动另一个服务器，并将一些用户迁移到其中？在这种情况下，每个用户拥有db可能更方便。然后你只需移动一分贝作为一个单位；其他一切都是原封不动的(也就是说，您已经被用户“切分”了。）
用户之间是否有共享的表（除了grant表）？使用db per user，使其成为自己的db。
至于何时升级模式，有很多技术，没有一种是完美的。我会分别看每个案子。添加列的一种技术是构建一个并行表（垂直分区）来容纳新的列。这是零停机，但马虎。下次不能使用此技巧时，可以取消对这些列的分区。
150张table对于一个应用程序来说似乎太多了。
一张表200gb听起来像是你节省了比你需要的更多的东西。想想汇总表。
还是我看错了问题。。。你有
一组150个表，其中包含所有用户？
一个数据库有多组150个表，每个用户一组？
许多数据库，每个用户一个，每个有150个表？