mysql怎么整理碎片 2021中国银行国庆放几天假( 三 )


查询缓存利用率在25%以下的话说明query_cache_size设置的过大 , 可适当减小;查询缓存利用率在80%以上而且 Qcache_lowmem_prunes50的话说明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 5.6 整理表的碎片 可以看到,当前表的碎片率超高了,50.6% 。
有三种办法整理碎片
这三种操作都是先创建一个临时表复制完成后再删除旧表,所以在执行操作的过程中磁盘会先增大 。
会锁表
会锁表
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: time; default: 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不大的情况下 , 数据拷贝继续 。

推荐阅读