我不认为自己会很快从MySQL转换过来——所以我想我不需要PDO的抽象功能。DavidM，谢谢你的文章，它们帮了我很多。

我在一些网站上工作过，这些网站都是由PHP和MySQL支持的，每个月都有数百万的点击率。以下是一些基本知识:

Cache, cache, cache. Caching is one of the simplest and most effective ways to reduce load on your webserver and database. Cache page content, queries, expensive computation, anything that is I/O bound. Memcache is dead simple and effective. Use multiple servers once you are maxed out. You can have multiple web servers and multiple database servers (with replication). Reduce overall # of request to your webservers. This entails caching JS, CSS and images using expires headers. You can also move your static content to a CDN, which will speed up your user's experience. Measure & benchmark. Run Nagios on your production machines and load test on your dev/qa server. You need to know when your server will catch on fire so you can prevent it.

我推荐阅读《构建可扩展的网站》，它是由Flickr的一位工程师写的，是一个很好的参考。

看看我关于可伸缩性的博客文章，它有很多关于多种语言和平台可伸缩性的演示文稿的链接: http://www.ryandoherty.net/2008/07/13/unicorns-and-scalability/

我运营的网站每月有700万到800万的访问量。不是特别多，但足以让我们的服务器感受到负载。我们选择的解决方案很简单:数据库级的Memcache。如果数据库负载是您的主要问题，则此解决方案效果很好。

我们开始使用Memcache缓存最常用的整个对象和数据库结果。它确实起作用了，但它也引入了bug(如果我们更加小心的话，我们可能会避免其中一些bug)。

所以我们改变了我们的方法。我们构建了一个数据库包装器(使用与旧数据库完全相同的方法，因此很容易切换)，然后我们将其子类化以提供memcached数据库访问方法。

现在，您所要做的就是决定查询是否可以使用缓存(可能已经过期)的结果。用户运行的大多数查询现在都直接从Memcache中获取。例外情况是更新和插入，这对于主网站来说只发生在日志记录中。这个相当简单的措施减少了大约80%的服务器负载。

没有两个站点是相同的。您确实需要使用像jmeter和benchmark这样的工具来查看问题点在哪里。您可以花费大量的时间来猜测和改进，但是在您度量和比较您的更改之前，您不会看到真正的结果。

例如，多年来，MySQL查询缓存是我们所有性能问题的解决方案。如果你的站点很慢，MySQL专家建议打开查询缓存。事实证明，如果你有一个高的写负载，缓存实际上是瘫痪的。如果你不经过测试就打开它，你永远不会知道。

别忘了，缩放永远不会结束。处理10req/s的站点将需要更改以支持1000req/s。如果您足够幸运，需要支持10,000req/s，那么您的体系结构可能也会完全不同。

数据库

Don't use MySQLi -- PDO is the 'modern' OO database access layer. The most important feature to use is placeholders in your queries. It's smart enough to use server side prepares and other optimizations for you as well. You probably don't want to break your database up at this point. If you do find that one database isn't cutting, there are several techniques to scale up, depending on your app. Replicating to additional servers typically works well if you have more reads than writes. Sharding is a technique to split your data over many machines.

缓存

You probably don't want to cache in your database. The database is typically your bottleneck, so adding more IO's to it is typically a bad thing. There are several PHP caches out there that accomplish similar things like APC and Zend. Measure your system with caching on and off. I bet your cache is heavier than serving the pages straight. If it takes a long time to build your comments and article data from the db, integrate memcache into your system. You can cache the query results and store them in a memcached instance. It's important to remember that retrieving the data from memcache must be faster than assembling it from the database to see any benefit. If your articles aren't dynamic, or you have simple dynamic changes after it's generated, consider writing out html or php to the disk. You could have an index.php page that looks on disk for the article, if it's there, it streams it to the client. If it isn't, it generates the article, writes it to the disk and sends it to the client. Deleting files from the disk would cause pages to be re-written. If a comment is added to an article, delete the cached copy -- it would be regenerated.

我不敢相信居然没有人提到这个:模块化和抽象。如果您认为您的站点将不得不扩展到许多机器，那么您必须这样设计它!这意味着一些愚蠢的事情，比如不要假设数据库在本地主机上。它还意味着一些一开始会很麻烦的事情，比如编写数据库抽象层(像PDO，但要轻得多，因为它只做您需要它做的事情)。

这意味着在一个框架下工作。您将需要对代码进行分层，以便稍后通过重构数据抽象层(例如，通过告诉它某些对象位于不同的数据库中)来获得性能，并且代码不必知道或关心。

最后，要注意内存密集型操作，例如不必要的字符串复制。如果你能保持PHP的内存使用较低，那么你的web服务器就会得到更好的性能，当你采用负载平衡的解决方案时，这是可以扩展的。

PDO也非常慢，而且它的API相当复杂。如果不考虑可移植性，任何头脑正常的人都不应该使用它。让我们面对现实吧，99%的网络应用都不是这样的。你只需坚持使用MySQL或PostrgreSQL，或任何你正在使用的。

至于PHP的问题和要考虑什么。我认为过早的优化是万恶之源。,)首先完成你的应用程序，在编程时尽量保持干净，做一点文档并编写单元测试。有了以上所有的方法，在必要的时候重构代码就没有问题了。但首先你想把它做完，然后把它推出去，看看人们对它有什么反应。