可以看到,当前表的碎片率超高了,50.6%。
天津ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联建站的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:18980820575(备注:SSL证书合作)期待与您的合作!
有三种办法整理碎片
这三种操作都是先创建一个临时表复制完成后再删除旧表,所以在执行操作的过程中磁盘会先增大。
会锁表
会锁表
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不大的情况下,数据拷贝继续。
工具在等待的时候,会打印进程报告。如果replica停止了,会立即打印进程报告,然后在每个进程报告期间重复。
--check-interval
type: time; default: 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
简写: -A; type: 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 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引入了一些新的问题,而且大部分场景下比较鸡肋,官方打算弃用了
参考:
楼主的意思应该是由于数据库设计时使用了允许NULL的字段,由于一些不规范的操作,使得指数据库中存在着一些"空"数据,这个就是所谓的"碎片"了,这些碎片的存在会影响数据库的查询效率,不知道我说的是不是楼主的意思?如果是的话,直接DELETE就行,或者优化字段.
删除数据必然会在数据文件中造成不连续的空白空间,而当插入数据时,这些空白空间则会被利用起来.于是造成了数据的存储位置不连续,以及物理存储顺序与理论上的排序顺序不同,这种是数据碎片.实际上数据碎片分为两种,一种是单行数据碎片,另一种是多行数据碎片.前者的意思就是一行数据,被分成N个片段,存储在N个位置.后者的就是多行数据并未按照逻辑上的顺序排列.当有大量的删除和插入操作时,必然会产生很多未使用的空白空间,这些空间就是多出来的额外空间.索引也是文件数据,所以也会产生索引碎片,理由同上,大概就是顺序紊乱的问题.Engine 不同,OPTIMIZE 的操作也不一样的,MyISAM 因为索引和数据是分开的,所以 OPTIMIZE 可以整理数据文件,并重排索引。这样不但会浪费空间,并且查询速度也更慢。
查看碎片信息:
Index_length 代表索引的总量
Data_free 代表碎片数量
从information_schema中获取信息:
碎片整理:
过程时间长短取决于表大小和碎片多少,
返回结果optimize status OK则整理完成;
查看碎片信息:
Index_length 代表索引的总量
Data_free 代表碎片数量
从information_schema中获取信息:
碎片整理:
过程时间长短取决于表大小和碎片多少,
返回结果optimize status OK则整理完成;
碎片整理过程会添加表级排他锁,需要找非繁忙期进行操作。
我们都知道,在mysql (这里只探讨innodb) 中delete数据,并非真实删除,而是在这行数据上打了一个del的标记,所以这行占用的空间也并不会释放,但是空间可以被复用,所以期望用delete数据来释放空间的同学可以醒醒了。这样就造成了空间上的碎片,那么如果干掉这些碎片呢。
这里先说结论,alter table语句可以触发表重建,消除碎片空间。
mysql中的数据存储结构大概是下面这个样子的
而delete掉的标记会记录在头信息中。
做个实验,看看空间是否真的没有释放;
创建一张表user,并插入很多数据
查看表的文件大小
再随便插入几条
ok这里看到文件大小增加了16k,这是因为mysql的一页就是16k,所以文件大小是16k、16k的增长的。
这时候我们删除大量的数据再次查看文件大小,仍然是272k,索命,数据虽然删除,但是空间没有释放。
这里我们对主键执行一个alter table语句
再次查看文件大小
ok 文件大小明显的减少,这里说明主键的alter语句会重建表,并且释放碎片空间;
这时候我们再删除大量的数据再次查看文件大小,这里我们对普通列执行一个alter table语句
再次查看文件大小
ok 文件大小明显的减少,这里说明普通列的alter语句会重建表,并且释放碎片空间;