mysql 优化之应用层

一个高性能,高可用的系统，对于数据库的优化是必不可少的。

而对于数据库的优化，也从来不是一个单独的技术点，而是由上至下(从应用层到服务层)的一个系统化工程。

那数据库优化的目的是什？很简单，就是减少应用对数据库的读写压力。如果从这个目的上来讲的话，就能明白，数据库优化绝不仅仅只是对数据库做改变。

在这篇博文里，我会简单谈一下我所理解的mysql优化中的应用层优化。

我这里所指所谈的优化之应用层，的意思和目的是不靠改变mysql数据库的形式，来对数据库进行优化。

人没有牺牲就什么都得不到，为了得到什么东西，就需要付出同等的代价。 ——爱德华

任何正常的优化行为，都是有代价的，在现有的计算机世界里更是如此。

在很久以前，系统资源匮乏，内存和硬盘昂贵，人们做系统为了压榨出最后一点点性能付出了时间的代价，在那个时代，优化是指用时间换取空间。

在今天这个一切上云的时代，内存和硬盘起步都是按 G 按 T 算的了，价格还亲民实惠，我们开始追求高性能高可用的架构，用时间换取空间这种策略不再划算，现在已经是用空间换取时间的年代了。

而应用层对于数据库的优化是性价比最高的方法之一，它利用少量时间，少量的代码，且还不用修改数据库的任何配置与架构，即可达显著的性能提升的效果。

手段1，分散压力。

在计算机中，能够持久化的数据，都是存在硬盘上的，而恰恰硬盘存储是读写速度最慢的(寄存器最快，内存其次)。

我们可以使用内存缓存工具，例如 MemCache ,Redis 等缓存工具，将一些热点查询结果，耗时查询结果等丢到内存中，在下一次查询中，程序先判断内存中是否有这个结果集，有则直接在内存中拿数据，没有则说明数据过期或者为第一次拿数据，从数据库中取出数据后，再将结果放到内存中，方便下次查询使用。

这样，能将大部分读取压力转嫁到内存上，不用再占用过多的数据库连接资源与io读写能力，从这个方面达到了降低数据库的压力，还大幅度提高访问速度。

例1:

某商城首页，经过分析，大部分流量是用户直接输入首页地址来访问的，而首页有太多查询，例如商品栏目及子栏目，各种热推商品。这时我们就可以将这种不经常变动或者很少变动的数据，热点数据，耗时数据，放到内存中，提高访问速度的同时减少数据库读取压力。

手段2，减少查询与延迟查询

这种操作似乎有点耸人听闻，但是现实编码中，是存在的。

我们吃饭，只能一碗一碗的吃，你给我一锅，我是吃不下的。——来自用户

我相信没有人抬杠的吧，电脑屏幕就这么大，你把所有数据丢给他，他是不可能一屏看完的，就上面那个例子而言，商城，一般用户进入首页都不会往下滑，大家可以看看狗东。

狗东就用了一个懒加载，你只有实际有需要，我再去给你查，甚至量级再大些，再去给你查也不会去数据库给你查，而也是从缓存查，当然，这是另一个话题了。

其实这事我们经常做，就是局部加载,Ajax技术。通过这种方法，我们可以从根本上减少不必要的查询。

甚至，我们可以不查询，或在某一段时间内只查询一次。

这种情况，只适用于不敏感的数据，例如某商品共有多少人买过等，用户可能不会太关心这个数字，且用户无法查证。

一般这种数据都是一天查询一次，每天傍晚做定时任务跑一次丢到内存中。做得好的会配合时间加权算法做这类数据，这种就是延迟查询和假查询。

而这类统计，在数据库中是非常耗时的一个操作，通常这类数据，我喜欢称之为，有必要但是不重要的数据。

手段3，减少1+N查询

什么是1+N查询？由一条SQL引发出 N 条 SQL的语句就叫1+N查询。

通常也叫新手1+N查询。这种情况，发生得比较少，但也不是没有。这种情况发生经常是以下场景:

还是以商城为例，要求查出商品价格大于3000元的栏目名称，而商品表内没有栏目名称。部分新手就会通过先查商品表所有大于3000元的商品(分组)，然后根据这些结果，循环再去查栏目表。

重点就在循环查这里了。每循环一次就会多一次查询多一条查询sql(PDO长连接模式下并不会出现多次链接),严重影响效率。

在这种情况下，可以使用 in 查询。

而一般的1+N查询是使用链接查询来优化，视情况而定。

而在 Laravel框架中，又可能会出现另外一种 1+N 查询。

在此框架中有 Eloquent ORM 中有懒加载模式，如果对文档不熟悉的话，很容易就会写出 1+N 的SQL。

原文链接: mysql优化之应用层