服务器应用层,韩国服务器应用层

如果在提高MySQL的性能上花费太多时间，容易使视野局限于MySQL本身，而忽略了用户体验。回过头来看，也许可以意识到，或许MySQL已经足够优化，对于用户看到的响应时间而言，其所占的比重已经非常之小，此时应该关注下其他部分了。这是个很不错的观点，尤其是对DBA而言，这是很值得去做的正确的事。但如果不是MySQL,那又是什么导致了问题呢?使用第3章提到的技术，通过测量可以快速而准确地给出答案。如果能顺着应用的逻辑过程从头到尾来剖析，那么找到问题的源头一-般来说并不困难。有时，尽管问题在MySQL上，也很容易在系统的另一部分得到解决。

无论问题出在哪里，都至少可以找到一个靠谱的工具来帮助进行分析，而且通常是免费的。例如，如果有JavaScript或者页面渲染的问题，可以使用包括Firefox浏览器的Firebug插件在内的调优工具，或者使用Yahoo!的YSlow工具。我们在前面提到了几个应用层工具。一些工具甚至可以剖析整个堆栈: New Relic 是一个很好的例子，它可以剖析Web应用的前端、应用以及后端。

常见问题

我们在应用中反复看到一此相同的问题，经常是因为人们使用了缺乏设计的现成系统或者简单开发的流行框架。虽然有时候可以通过这些框架更快更简单地构建系统，但是如果不清楚这些框架背后做了什么操作，反而会增加系统的风险。

下面是我们经常会碰到的问题清单，通过这些过程可以激发你的思维。

●      什么东西在消耗系统中每台主机的CPU、磁盘、网络，以及内存资源?这些值是否合理?如果不合理，对应用程序做基本的检查，看什么占用了资源。配置文件通常是解决问题最简单的方式。例如，如果Apache因为创建1000个需要50MB内存的工作进程而导致内存提出，就可以配置应用程序少使用些Apache工作进程。也可以配置每个进程少使用一些内存。

●     应用真的需要所 有获取到的数据吗? 获取1000行数据但只显示10行，而丢弃剩下的990行，这是常见的错误，(如果应用程序缓存r另外的900行备用，这也许是有意的优化。)

●应用在处理本应由数据库处理的事情吗，成者反过来?这里有两个例子，从表中获取所有的行在应用中进行统计计数，或者在数据库中执行复杂的字符串操作。数据库擅长统计计数，而应用擅长正则表达式。要善F使用正确的工具来完成任务。

●     应用执行了太多的查询? ORM宜称的把程序员从写SQL中解放出来的语句接口通常是罪魁祸首。

●     应用执行的查询太少了?好吧，上面只说了执行太多sQL可能成为问题。但是，有时候让应用来做“手工关联”以及类似的操作也可能是个好主意。因为它们允许更细的粒度控制和更有效的使用缓存，以及更少的锁争用，甚至有时应用代码里模拟的哈希关联会更快(MySQL 的嵌套循环的关联方法并不总是高效的)。

●     应用创建了没必要的MySQL连接吗?如果可以从缓存中获得数据，就不要再连接数据库。

●     应用对一个MySQL实例创建连接的次数太多了吗(也许因为应用的不同部分打开了它们自己的连接) ?通常来说更好的办法是重用相同的连接。

●     应用做了太多的“垃圾”查询?一个常见的例子是发送查询前先发送一个ping命令看数据库是否存活，或者每次执行SQL前选择需要的数据库。总是连接到一个特定的数据库并使用完整的表名也许是更好的方法。(这也使得从日志或者通过SHowPROCESSLIST看SQL更容易了，因为执行日志中的SQL语句的时候不用再切换到特定的数据库，数据库名已经包含在SQL语句中了。)“预备(Preparing)” 连接是另一个常见问题。Java驱动在预备期间会做大量的操作，其中大部分可以禁用。另一个常见的垃圾查询是SET NAMES UTF8, 这是一个错误的方法 (它不会改变客户端库的字符集，只会影响韩国服务器的设置)。如果应用在大部分情况使用特定的字符集工作，可以修改配置文件把特定字符集设为默认值，而不需要在每次执行时去做修改。

●应用使用了连接池吗?这既可能是好事，也可能是坏事。连接池可以帮助限制总的连接数，有大量SQL执行的时候效果不错(Ajax 应用是一个典型的例子)。然而，连接池也可能有些副作用，比如说 应用的事务、临时表、连接相关的配置项， 以及用户自定义变量之间相互干扰等。

●      应用是否使用长连接?这可能导致太多连接。通常来说长连接不是个好主意，除非网络环境很慢导致创建连接的开销很大，或者连接只被一或两 个很快的SQL使用，或者连接频率很高导致客户端本地端口不够用。如果MySQL的配置正确，也许就不需要长连接了，比如使用skip name_resolve来避免DNS反向查询，确保thread_cache足够大，并且增加back_log。

●      应用是否A不使用的时候还保持连接打开？如果是这样，尤其是连接到很多

长连接和连接池的区别可能使人困感。长连接可能跟连接池有同样的副作用，因为重用的连接在这两种情况下都是有状态的。

然而，连接池通常不会导致服务器连接过多，因为它们会在进程间排队和共享连接。另一方面，长连接是在每个进程基础上创建，不会在进程间共享。

连接池也比共享连接的方式对连接策略有更强的控制力。连接池可以配置为自动扩展.但是通常的实践经验是，当遇到连接池完全占满时，应该将连接请求进行排队而不是扩展连接池。这样做可以在应用韩国服务器上进行排队等待，而不是将压力传递到MySQL数据库服务器上导致连接数太多而过载。

有很多方法可以使得查询和连接更快，但是一般的规则是， 如果能够直接避免进行查询和连接，肯定比努力提升查询和连接的性能能获得更好的优化结果。