今天在看CU的时候,发现有人问有关optimize来表优化的问题,当年因为这个问题,困扰我很长一段时间,今天有空我把这个问题,用实际数据来展示出来,让大家可以亲眼来看看,optimize
table的重要作用,而不是似是而非的估计了。

一,原始数据

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,一个月一次,看实际情况而定了。

举个例子来说吧。有100个php程序员辞职了,但是呢只是人走了,php的职位还在那里,这些职位不会撤销,要等新的php程序来填补这些空位。招一个好的程序员,比较难。我想大部分时间会空在那里。哈哈。

五,手册中关于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会锁定表。

实例说明optimize table在优化MySQL时很重要的更多相关文章

  1. 实例说明optimize table在优化mysql时很重要

    今天在看CU的时候,发现有人问有关optimize来表优化的问题,当年因为这个问题,困扰我很长一段时间,今天有空我把这个问题,用实际数据来展示出来,让大家可以亲眼来看看,optimize table的 ...

  2. optimize table在优化mysql时很重要

    一个表的数据量有1000W条,那么查看这么表占据的硬盘空间时会发现,数据本身是300M,索引是200M 这个时候,删除掉500W条数据,这个时候数据本身150M,而索引还是200M左右 你删除数据时, ...

  3. optimize table 表优化问题

    语法: optimize table '表名' 一,原始数据 1,数据量 2,存放在硬盘中的表文件大小 3,查看一下索引信息 索引信息中的列的信息说明. Table :表的名称.Non_unique: ...

  4. optimize table 删除空洞--MYSQL

    来看看手册中关于 OPTIMIZE 的描述: OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ... 如果您已经删除 ...

  5. optimize table table_name myisam mysql自动清除删除过留下的空记录

    optimize table table_name 这个可以清除你表里面的空记录,每次清除的时候记得锁表 lock tables table_name  write|read; unlock tabl ...

  6. mysql下优化表和修复表命令使用说明(REPAIR TABLE和OPTIMIZE TABLE)

    随着mysql的长期使用,可以修复表来优化,优化时减少磁盘占用空间.方便备份. REPAIR TABLE `table_name` 修复表 OPTIMIZE TABLE `table_name` 优化 ...

  7. mysql下优化表和修复表命令(repair table、optimize table)

    随着mysql的长期使用,肯定会出现一些问题,一般情况下mysql表无法访问,就可以修复表了,优化时减少磁盘占用空间,方便备份. repair table table_name //修复表 optim ...

  8. mysql下优化表和修复表命令使用说明(REPAIR TABLE和OPTIMIZE TABLE)

    REPAIR TABLE `table_name` 修复表 OPTIMIZE TABLE `table_name` 优化表 show create table tablename   表结构 REPA ...

  9. mysql之 OPTIMIZE TABLE整理碎片

    来看看手册中关于 OPTIMIZE 的描述: OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ... 如果您已经删除 ...

随机推荐

  1. errcode 4103 invalid page hint 小程序模板消息推送遇到的坑

    invalid page hint一直提示这个坑爹的就是,我的小程序没发布之前,也就是测试版本用这个格式是可以的 /pages/myGroup/myGroup?groupid=22***但是发布成功以 ...

  2. RAID常用级别的比较

    [转]RAID常用级别的比较 特点 硬盘及容量 性能及安全 典型应用 raid 0 用于平行存储,即条带.其原理是把连续的数据分成几份,然后分散存储到阵列中的各个硬盘上.任何一个磁盘故障,都将导致数据 ...

  3. volatile关键字的特性总结

    当一个变量定义为volatile后,它将具备两个特性: 1.保证此变量对所有线程的可见性,所谓"可见性",,是指当一个线程修改了这个变量的值,新值对于其他线程来说是可以立即得知的. ...

  4. element-ui+vuex共享自定义方法进行表单验证 validator

    element-ui的官网上写的自定义表单验证,方法都是写在单vue文件中的,不容易共享.怎么使用vuex将方法共享出来,各个组件都能用呢? 如下是一个验证age的数据, rules:{ age:[{ ...

  5. JS大小写字母转换

    var a = "ABCd"; console.log(a.toLowerCase());//转换成小写 console.log(a.toUpperCase());//转换成大写

  6. css实现切角效果

    1. 一个切角 思路:如果我们要得到有一个切角的元素,我们只需要使用一个径向渐变就可以达到这个目标,这个渐变需要把一个透明色标放在切角处,然后再相同的位置设置另一个色标,并且把它的颜色设置成我们想要的 ...

  7. window64 PHP ffmpeg详解简单上手 音频amr转mp3

    从网上找了一大堆关于window 64 ffmpeg的信息,都是又长又不关键,让人难消化. 我只要简单的amr转MP3格式而已. 终于搞明白.自己总结了下! 希望能帮助到喜欢言简意赅,一眼上手的同学. ...

  8. win8使用putty登录虚拟机linux

    从下午两点开始在尝试,差不多用了6个小时候到现在终于成功了! 连接器使用的是putty,只要知道虚拟机的ip地址就可以尝试连接,所以首先查询虚拟机上的ip地址,使用命令: ifconfig 出现提示: ...

  9. 优雅的处理Redis访问超时

    很长一段时间以来,一直在项目中使用Redis作为辅助存储,确切来说是利用Redis的内存存储,而不是将其作为缓存.比如常见的利用Set集合来判断某个数值是否存在,或者将来自不同请求的数据放在Redis ...

  10. [转载]innodb 的预读

    innodb在io的优化上有个比较重要的特性为预读,innodb以64个page为一个extent,那么innodb的预读是以page为单位还是以extent? 这样就进入了下面的话题:linear ...