MySQL 5.6 整理表的碎片

https://blog.51cto.com/dadaman/1957229

可以看到，当前表的碎片率超高了，50.6%。

有三种办法整理碎片

这三种 *** 作都是先创建一个临时表复制完成后再删除旧表，所以在执行 *** 作的过程中磁盘会先增大。

会锁表

https://dev.mysql.com/doc/refman/5.6/en/

https://dev.mysql.com/doc/refman/5.6/en/optimize-table.html

会锁表

pt-online-schema-change - ALTER tables 无需锁表。

整理结果很明显，整理后碎片率0.3%。

这里有几个参数需要介绍一下：

--dry-run

这个参数不建立触发器，不拷贝数据，也不会替换原表。只是创建和更改新表。

--execute

表明你已经阅读了文档，并且确认要 alter the table。你必须配置这个参数来 alter the table。如果你不配置，那么工具将只进行一些安全检查然后就退出了。这帮助确保你已经阅读了文档，并且了解如何使用该工具。如果你没有阅读这些文档，那么不会设置该参数。

--critical-load

每次chunk *** 作前后，会根据show global status统计指定的状态量的变化，默认是统计Thread_running。目的是为了安全，防止原始表上的触发器引起负载过高。这也是为了防止在线DDL对线上的影响。超过设置的阀值，就会终止 *** 作，在线DDL就会中断。提示的异常如上报错信息。

--max-lag

type: timedefault: 1s

lag 滞后偏移

暂停数据拷贝，直到所有replicas的lag值低于该值。在每个 data-copy query (each chunk)后，工具会通过Seconds_Behind_Master查询所有replica的 replication lag 。如果任何replica lag大于该值，那么工具会sleep --check-interval 秒，然后再次检查所有replica。如果你指定 --check-slave-lag ，那么工具会检查那台server，而不是所有server。如果你想控制哪个提供工具的监控，配置DSN值 --recursion-method 。

工具会等待直到replicas停止lagging。如果任一replica停止，工具会一直处于等待状态直到该replica启动。 在所有replicas运行并且lagging不大的情况下，数据拷贝继续。

工具在等待的时候，会打印进程报告。如果replica停止了，会立即打印进程报告，然后在每个进程报告期间重复。

--check-interval

type: timedefault: 1

Sleep time between checks for --max-lag .

--max-load

选项定义一个阀值，在每次chunk *** 作后，查看show global status状态值是否高于指定的阀值。该参数接受一个mysql status状态变量以及一个阀值，如果没有给定阀值，则定义一个阀值为为高于当前值的20%。注意这个参数不会像--critical-load终止 *** 作，而只是暂停 *** 作。当status值低于阀值时，则继续往下 *** 作。是暂停还是终止 *** 作这是--max-load和--critical-load的差别。

--charset

简写: -Atype: string

设置默认字符集。如果值为 utf8，设置 Perl’s binmode on STDOUT to utf8，传送 mysql_enable_utf8 参数到 DBD::mysql，然后在连接到MySQL后运行 SET NAMES UTF8 。其他的值也是在STDOUT设置 binmode，然后在连到MySQL后运行 SET NAMES 。

--check-replication-filters

检查复制中是否设置了过滤条件，如果设置了，程序将退出

--nocheck-replication-filters

不检查复制中是否设置了过滤条件

--set-vars

设置mysql的变量值

--check-slave-lag

检查主从延迟

--no-version-check

不检查版本，在阿里云服务器中一般加入此参数，否则会报错

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

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

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

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

需要重启mysql生效；

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

a)使用mysql命令：

如果报错：

Query cache is disabledrestart 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引入了一些新的问题，而且大部分场景下比较鸡肋，官方打算弃用了

参考：

https://www.cnblogs.com/wangzhuxing/p/5223881.html

https://www.cnblogs.com/lixiuran/archive/2014/03/08/3588654.html

删除数据必然会在数据文件中造成不连续的空白空间,而当插入数据时,这些空白空间则会被利用起来.于是造成了数据的存储位置不连续,以及物理存储顺序与理论上的排序顺序不同,这种是数据碎片.实际上数据碎片分为两种,一种是单行数据碎片,另一种是多行数据碎片.前者的意思就是一行数据,被分成N个片段,存储在N个位置.后者的就是多行数据并未按照逻辑上的顺序排列.当有大量的删除和插入 *** 作时,必然会产生很多未使用的空白空间,这些空间就是多出来的额外空间.索引也是文件数据,所以也会产生索引碎片,理由同上,大概就是顺序紊乱的问题.Engine 不同,OPTIMIZE 的 *** 作也不一样的,MyISAM 因为索引和数据是分开的,所以 OPTIMIZE 可以整理数据文件,并重排索引。这样不但会浪费空间，并且查询速度也更慢。

查看碎片信息：

Index_length 代表索引的总量

Data_free 代表碎片数量

从information_schema中获取信息：

碎片整理：

过程时间长短取决于表大小和碎片多少，

返回结果optimize status OK则整理完成；

---