托管：为什么 MySQL 数据库的数量很重要？
好吧，也许我在这里遗漏了一些东西，但我正在查看各种 PHP 托管选项 和我看到诸如“10 个 MySQL 数据库”、25 个甚至无限个之类的东西。
现在，我在一个具有 Oracle 后端的网站上工作，该网站拥有 10,000 多个并发用户，并且我们拥有……一个数据库。
当然，数据库的理念是您可以在其中存储任何您想要的内容。 那么为什么这个数字对于 MySQL 来说很重要呢？ 是否有一些我不知道的表、行或整体数据库限制（完全有可能）？ 或者是并发连接的问题？ 或者其他一些性能问题（例如分片）？ 分片方面似乎不太可能，因为即使是基本的托管选项（即每月 5 美元以下）我也看到有 10 个数据库。
如果有人能告诉我这件事，那就太好了。
Ok, maybe I'm missing something here but I'm looking at various PHP hosting options and I see things like "10 MySQL databases", or 25 or even unlimited.
Now I've worked on sites with an Oracle backend that have 10,000+ concurrent users and we've had... one database.
The idea of a database is, of course, that you can store whatever you want in it. So why is it for MySQL that the number matters? Is there some table, row or overall database limit I'm not aware of (entirely possible)? Or is it a question or concurrent connections? Or some other performance issue (eg sharding)? The sharding aspect seems unlikely because even basic hosting options (ie under $5/month) I see with 10 databases.
If someone could clue me in on this one, it'd be great.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
尽管有一些技术和历史方面的考虑，但这主要是一种营销策略。
首先，如果这是显而易见的，我们深表歉意，但是 SCHEMA 之于 Oracle 就像数据库之于 MySQL（用过于简单的术语来说，就是表的逻辑集合）。
主机说您可以在服务器上配置 XX 个逻辑数据库。 许多 Web 应用程序需要数据库才能运行。 现代 Web 应用程序（例如 Wordpress、Movable Type、Joomla 等）将允许您使用自定义前缀来命名表格。 但是，如果应用程序没有此配置功能，则意味着每次安装都需要一个数据库。 此外，类似地，如果两个应用程序具有相同的表名，它们就不能共存于单个数据库中。 许多早期的 Web 应用程序都是这样开始的，因此早期数据库的数量是一个需要考虑的重要功能。
还有访问权限和安全性。 虽然 MySQL（和其他数据库）可以配置为向用户提供细粒度的访问控制，直至表和列级别，但创建一个对逻辑数据库拥有完全权限的用户通常更容易。 这对于销售服务但将已完成的网站/应用程序的实际托管传递给共享网络主机的人来说非常重要。
It's mostly a marketing tactic, although there are some technical and historical considerations.
First, apologies if this is obvious, but SCHEMAs are to Oracle as DATABASES are to MySQL (in over simplified terms, a logical collections of tables).
The host is saying you can have XX number of configured logical databases on a server. Lots of web applications need a database to run. Modern web applications like Wordpress, Movable Type, Joomla, etc., will let you name your tables with a custom prefix. However, if an application doesn't have this configuration feature that means you need one database per install. Also, in a similar vein, if two applications have the same table name, they can't coexist in a single database. Lots of early web applications started out like this, so early on number of databases was an important feature to consider.
There's also access and security. While MySQL (and other databases) can be configured to give users fine grained access-control down to the table and column level, it's often easier to create one user who has full permission on a logical Database. This is important to people who sell services but pass off the actual hosting of completed sites/applications to the shared web-host.
有些人喜欢每个应用程序一个数据库
Some people like one database per app
这是营销，不是技术。 他们想要做广告。 “10”听起来是一个不错的数字。
It's marketing, not technical. They want something to advertise. "10" sounds like a good number.
出于开发目的，有时最好复制整个数据库来测试新软件。 击败重命名代码中的所有表（尽管Wordpress等应用程序允许您为所有表名指定前缀，以防您没有多个数据库的奢侈）。
For development purposes, sometimes it's good to make a copy of your entire database to test new software against. Beats renaming all the tables in your code (although apps like Wordpress let you specify a prefix for all your table names in case you don't have the luxury of multiple DBs).
当我使用共享托管时，我为每个站点/客户端的自定义应用程序设置了一个单独的数据库，如果您使用 Fantastico 安装应用程序，它将默认为每个站点/客户端使用一个数据库。
我相信，当您的服务水平超出当前水平时，这些限制会促使您升级到下一个服务水平。
When I used shared hosting, I set up a separate database for each site/client for custom apps, and if you use Fantastico to install applications it will use a database for each one by default.
I believe the limits are there to prompt you to upgrade to the next tier of service when you outgrow the current level.
尼克是部分正确的，但它也与那些尝试在一个共享帐户上托管多个站点并为每个站点使用不同的数据库和一个脚本来通过一点 dns 伪装来提供正确内容的人有关。
Nick is partially correct, but it also has to do with people who will try to host multiple sites on one shared account and will use a different database for each and a script to serve the correct content with a little dns masquerading.
此外，这可能是一种营销视角。
如果您只是为自己设置数据库，那么低计数就可以了。 但对于商业用户来说，他们可能希望在一项服务上为多个客户拥有多个站点，并试图走捷径，每个客户/项目可能需要 1 个数据库（或更多）。
因此，对数据库数量进行限制会在一定程度上控制您提供的各种服务，并可能限制您的“转售”价值的潜力，即：阻止您购买 1 个计划，然后将其出售给其他人，例如“转租”。
Additionally its possibly a marketing perspective.
If you're only setting up databases for yourself, the low count is fine. but for commerical users, whom may want to have multiple sites for multiple clients on the one service, trying to cut corners, you're likely to need 1 Database ( or more ) per client/project.
So putting a limit on number of databases controls somewhat the variety services you offer, and potentially limits potential for your "resale" value, ie: to stop you buying 1 plan and then selling it on to somebody else, like "subleasing".
这主要适用于当您在同一个机器上托管多个站点时。 对我来说，我购买/出售很多网站，因此我需要能够使每个网站尽可能与其他网站分离。
This is mainly for when you are hosting multiple sites on the same box. For me, I buy/sell a lot websites so I need to be able to keep each website as detached from the others as possible.