MySQL 内存占用总是太高，你需要立即进行这些操作……

生产环境中，MySQL 不经意间吃掉全部的内容，然后开始吃掉 SWAP，性能一降再降，怎么办？

创新互联是专业的陕州网站建设公司，陕州接单;提供成都做网站、成都网站制作,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行陕州网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!

可以从下面三点查看原因：

MySQL 使用内存，有两个途径。

永久占用的内容

比如全局缓冲区（Global Buffer）类别，是在服务器启动期间从操作系统获得的，不会释放到任何一个别的进程。

动态请求的内存

线程缓冲区由MySQL使用，它是在处理新查询时从操作系统请求的内存。在执行查询之后，该内存被释放回操作系统。

这意味着 MySQL 的内存使用，是 全局缓冲区 加上 线程缓冲区 以及 允许的最大连接数 。

对于专用数据库服务器，该值需要保持在服务器内存的90%以下。在共享服务器的情况下，它应该保持在服务器内存的50%以下。

检查一下 MySQL 设置，有助于确定内存使用情况，从而为 MySQL 分配合适的值。

一个近似的公式：

当网站受到攻击时，有可能在短时间内建立异常高的连接数量。MySQL 中的 PROCESSLIST 可用于检测顶级用户并阻止对滥用连接的访问。

找出查询需要很长时间才能执行的语句，因为这些查询需要进一步优化服务器才能更好地执行，可以通过服务器查询日志进行识别。由于查询速度慢，导致磁盘读取较多，导致内存和CPU使用率较高，影响服务器性能。

最后，到了加内存条的时候了。虽然在优化数据库设置之后，服务器会不断地路由到使用交换内存，但也必须增加内存。俗话说：“巧妇难为无米之炊”，就是这个意思。

上面说的这些方向，大家可以在实际操作中验证体会，希望大家在数据库优化的路上，麻溜顺畅，砥砺前行。

MySQL表对象缓存

表对象缓存： 是将某个表对象的字典信息（定义内容）缓存到内存中，用来提高对表的访问效率。某个表被访问过一次后，只要服务器没有关闭且表定义没有被修改的条件下，访问该表，只需要从内存中找到这个已经缓存起来的对象做相应操作即可。

用户访问表时，表对象在缓存时： 通过HASH算法找到TABLE_SHARE，然后每个线程构造各自的实例化TABLE即可。

用户访问表时，当表没有被缓存的情况下： 第一需要打开表，首先需要从系统表中将这个表的所有信息都读入内存中，这些信息包括表名、库名、所有列信息、列的默认值、表的字符集、对应的frm文件路径、所属存储引擎、主键等，将这些信息构造一个TABLE_SHARE结构体，这个结构体是表对象缓存的第一层，所有用户共享访问且为静态不允许修改，它是缓存在table_def_cache（由参数table_definition_cache控制）中的。

而真正与用户打交道的是TABLE_SHARE的衍生品，它对应结构体为TABLE，在被使用前需要将TABLE_SHARE结构体实例化TABLE才能被使用，由每个线程构造各自的实例化TABLE即可。（实例化的TABLE由table_open_cache及table_open_cache_instance控制）

注意1： DDL操作时会将所有instance锁住，而DML操作时instance之间互不干扰。

(DDL statements still require a lock on the entire cache, but such statements are much less frequent than DML statements.)

注意2： 一个线程中如果打开表过多，超过一个instance限制的大小时，是不能跨instance缓存的

(instance大小：table_open_cache / table_open_cache_instances)

表缓存涉及其他参数： 通过下面参数判断table_open_cache参数设置是否合理

table_open_cache_hit：能够从table open cache的free list中找到table则为命中，+1

table_open_cache_misses：与table_open_cache_hit相反，如果找不到则需要重新实例化则+1，通常发生在初始化第一次加载表或超过table_open_cache的设置被淘汰后需要重新实例化。

table_open_cache_overflow：table cache淘汰的数量，每次淘汰+1

opened_tables:已经打开的表数。如果Opened_tables很大，那么table_open_cache的值可能太小了。

open_tables：总的instance (table cache)的总数

MySQL缓存

mysql 开启查询缓存可以有两种方法来开启一种是使用set命令来进行开启，另一种是直接修改my.ini文件来直接设置都是非常的简单的哦。

开启缓存，设置缓存大小，具体实施如下：

windows下是my.ini，linux下是my.cnf;

在配置文件的最后追加上：

需要重启mysql生效；

b) 开启缓存,两种方式：

a)使用mysql命令：

如果报错：

Query cache is disabled; restart the server with query_cache_type=1 to enable it，还是老老实实的该配置文件，然后重启吧，原因如下：

查看是否设置成功

show variables like "%query_cache%" 查看是否设置成功：

当然如果你的数据表有更新怎么办，没关系mysql默认会和这个表有关系的缓存删掉，下次查询的时候会直接读表然后再缓存

下面是一个简单的例子：

以上的相关内容就是对mysql缓存查询和设置的介绍，望你能有所收获。

一般，我们会把 query_cache_type 设置为 ON,默认情况下应该是ON

query_cache_type有3个值 0代表关闭查询缓存OFF，1代表开启ON，2（DEMAND）代表当sql语句中有SQL_CACHE关键词时才缓存，如：

这样 当我们执行 select id,name from tableName; 这样就会用到查询缓存。

①在 query_cache_type 打开的情况下，如果你不想使用缓存，需要指明

select sql_no_cache id,name from tableName;

②当sql中用到mysql函数，也不会缓存

当然也可以禁用查询缓存： mysql set session query_cache_type=off;

上面的显示，表示设置查询缓存是可用的。

表示查询缓存大小，也就是分配内存大小给查询缓存，如果你分配大小为0，

那么 第一步 和 第二步 起不到作用，还是没有任何效果。

上面是 mysql6.0设置默认的，之前的版本好像默认是0的，那么就要自己设置下。

设置

这里是设置1M左右，900多K。

再次查看下:

显示我们设置新的大小，表示设置成功。

例如： 如果查询结果很大， 也缓存？？？？这个明显是不可能的。

MySql 可以设置一个最大的缓存值，当你查询缓存数结果数据超过这个值就不会

进行缓存。缺省为1M，也就是超过了1M查询结果就不会缓存。

这个是默认的数值，如果需要修改，就像设置缓存大小一样设置，使用set

重新指定大小。

好了，通过4个步骤就可以 打开了查询缓存，具体值的大小和查询的方式 这个因不同

的情况来指定了。

mysql查询缓存相关变量

MySQL 提供了一系列的 Global Status 来记录 Query Cache 的当前状态，具体如下：

Qcache_free_blocks：目前还处于空闲状态的 Query Cache 中内存 Block 数目

Qcache_free_memory：目前还处于空闲状态的 Query Cache 内存总量

Qcache_hits：Query Cache 命中次数

Qcache_inserts：向 Query Cache 中插入新的 Query Cache 的次数，也就是没有命中的次数

Qcache_lowmem_prunes：当 Query Cache 内存容量不够，需要从中删除老的 Query Cache 以给新的 Cache 对象使用的次数

Qcache_not_cached：没有被 Cache 的 SQL 数，包括无法被 Cache 的 SQL 以及由于 query_cache_type 设置的不会被 Cache 的 SQL

Qcache_queries_in_cache：目前在 Query Cache 中的 SQL 数量

Qcache_total_blocks：Query Cache 中总的 Block 数量

检查是否从查询缓存中受益的最简单的办法就是检查缓存命中率

当服务器收到SELECT 语句的时候，Qcache_hits 和Com_select 这两个变量会根据查询缓存

的情况进行递增

查询缓存命中率的计算公式是：Qcache_hits/(Qcache_hits + Com_select)。

query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据 查询，就容易造成内存碎片和浪费。

查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%，可以用FLUSH QUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。

查询缓存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小;查询缓存利用率在80%以上而且 Qcache_lowmem_prunes 50的话说明query_cache_size可能有点小，要不就是碎片太多。

查询缓存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%

示例服务器 查询缓存碎片率 = 20.46%，查询缓存利用率 = 62.26%，查询缓存命中率 = 1.94%，命中率很差，可能写操作比较频繁吧，而且可能有些碎片。

查询缓存可以看做是SQL文本和查询结果的映射。如果第二次查询的SQL和第一次查询的SQL完全相同（注意必须是完全相同，即使多一个空格或者大小写不同都认为不同）且开启了查询缓存，那么第二次查询就直接从查询缓存中取结果，可以通过下面的SQL来查看缓存命中次数（是个累加值）：

另外即使完全相同的SQL，如果使用不同的字符集、不同的协议等也会被认为是不同的查询而分别进行缓存。

在表的结构或数据发生改变时，查询缓存中的数据不再有效。有这些INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE会导致缓存数据失效。所以查询缓存适合有大量相同查询的应用，不适合有大量数据更新的应用。

可以使用下面三个SQL来清理查询缓存：

1、FLUSH QUERY CACHE; // 清理查询缓存内存碎片。

2、RESET QUERY CACHE; // 从查询缓存中移出所有查询。

3、FLUSH TABLES; //关闭所有打开的表，同时该操作将会清空查询缓存中的内容。

Query Cache是MySQL Server层的一个非常好的特性，对于小数据集或访问量非常集中的应用场景，有非常好的性能提升，但是Query Cache引入了一些新的问题，而且大部分场景下比较鸡肋，官方打算弃用了

参考：

文章题目：mysql缓冲怎么清 mysql缓存清理
路径分享：http://azwzsj.com/article/ddoshoi.html