高性能Web应用有20个“绊脚石”

6.  单一的数据库副本

你必须使用一个以上的读副本或者MySQL从节点，这允许在主节点出问题时的快速故障转移。

拥有数据库的多个副本意味着横向扩展。如果你有两个，你就会看到3-4个会对你基础设施的提升。

7． 使用数据库进行排队

MySQL数据库非常适合储存表格、数据以及他们之间的关系，不幸的是，它并不适合处理应用程序的队列。尽管如此，许多开发者都习惯使用一个表格来 达到这个目的。比如，让你的应用程序包含一些作业表格，或者一个状态列，拥有一些类似“in-process”、“in-queue” 及“finished”的值。

因为锁竞争、scan及 poll进程将造成更多的工作，这些解决方案会带来一些扩展性问题，它们将会显著的降低数据库速度。幸运的是这里存在很多有效的开源解决方案，比如RabbitMQ及Amazon的SQS。

8.  使用一个做全文查询的数据库

页面搜索是掣肘应用程序的另一个方面，尽管MySQL一段时间也支撑了full-text索引。但是它们只对MyISAM表格有效，其它类型表格都不买账，一直困扰着开发者。

一个解决方案是使用类似Solr的专业搜索引擎，这些技术拥有许多很好的库去支撑你的编程语言，同时会提供一个更快的搜索速度。这些方案同样易于扩展，并且不会让你的数据库成为累赘。

替代方案是Sphinx SE，一个MySQL存储引擎，将Sphinx服务器整合进数据库。此外，MySQL 5.6版本中还使用了InnoDB做全文搜索的默认搜索引擎。

9.  对象关系模型

ORM，就像毒药一样，一旦进行使用，就很难摆脱。有利的一面是ORM有益于快速原型，并且允许非专家级MySQL开发者使用对象或者内存模式进行读写访问。如果你不进行扩展，那么他们的速度将非常快，并让功能的快速交付得到保障。

然后DBA（数据库管理员）会因为缓慢且丑陋的查询来到开发团队并且说：“这个查询在应用程序什么地方，我们需要进行修复，它需要被重写。”开发团队则会说：“我们也不知道！”从而会收到来自运营组一些质疑的眼神。

有能力对bad sql进行跟踪并将其指出是非常重要的。DBA团队需要一定的指引找到bad sql的源头。如果查询是来自ORM，他们并不具备这些指引。这样你的团队将面对一个巨大的技术负债，同样也是个非常难以解决的挑战。

10.  缺少Instrumentation

Instrumentation（仪表盘）为应用程序提供了码表和油表，这是汽车不可缺少的两个部分。他们提供了应用程序的内部工作信息：他们记录了时间信息，并且提供了应用程序耗时最多的环节。

一个非常人气的网络解决方案就是New Relic，它提供了一个非常全面的可视化界面，针对各个领域工作者——项目经理、开发者、运营团队，甚至是业务部门都可以从图中发现问题所在。当然，现在已经有很多的开源Instrumentation。