ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

MySQL如何进行索引重建操作?

2019-10-20 09:55:02  阅读:288  来源: 互联网

标签:20 08 MySQL t1 索引 mysql TABLE 重建


在MySQL数据库中,没有类似于SQL Server数据库或Oracle数据库中索引重建的语法(ALTER INDEX ... REBUILD),那么在MySQL数据库中,是否有什么方式重建索引呢? 在官方文档中"2.11.10 Rebuilding or Repairing Tables or Indexes"中,提到下面三种方式可以Rebuild Index

 

·         Dump and Reload Method

 

·         ALTER TABLE Method

 

·         REPAIR TABLE Method

 

 

另外, OPTIMIZE TABLE也会对索引进行重建,下面我们来简单验证、测试一下,如有不对或不足的地方,敬请指正。

 

 

第一种方法(mysqldump导出然后重新导入),相当于重新CREATE INDEXES , 这里就不讨论了。下面我们来看看其它几种方法,那么要判断索引是否REBUILD了呢?我们来测试验证一下吧,新建测试表如下:

 

 

CREATE TABLE t1 (
    c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    c2 VARCHAR(100),
    c3 VARCHAR(100) )
ENGINE=InnoDB;
 
create index ix_t1_c2 on t1(c2);

 

 

 

DROP INDEX + CREATE INDEX方法

 

这种方法过于简单,这里不叙说了。其实也没有啥好说的。

 

 

 

ALTER TABLE方法

 

 

那么我们能否在MySQL中找到索引的创建或修改时间呢?经过查证,目前而言,MySQL中是没有相关系统表或视图会记录索引的创建时间的,我们可以用间接的方法来间接验证,有些方法不是特别可靠和准确,最准确的方法应该是阅读源码:

 

 

1:表的创建时间,可以间接推断索引的创建时间。因为索引的创建时间肯定在表的创建时间之后。

 

2:对应表的idb文件的修改或创建时间(若文件从创建后不曾修改过则可认为创建时间=修改时间,关于更多详细内容,参考Linux如何查找文件的创建时间,当然这种方法不是非常准确。我们知道,对于InnoDB存储引擎的表而言,对应的索引数据存储在ibd文件中,所以文件的创建时间或修改时间是间接判断索引创建时间。如果存储引擎为MyISAM的话,还有专门的索引文件MYI。

 

注意:show indexes from tablename不会显示索引创建时间

 

mysql> SELECT table_name,create_time FROM  information_schema.TABLES WHERE table_name='t1';
+------------+---------------------+
| TABLE_NAME | CREATE_TIME         |
+------------+---------------------+
| t1         | 2019-10-20 08:18:33 |
+------------+---------------------+
1 row in set (0.01 sec)

 

 

然后我们对表进行ALTER TABLE t1 ENGINE = InnoDB;进行操作后,然后去验证表的创建时间,如下所示,其实ALTER TABLE xxx ENGINE=InnoDB 其实等价于REBUILD表(REBUILD表就是重建表的意思),所以索引也等价于重新创建了。

 

 

clip_image001

 

 

在另外一个窗口,我们对比t1.ibd的创建时间,如下所示,也间接验证了表和索引都REBUILD了。(这里是MySQL 8.0.18 ,如果是之前的版本,还有frm之类的文件。)

 

 

 
[root@db-server MyDB]# ls -lrt t1*
-rw-r-----. 1 mysql mysql 131072 Oct 20 08:18 t1.ibd
[root@db-server MyDB]# stat t1.ibd
  File: ‘t1.ibd’
  Size: 131072          Blocks: 224        IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 106665154   Links: 1
Access: (0640/-rw-r-----)  Uid: ( 1000/   mysql)   Gid: ( 1000/   mysql)
Context: system_u:object_r:mysqld_db_t:s0
Access: 2019-10-20 08:18:25.911990445 +0800
Modify: 2019-10-20 08:18:33.626989940 +0800
Change: 2019-10-20 08:18:33.626989940 +0800
 Birth: -
[root@db-server MyDB]# stat t1.ibd
  File: ‘t1.ibd’
  Size: 131072          Blocks: 224        IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 106665156   Links: 1
Access: (0640/-rw-r-----)  Uid: ( 1000/   mysql)   Gid: ( 1000/   mysql)
Context: system_u:object_r:mysqld_db_t:s0
Access: 2019-10-20 08:20:50.866980953 +0800
Modify: 2019-10-20 08:20:51.744980896 +0800
Change: 2019-10-20 08:20:51.744980896 +0800
 Birth: -

 

clip_image002

 

 

 

 

REPAIR TABLE方法

 

REPAIR TABLE方法用于修复被破坏的表,而且它仅仅能用于MyISAM, ARCHIVE,CSV类型的表。下面的测试环境为MySQL 5.6.41,创建测试表,然后对表进行REPAIR TABLE操作

 

 

mysql> CREATE TABLE t (
    ->     c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    ->     c2 VARCHAR(100),
    ->     c3 VARCHAR(100) )
    -> ENGINE=MyISAM;
Query OK, 0 rows affected (0.01 sec)
 
mysql> SELECT table_name,create_time FROM  information_schema.TABLES WHERE table_name='t';
+------------+---------------------+
| table_name | create_time         |
+------------+---------------------+
| t          | 2019-10-20 08:35:43 |
+------------+---------------------+
1 row in set (0.00 sec)

 

 

然后对表t进行修复操作,发现表的create_time没有变化,如下所示:

 

 

mysql> REPAIR TABLE t;
+--------+--------+----------+----------+
| Table  | Op     | Msg_type | Msg_text |
+--------+--------+----------+----------+
| MyDB.t | repair | status   | OK       |
+--------+--------+----------+----------+
1 row in set (0.01 sec)
 
mysql> SELECT table_name,create_time FROM  information_schema.TABLES WHERE table_name='t';
+------------+---------------------+
| table_name | create_time         |
+------------+---------------------+
| t          | 2019-10-20 08:35:43 |
+------------+---------------------+
1 row in set (0.00 sec)

 

 

clip_image003

 

 

在另外一个窗口,我们发现索引文件t.MYI的修改时间和状态更改时间都变化了,所以判断索引重建(Index Rebuild)了。

 

 

[root@testlnx02 MyDB]# ls -lrt t.*
-rw-rw----. 1 mysql mysql 8608 Oct 20 08:35 t.frm
-rw-rw----. 1 mysql mysql 1024 Oct 20 08:35 t.MYI
-rw-rw----. 1 mysql mysql    0 Oct 20 08:35 t.MYD
[root@testlnx02 MyDB]# stat t.MYI
  File: `t.MYI'
  Size: 1024            Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 1836747     Links: 1
Access: (0660/-rw-rw----)  Uid: (   27/   mysql)   Gid: (   27/   mysql)
Access: 2019-10-20 08:36:02.395428301 +0800
Modify: 2019-10-20 08:35:43.112562600 +0800
Change: 2019-10-20 08:35:43.112562600 +0800
[root@testlnx02 MyDB]# stat t.MYI
  File: `t.MYI'

标签:20,08,MySQL,t1,索引,mysql,TABLE,重建
来源: https://www.cnblogs.com/kerrycode/p/11706730.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有