我正在构建一个网络应用程序。这个应用程序将使用 MySQL 来存储与每个用户相关的所有信息。然而，它也将使用 MySQL 来存储系统管理员类型的东西，如错误日志、事件日志、各种临时令牌等。第二组信息可能会比第一组大，而且它不那么重要。如果我丢失了所有错误日志，该站点将继续运行而不会出现问题。
我很纠结是否要为这些不同类型的信息建立多个数据库，或者将它们全部塞入一个数据库中的多个表中。
将所有内容合二为一的原因是我只需要打开一个连接。我注意到打开连接会造成可衡量的时间损失，尤其是使用远程 mysql 服务器。
你们是做什么的？
首先，我必须说，我认为将所有事件日志、错误日志存储在 db 中是一个非常糟糕的主意，相反，您可能希望将它们存储在文件系统中。
如果您的 Web 应用程序出现意外情况，您将只需要错误日志或事件日志。然后你下载文件并检查它，仅此而已。无需将其存储在数据库中。它会减慢你的数据库和你的网络应用程序。
作为对您问题的回答，如果您真的想这样做，您应该将它们分开，并且您应该找到一种方法来保持页面运行，即使您的事件 og 和错误日志数据库已加载并且响应缓慢。
使用两个不同的数据库（一个用于您的应用程序的“核心”数据，另一个用于“技术”数据）可能不是一个坏主意，至少如果您希望您的应用程序有很多用户：
也许打开两个连接意味着更多的时间——但这种差异可能可以忽略不计，不是吗？
我已经在使用两个数据库的应用程序上工作过几次：
这样，是的，我们有时会打开两个连接 - 单独一台服务器无法处理负载......
无论如何都要使用连接池。因此，获得连接的时间不是问题。但是如果你有 2 个连接，事务处理就会变得更加复杂。另一方面，有时拥有 2 个连接很方便：如果业务事务出现问题，您可以回滚事务并仍然在管理事务上记录失败。但我仍然会坚持一个数据库。
我只会使用一个数据库 - 主要是因为您提供的原因：您只需要一个连接即可访问日志记录和用户存储的数据。
根据您的编程语言，一些框架（例如 J2EE）提供连接池。使用两个数据库，您将需要两个池。另一方面，在 PHP 中，建立一个（或两个）连接时会考虑性能。
无论您是否使用单独的“数据库”，对 mysql 都没有任何影响，它们只是目录。
它可能使设置权限更容易，这是这样做的正当理由。除此之外，它与将表保存在同一个数据库中完全相同（除了您可以拥有多个同名的表......但请不要）
但是，将它们放在单独的服务器上可能是个好主意，因为您可能不希望核心关键数据（例如用户信息）与大量不重要的数据混合在一起。对于旧的审计数据、调试日志等尤其如此。
此外，短期数据，例如搜索结果、会话等，可以放置在不同的服务器上——它可能没有高可用性[1] 要求。
话虽如此，如果您不需要这样做，请将其全部转储到一台更易于管理的服务器上（备份、提供高可用性、管理安全性等）。
通常不可能在 >1 台服务器上获取一致的数据快照。这是只拥有一个（或您关心的用于备份目的的一个）的一个很好的理由
[1] 数据，而不是数据库。
在 MySQL 中，InnoDB 可以选择将某个数据库的所有表存储在一个文件中，或者每个表有一个文件。
无论如何，建议每个表有一个文件，如果这样做，如果您有一个或多个数据库，它会在数据库存储级别上有所不同。
使用连接池，一个或多个数据库也可能无关紧要。
因此，在我看来，问题是您是否考虑过将数据库的“另一半”分离到单独的服务器上——单独的服务器可能具有非常不同的硬件配置，例如没有 RAID。如果是这样，请考虑使用单独的数据库。如果没有，请使用单个数据库。
我看不出有两个数据库的理由。拥有专门用于“技术”和“业务”数据的表格是完全可以接受的，但逻辑分离应该就足够了。
对我来说，物理分离似乎没有必要，除非您指的是应用程序和数据仓库星型模式。在这种情况下，它要么是实时更新，要么是更典型的夜间批处理 ETL。