来看看手册中关于 OPTIMIZE 的描述:

OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

如果您已经删除了表的一大部分,或者如果您已经对含有可变长度行的表(含有VARCHAR, BLOB或TEXT列的表)进行了很多更改,则应使用
OPTIMIZE TABLE。被删除的记录被保持在链接清单中,后续的INSERT操作会重新使用旧的记录位置。您可以使用OPTIMIZE TABLE来重新
利用未使用的空间,并整理数据文件的碎片。 在多数的设置中,您根本不需要运行OPTIMIZE TABLE。即使您对可变长度的行进行了大量的更新,您也不需要经常运行,每周一次或每月一次
即可,只对特定的表运行。 OPTIMIZE TABLE只对MyISAM, BDB和InnoDB表起作用。 注意,在OPTIMIZE TABLE运行过程中,MySQL会锁定表。

原始数据

1,数据量

mysql> select count(*) as total from ad_visit_history; 
+---------+ 
| total | 
+---------+ 
| 1187096 | //总共有118万多条数据 
+---------+ 
1 row in set (0.04 sec)

2,存放在硬盘中的表文件大小

[root@ www.linuxidc.com test1]# ls |grep visit |xargs -i du {} 
382020 ad_visit_history.MYD //数据文件占了380M 
127116 ad_visit_history.MYI //索引文件占了127M 
12 ad_visit_history.frm //结构文件占了12K

3,查看一下索引信息

mysql> show index from ad_visit_history from test1; //查看一下该表的索引信息 
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+ 
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | 
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+ 
| ad_visit_history | 0 | PRIMARY | 1 | id | A | 1187096 | NULL | NULL | | BTREE | | 
| ad_visit_history | 1 | ad_code | 1 | ad_code | A | 46 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | unique_id | 1 | unique_id | A | 1187096 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | ad_code_ind | 1 | ad_code | A | 46 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | from_page_url_ind | 1 | from_page_url | A | 30438 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | ip_ind | 1 | ip | A | 593548 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | port_ind | 1 | port | A | 65949 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | session_id_ind | 1 | session_id | A | 1187096 | NULL | NULL | YES | BTREE | | 
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+ 
8 rows in set (0.28 sec)

索引信息中的列的信息说明。

Table :表的名称。
Non_unique:如果索引不能包括重复词,则为0。如果可以,则为1。
Key_name:索引的名称。
Seq_in_index:索引中的列序列号,从1开始。
Column_name:列名称。
Collation:列以什么方式存储在索引中。在MySQLSHOW INDEX语法中,有值’A’(升序)或NULL(无分类)。
Cardinality:索引中唯一值的数目的估计值。通过运行ANALYZE TABLE或myisamchk -a可以更新。基数根据被存储为整数的统计数据来计数,所以即使对于小型表,该值也没有必要是精确的。基数越大,当进行联合时,MySQL使用该索引的机会就越大。
Sub_part:如果列只是被部分地编入索引,则为被编入索引的字符的数目。如果整列被编入索引,则为NULL。
Packed:指示关键字如何被压缩。如果没有被压缩,则为NULL。
Null:如果列含有NULL,则含有YES。如果没有,则为空。
Index_type:存储索引数据结构方法(BTREE, FULLTEXT, HASH, RTREE)

二,删除一半数据

mysql> delete from ad_visit_history where id>598000; //删除一半数据 
Query OK, 589096 rows affected (4 min 28.06 sec)

[root@ www.linuxidc.com test1]# ls |grep visit |xargs -i du {} //相对应的MYD,MYI文件大小没有变化 
382020 ad_visit_history.MYD 
127116 ad_visit_history.MYI 
12 ad_visit_history.frm

按常规思想来说,如果在数据库中删除了一半数据后,相对应的.MYD,.MYI文件也应当变为之前的一半。但是删除一半数据后,.MYD.MYI尽然连1KB都没有减少,这是多么的可怕啊。

我们在来看一看,索引信息
mysql> show index from ad_visit_history; 
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+ 
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | 
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+ 
| ad_visit_history | 0 | PRIMARY | 1 | id | A | 598000 | NULL | NULL | | BTREE | | 
| ad_visit_history | 1 | ad_code | 1 | ad_code | A | 23 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | unique_id | 1 | unique_id | A | 598000 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | ad_code_ind | 1 | ad_code | A | 23 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | from_page_url_ind | 1 | from_page_url | A | 15333 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | ip_ind | 1 | ip | A | 299000 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | port_ind | 1 | port | A | 33222 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | session_id_ind | 1 | session_id | A | 598000 | NULL | NULL | YES | BTREE | | 
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+ 
8 rows in set (0.00 sec)

对比一下,这次索引查询和上次索引查询,里面的数据信息基本上是上次一次的一本,这点还是合乎常理。

三,用optimize table来优化一下

??mysql> optimize table ad_visit_history; //数据表数据删除或更新后留下的碎片优化语句
+------------------------+----------+----------+----------+ 
| Table | Op | Msg_type | Msg_text | 
+------------------------+----------+----------+----------+ 
| test1.ad_visit_history | optimize | status | OK | 
+------------------------+----------+----------+----------+ 
1 row in set (1 min 21.05 sec)

1,查看一下.MYD,.MYI文件的大小

??[root@ www.linuxidc.com test1]# ls |grep visit |xargs -i du {} 
182080 ad_visit_history.MYD //数据文件差不多为优化前的一半 
66024 ad_visit_history.MYI //索引文件也一样,差不多是优化前的一半 
12 ad_visit_history.frm

2,查看一下索引信息
??mysql> show index from ad_visit_history; 
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+ 
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | 
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+ 
| ad_visit_history | 0 | PRIMARY | 1 | id | A | 598000 | NULL | NULL | | BTREE | | 
| ad_visit_history | 1 | ad_code | 1 | ad_code | A | 42 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | unique_id | 1 | unique_id | A | 598000 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | ad_code_ind | 1 | ad_code | A | 42 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | from_page_url_ind | 1 | from_page_url | A | 24916 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | ip_ind | 1 | ip | A | 598000 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | port_ind | 1 | port | A | 59800 | NULL | NULL | YES | BTREE | | 
| ad_visit_history | 1 | session_id_ind | 1 | session_id | A | 598000 | NULL | NULL | YES | BTREE | | 
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+ 
8 rows in set (0.00 sec)

从以上数据我们可以得出,ad_code,ad_code_ind,from_page_url_ind等索引机会差不多都提高了85%,这样效率提高了好多。

四,小结

结合mysql官方网站的信息,个人是这样理解的。当你删除数据时,mysql并不会回收,被已删除数据的占据的存储空间,以及索引位。而是空在那里,而是等待新的数据来弥补这个空缺,这样就有一个缺少,如果一时半会,没有数据来填补这个空缺,那这样就太浪费资源了。所以对于写比较频烦的表,要定期进行optimize,一个月一次,看实际情况而定了。

表碎片处理方法OPTIMIZE的更多相关文章

  1. Mysql--数据表碎片优化方法

    碎片产生原因: 大量批量插入和删除操作数据库,基于线性表的顺序存储结构的特点,出现了大量的空间碎片.一.优化步骤: 1.查看整库的情况 2.方便优化 3.整库所有表, 包含行数 索引长度 碎片空间 二 ...

  2. 使用OPTIMIZE TABLE命令来整理表碎片实践

    操作环境:ubuntu 14.10   mysql 5.6.25 对含有BLOB或TEXT字段的表,若经常做修改或删除类的操作,需要定期执行OPTIMIZE TABLE命令来整理碎片. 1.creat ...

  3. mysql optimize整理表碎片

    当您的库中删除了大量的数据后,您可能会发现数据文件尺寸并没有减小.这是因为删 除操作后在数据文件中留下碎片所致.optimize table 可以去除删除操作后留下的数据文件碎片,减小文件尺寸,加快未 ...

  4. 表优化 altering table OPTIMIZE TABLE `sta_addr_copy`

    表优化 altering table OPTIMIZE TABLE `sta_addr_copy` [总结] 1.实际测试的结果是,在state sqlaltering table OPTIMIZE ...

  5. Oracle 分区表的新增、修改、删除、合并。普通表转分区表方法

    一. 分区表理论知识 Oracle提供了分区技术以支持VLDB(Very Large DataBase).分区表通过对分区列的判断,把分区列不同的记录,放到不同的分区中.分区完全对应用透明. Orac ...

  6. Oracle 数据库整理表碎片

    Oracle 数据库整理表碎片 转载:http://kyle.xlau.org/posts/table-fragmentation.html 表碎片的来源 当针对一个表的删除操作很多时,表会产生大量碎 ...

  7. oracle_分区表的新增、修改、删除、合并。普通表转分区表方法

    一. 分区表理论知识Oracle提供了分区技术以支持VLDB(Very Large DataBase).分区表通过对分区列的判断,把分区列不同的记录,放到不同的分区中.分区完全对应用透明. Oracl ...

  8. Mysql Innodb 表碎片整理

    一.为什么会产生碎片 简单的说,删除数据必然会在数据文件中造成不连续的空白空间,而当插入数据时,这些空白空间则会被利用起来.于是造成了数据的存储位置不连续,以及物理存储顺序与理论上的排序顺序不同,这种 ...

  9. 08 Oracle表碎片查询以及整理(高水位线)

    Oracle表碎片查询以及整理(高水位线) 1.表碎片的来源 当针对一个表的删除操作很多时,表会产生大量碎片.删除操作释放的空间不会被插入操作立即重用,甚至永远也不会被重用. 2.怎样确定是否有表碎片 ...

随机推荐

  1. vue-grid-layout

    vue-grid-layout    vue-grid-layout is a grid layout system, like Gridster, for Vue.js. Heavily inspi ...

  2. USART 串口

    串口不工作 请逐一检查: 是否正确配置复用IO口(先用RCC_APB2PeriphClockCmd在RCC寄存器中先开启GPIOx的时钟使能,再用 GPIO_Init 进行IO复用配置) 是否正确配置 ...

  3. spring boot过滤器FilterRegistrationBean

    有2种方式可以实现过滤器 1:通过FilterRegistrationBean实例注册 2:通过@WebFilter注解生效 这里选择第一种,因为第二种不能设置过滤器之间的优先级 为了演示优先级,这里 ...

  4. Python第一课-Python的下载与安装

    官网 https://www.python.org/ 我们安装的是windows 系统 Python3和Python2版本不兼容,我们下载最新的Python3.7.4 下载executatable版本 ...

  5. 面试系列20 生产环境中的redis是怎么部署的

    redis cluster,10台机器,5台机器部署了redis主实例,另外5台机器部署了redis的从实例,每个主实例挂了一个从实例,5个节点对外提供读写服务,每个节点的读写高峰qps可能可以达到每 ...

  6. Xcode9.4.1官方下载链接地址

    More Downloads for Apple Developershttps://developer.apple.com/download/more/ Xcode 9.4.1https://dow ...

  7. 2018-8-10-win10-uwp-如何判断一个对象被移除

    title author date CreateTime categories win10 uwp 如何判断一个对象被移除 lindexi 2018-08-10 19:16:50 +0800 2018 ...

  8. bind()的模拟实现

    上一篇对call和apply的模拟实现做了一个梳理,可参见:模拟实现call.apply,下面将具体研究一下bind啦啦啦 1. bind和call/apply的差别 bind方法会创建一个新函数,返 ...

  9. 常用Linux Tips(不定期更新)

    查看本机所有开放端口 lsof -i -P | grep -i listen 查看一段文本单词出现频率 awk '{b[length($0)]++;total_lines++;for(i=1;i< ...

  10. C++ 系列:C++ 内存布局

    1 前言 了解你所使用的编程语言究竟是如何实现的,对于C++程序员可能特别有意义.首先,它可以去除我们对于所使用语言的神秘感,使我们不至于对于编译器干的活感到完全不可思议:尤其重要的是,它使我们在De ...