mysql之 OPTIMIZE TABLE整理碎片
来看看手册中关于 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 test_history;
+---------+
| total |
+---------+
| 1187096 | //总共有118万多条数据
+---------+
1 row in set (0.04 sec)
2,存放在硬盘中的表文件大小
[root@ www.linuxidc.com test1]# ls |grep visit |xargs -i du {}
382020 test_history.MYD //数据文件占了380M
127116 test_history.MYI //索引文件占了127M
12 test_history.frm //结构文件占了12K
3,查看一下索引信息
mysql> show index from test_history from test1; //查看一下该表的索引信息
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| test_history | 0 | PRIMARY | 1 | id | A | 1187096 | NULL | NULL | | BTREE | |
| test_history | 1 | ad_code | 1 | ad_code | A | 46 | NULL | NULL | YES | BTREE | |
| test_history | 1 | unique_id | 1 | unique_id | A | 1187096 | NULL | NULL | YES | BTREE | |
| test_history | 1 | ad_code_ind | 1 | ad_code | A | 46 | NULL | NULL | YES | BTREE | |
| test_history | 1 | from_page_url_ind | 1 | from_page_url | A | 30438 | NULL | NULL | YES | BTREE | |
| test_history | 1 | ip_ind | 1 | ip | A | 593548 | NULL | NULL | YES | BTREE | |
| test_history | 1 | port_ind | 1 | port | A | 65949 | NULL | NULL | YES | BTREE | |
| test_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 test_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 test_history.MYD
127116 test_history.MYI
12 test_history.frm
按常规思想来说,如果在数据库中删除了一半数据后,相对应的.MYD,.MYI文件也应当变为之前的一半。但是删除一半数据后,.MYD.MYI尽然连1KB都没有减少,这是多么的可怕啊。
我们在来看一看,索引信息
mysql> show index from test_history;
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| test_history | 0 | PRIMARY | 1 | id | A | 598000 | NULL | NULL | | BTREE | |
| test_history | 1 | ad_code | 1 | ad_code | A | 23 | NULL | NULL | YES | BTREE | |
| test_history | 1 | unique_id | 1 | unique_id | A | 598000 | NULL | NULL | YES | BTREE | |
| test_history | 1 | ad_code_ind | 1 | ad_code | A | 23 | NULL | NULL | YES | BTREE | |
| test_history | 1 | from_page_url_ind | 1 | from_page_url | A | 15333 | NULL | NULL | YES | BTREE | |
| test_history | 1 | ip_ind | 1 | ip | A | 299000 | NULL | NULL | YES | BTREE | |
| test_history | 1 | port_ind | 1 | port | A | 33222 | NULL | NULL | YES | BTREE | |
| test_history | 1 | session_id_ind | 1 | session_id | A | 598000 | NULL | NULL | YES | BTREE | |
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
8 rows in set (0.00 sec)
对比一下,这次索引查询和上次索引查询,里面的数据信息基本上是上次一次的一本,这点还是合乎常理。
三,用optimize table来优化一下
show table status like 'XXX'\G;
data_free选项代表数据碎片。
针对MySQL的不同数据库存储引擎,在optimize使用清除碎片,回收闲置的数据库空间,把分散存储(fragmented)的数据和索引重新挪到一起(defragmentation),对I/O速度有好处。
mysql> optimize table test_history; //删除数据后的优化
+------------------------+----------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+------------------------+----------+----------+----------+
| test1.test_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 test_history.MYD //数据文件差不多为优化前的一半
66024 test_history.MYI //索引文件也一样,差不多是优化前的一半
12 test_history.frm
2,查看一下索引信息
mysql> show index from test_history;
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------------+------------+-------------------+--------------+---------------+-----------+-------------+----------+--------+------+------------+---------+
| test_history | 0 | PRIMARY | 1 | id | A | 598000 | NULL | NULL | | BTREE | |
| test_history | 1 | ad_code | 1 | ad_code | A | 42 | NULL | NULL | YES | BTREE | |
| test_history | 1 | unique_id | 1 | unique_id | A | 598000 | NULL | NULL | YES | BTREE | |
| test_history | 1 | ad_code_ind | 1 | ad_code | A | 42 | NULL | NULL | YES | BTREE | |
| test_history | 1 | from_page_url_ind | 1 | from_page_url | A | 24916 | NULL | NULL | YES | BTREE | |
| test_history | 1 | ip_ind | 1 | ip | A | 598000 | NULL | NULL | YES | BTREE | |
| test_history | 1 | port_ind | 1 | port | A | 59800 | NULL | NULL | YES | BTREE | |
| test_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,一个月一次,看实际情况而定了。
转载于:https://www.cnblogs.com/andy6/p/9543278.html
mysql之 OPTIMIZE TABLE整理碎片相关推荐
- 【MySQL】OPTIMIZE TABLE 的碎片整理功能
1.概述 OPTIMIZE TABLE 的碎片整理功能. (1)创建测试表 t,字段 id 和 context 的类型分别为 varchar(100)和 text: mysql> create ...
- mysql中OPTIMIZE TABLE的作用
1.先来看看多次删除插入操作后的表索引情况 mysql> SHOW INDEX FROM `tbl_name`;+----------+------------+------------+--- ...
- mysql optimize 作用_mysql optimize table
mysql 数据文件的使用是只扩展,不回收.对表执行delete之后,磁盘上数据文件是不会缩小的. 通常的做法,是先逻辑导出,然后truncate 原表(或者删除重建),再导入. 另外还有一种方法是o ...
- optimize table优化mysql例子
原始数据 数据量 mysql> select count(*) as total from ad_visit_history; +---------+ | total | +-------- ...
- mysql optimize 用法_mysql中OPTIMIZE TABLE的作用
在使用mysql的时候有时候,可能会发现尽管一张表删除了许多数据,但是这张表表的数据文件和索引文件却奇怪的没有变小.这是因为mysql在删除数据(特别是有Text和BLOB)的时候,会留下许多的数据空 ...
- MySQL的analyze table和optimize table对表进行定期优化
1.analyze table优化表的统计信息 mysql> show index from t; +-------+------------+---------------------+--- ...
- mysql进阶:optimize table 优化表命令 Table does not support optimize, doing recreate + analyze instead
optimize table table_name 1. 问题描述 在使用mysql的时候有时候,可能会发现尽管一张表删除了许多数据,但是这张表表的数据文件和索引文件却奇怪的没有变小.这是因为mysq ...
- 小谈 MySQL 第十一话·InnoDB 碎片整理
官方建议不要经常(每小时或每天)进行碎片整理,一般根据实际情况,只需要每周或每月整理一次即可: 目录 一.MySQL 表碎片化(Table Fragmentation) 的原因 二.MySQL 中如何 ...
- 小白学习MySQL - InnoDB支持optimize table?
MySQL数据库中进行表空间整理,可以用的一种操作就是optimize table, OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL]TABLE tbl_name [, tb ...
最新文章
- 百度API_获取当前详细地址
- 646. Maximum Length of Pair Chain 最长的链条长度
- c语言程序设计基础的考试题,c语言程序设计基础的考试题.doc
- 1. 请简述mysql数据库的锁机制_【MySQL入门】之MySQL数据库的锁机制(二)
- python可视化库matplotlib_Python数据可视化库-Matplotlib(一)
- 120天的努力,从牵引力教育开始逆袭的!
- linux系统rc路由配置_Linux下路由配置梳理
- OneNote无法同时设置中英文字体设置解决办法
- php语音机器人,php运营版语音机器人接单源代码带完美教程
- 枯燥的生活需要每日情话
- 销售订单配置项目说明
- 我只说一次,这样用领英开发国外客户,屡试不爽!
- Python爬虫-网贷之家P2P机构排名查询
- 常用的前端在线引用JS
- 会声会影2023最新中文旗舰版新功能介绍
- 10个程序员可以接私活的平台和一些建议!
- Android开发之监听手机来电
- python中完整爬取股票财务信息和公司基本信息含xpath
- 敏捷 scrum_敏捷教练,Scrum大师,交付经理
- ARP家族--ARP,代理ARP,Gratuitous ARP
热门文章
- lampp mysql最大连接数_mysql连接数问题备份
- git 子模块_Git子模块的问题
- 服务器mbr文件丢失吗,硬盘中了MBR病毒不要急,一款工具帮你搞定,保证数据不丢失!...
- java程序结构_java程序的三种结构
- java http 返回json_java发起http请求获取返回的Json对象方法
- 路由器有一个android设备连接不上,Android http连接 – 多个设备无法连接同一台服务器...
- Python的安装路径
- tar解压失败:gzip: stdin: not in gzip format
- 运行报错java.lang.Exception: No runnable methods
- HTML学习笔记:设置超链接文本修饰