在我正在编写的应用程序中，出于“安全原因”，我很久以前就将用户和主数据库分开了。然而，越来越难证明管理这种设置的开销和难度是合理的。
对于一些快速的细节，这是一个 PHP Web 应用程序。有 2 个单独的 mysqli 连接，每个数据库一个。每个数据库都有自己的用户和自己的凭据。这意味着您无法使用用户数据库凭据访问主数据库
从理论上讲，这可以防止 SQL 注入损坏、关注点分离、通过模糊性实现的安全性等。但是，在成本与回报之间，我失去了与用户表和数据库其余部分（例如连接）的轻松互操作性。
是否有更具体的原因表明这样的数据库设置有意义？这甚至很常见吗？
您可以使用可以访问特定列的单独用户帐户，而不是两个单独的连接一起工作。您的大多数语句可以使用只能访问用户表的用户名（而非密码）列的用户帐户，以及主数据库中不太重要的数据。
在 MySQL 中，您可以使用很好的粒度来执行此操作。这将允许您显示每个人的用户名，仅在登录页面中访问密码，在会话管理中仅访问会话，仅在通知程序中访问电子邮件地址等。
使用此模型，SQL 注入通常会限制在公共信息或它们到达的单个部分。
当然，什么是公开的，你的用户是如何设置的，有多少，他们得到什么都是特定于你的用例的。
检查您的 MySQL 版本的GRANT文档。
免责声明：这不是对 SQL 注入的修复，只是为了帮助最小化影响。
如果访问两个不同数据库的应用程序是相同的，那么数据库的分离就没有那么有用了。它使每个编程阶段和与数据相关的问题变得复杂。我更喜欢逻辑分离而不是数据的物理分离。
两个保险柜也一样：如果你有两个钥匙在同一个地方，那么两个保险柜的安全性是多少？
这里的“可用性与安全性”平衡失去了对安全性的更多可用性。
依靠.....
例如，银行将 PIN 存储在他们自己的数据库中，在他们自己的服务器上。如果有人试图从机架中删除数据，服务器也会自动删除数据。
单独数据库的一个很好的理由是，如果您希望能够让您的客户在遇到错误时将数据库发送给您。如果数据库不包含任何密码，则问题可能会更少。
我认为一个单独的数据库只有在它允许您以不同的方式管理两个数据库时才有意义。