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

当然pdo很好，但是它与mysql和mysqli相比的性能一直存在一些争议，尽管现在看起来已经固定了。

如果您考虑可移植性，您应该使用pdo，如果不考虑可移植性，则应该使用mysqli。它有一个面向对象接口、准备好的语句和pdo提供的大部分功能(除了可移植性)。

另外，如果真的需要性能，可以准备PHP 5.3中的MysqLnd驱动程序，它将与PHP更加紧密地集成，具有更好的性能和改进的内存使用(以及用于性能调优的统计数据)。

如果你有集群服务器(和youtube一样的负载)，Memcache是很好的，但我也会先尝试APC。

无论如何，在PHP中缓存是非常简单的，即使没有像memcached这样的扩展/帮助包。

你所需要做的就是使用ob_start()创建一个输出缓冲区。

创建全局缓存函数。调用ob_start，将函数作为回调函数传递。在函数中，查找页面的缓存版本。如果存在，就把它送上，然后结束。

如果不存在，脚本将继续处理。当它到达匹配的ob_end()时，它将调用您指定的函数。这时，您只需要获取输出缓冲区的内容，将它们放到一个文件中，保存文件，然后结束。

添加一些过期/垃圾收集。

许多人没有意识到可以嵌套ob_start()/ob_end()调用。如果你已经在使用输出缓冲区来解析广告或者做语法高亮等等，你可以嵌套另一个ob_start/ob_end调用。

我在一些网站上工作过，这些网站都是由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/

一般

在开始看到真实世界的负载之前，不要尝试优化。你可能猜对了，但如果你猜错了，那你就是在浪费时间。 使用jmeter、xdebug或其他工具对站点进行基准测试。 如果加载开始成为一个问题，对象或数据缓存都可能涉及到，所以通常阅读缓存选项(memcached, MySQL缓存选项)

Code

对代码进行分析，以便了解瓶颈在哪里，以及它是在代码中还是在数据库中

数据库

Use MYSQLi if portability to other databases is not vital, PDO otherwise If benchmarks reveal the database is the issue, check the queries before you start caching. Use EXPLAIN to see where your queries are slowing down. After the queries are optimized and the database is cached in some way, you may want to use multiple databases. Either replicating to multiple servers or sharding (splitting the data over multiple databases/servers) may be appropriate, depending on the data, the queries, and the kind of read/write behavior.

缓存

Plenty of writing has been done on caching code, objects, and data. Look up articles on APC, Zend Optimizer, memcached, QuickCache, JPCache. Do some of this before you really need to, and you'll be less concerned about starting off unoptimized. APC and Zend Optimizer are opcode caches, they speed up PHP code by avoiding reparsing and recompilation of code. Generally simple to install, worth doing early. Memcached is a generic cache, that you can use to cache queries, PHP functions or objects, or entire pages. Code must be specifically written to use it, which can be an involved process if there are no central points to handle creation, update and deletion of cached objects. QuickCache and JPCache are file caches, otherwise similar to Memcached. The basic concept is simple, but also requires code and is easier with central points of creation, update and deletion.

杂项

考虑高负载的替代web服务器。像lighthttp和nginx这样的服务器可以用比Apache少得多的内存处理大量流量，如果你可以牺牲Apache的强大功能和灵活性(或者如果你不需要这些东西，通常情况下，你不需要)。 请记住，现在的硬件非常便宜，所以一定要花费精力来优化一大块代码，而不是“让我们购买一个巨型服务器”。 考虑将“MySQL”和“scaling”标签添加到这个问题中

没有两个站点是相同的。您确实需要使用像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.