我有一个主要的MySQL数据库设置，以及一个处理查询的类。它真的很棒。我正在我的网站上构建一个自定义广告系统，我想知道创建一个单独的数据库以便处理该系统是否有任何好处？
这样做是否有任何陷阱？
选项＃1 - 一个用于主要网站功能的数据库，一个用于广告系统的数据库
选项＃2 - 主网站功能和广告系统的一个数据库
答案 0 :(得分：5)
嗯，您需要为您使用的每个数据库建立一个新连接，您还需要一个新的DB-Class实例 - 这两个实例都需要花费一些（最小的）内存。我个人认为没有理由要你/想要这样做。如果你只是想分开这两件事，也许你可以为广告表使用像“adv_”这样的前缀。
编辑：如果您想要组合（例如，加入）两个数据库的数据，可能会出现另一个问题 - 如果您不使用多个数据库，则会更容易。
答案 1 :(得分：1)
Johnnietheblack，这里没有简单的答案，甚至没有一个正确的答案：不同的表需要不同的方法，有时你必须抛弃一个学术/更“安全”的数据库模型来提高性能和可扩展性。
这总是需要权衡利弊。根据我的个人经验，我有一些想法与你分享：
当您在不同数据库中分隔表时，您需要在数据抽象层中做更多工作来保持参照完整性（您必须执行数据库杂务......）并链接信息。另一方面，管理数据库（索引，数据文件，查询调整等）更容易。
具有高插入率和低维护（更新/删除）的表以及参照完整性 重要的表 - 如日志表 - 是放在单独数据库中的理想选择：虽然插入的I / O很重，但记录不会随时间变化，很少检索它们，并且它们的索引往往非常简单（日期/时间和其他一些属性）。我有一个案例，其中日志文件是如此之大（数百万条记录），在一个点插入一个点几乎1秒。因为它每天有50万条新记录，所以它是一个雪球：我们无法阻止系统调整该死的东西，因为它需要太长时间，系统正在关闭，因为这个日志表随处可见并影响了业务（ 75％的程序使用此表）。
数据库可以在早餐时吃掉成千上万的记录，所以对于小桌子（少于1000条记录），你通常不需要担心，只有大的（超过5000）。我有一个朋友DBA在大多数表中都没有为性能创建索引：他做了一些测试并发现他们的SQL Server正在将查询计划更改为大多数表的TABLE SCANS。但请注意：强效药物！
在定义是否应将新表集放在一个数据库中时，尝试考虑SaaS：您的广告系统需要与您的网站紧密集成，或者它可以是一个单独的组件，可以重复使用其他组件？如果是后者，则应考虑使用单独的数据库，以便在更新架构时将影响降至最低，在新表中进行维护等。
还有很多其他案例，但是唉，我们的时间很少......重要的是要保持开放的心态，并试着忘记一点学术上完美的数据库模型。希望它有所帮助！