91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

mysql的frm文件報錯怎么修復

發布時間:2022-02-17 16:01:42 來源:億速云 閱讀:261 作者:iii 欄目:MySQL數據庫

本文小編為大家詳細介紹“mysql的frm文件報錯怎么修復”,內容詳細,步驟清晰,細節處理妥當,希望這篇“mysql的frm文件報錯怎么修復”文章能幫助大家解決疑惑,下面跟著小編的思路慢慢深入,一起來學習新知識吧。

在mysql中,frm的意思為“表定義”,是描述數據表結構的文件。frm文件是用來保存每個數據表的元數據信息,包括表結構的定義等。frm文件跟數據庫存儲引擎無關,也就是任何存儲引擎的數據表都必須有frm文件,命名方式為“數據表名.frm”。

本教程操作環境:windows7系統、mysql8版本、Dell G3電腦。

在mysql中,frm的意思為“表定義”,是描述數據表結構的文件。

在MYSQL中建立任何一張數據表,在其數據目錄對應的數據庫目錄下都有對應表的.frm文件,.frm文件是用來保存每個數據表的元數據(meta)信息,包括表結構的定義等。

.frm文件跟數據庫存儲引擎無關,也就是任何存儲引擎的數據表都必須有.frm文件,命名方式為數據表名.frm,如user.frm. .frm文件可以用來在數據庫崩潰時恢復表結構。

通常frm文件是不會損壞的,但是如果出現特殊情況出現frm文件損壞也不要放棄希望,例如下面報錯:

150821 16:31:27 [ERROR] /usr/local/mysql51/libexec/mysqld: Incorrect information in file: './t/test1.frm'

當修復MyISAM和InnoDB表時,MySQL服務會首先去調用frm文件,所以我們只能通過修復frm文件進行后面的數據恢復。

MySQL通過sql/table.cc的create_frm()函數創建frm文件,創建出來的frm文件是二進制文件,需要通過hexdump解析成16進制來分析。

create_frm()函數對frm文件頭部定義的代碼

/* Create a .frm file */

File create_frm(THD *thd, const char *name, const char *db,
                const char *table, uint reclength, uchar *fileinfo,
          HA_CREATE_INFO *create_info, uint keys, KEY *key_info)
{
  register File file;
  ulong length;
  uchar fill[IO_SIZE];
  int create_flags= O_RDWR | O_TRUNC;
  ulong key_comment_total_bytes= 0;
  uint i;

  if (create_info->options & HA_LEX_CREATE_TMP_TABLE)
    create_flags|= O_EXCL | O_NOFOLLOW;

  /* Fix this when we have new .frm files;  Current limit is 4G rows (QQ) */
  if (create_info->max_rows > UINT_MAX32)
    create_info->max_rows= UINT_MAX32;
  if (create_info->min_rows > UINT_MAX32)
    create_info->min_rows= UINT_MAX32;

  if ((file= mysql_file_create(key_file_frm,
                               name, CREATE_MODE, create_flags, MYF(0))) >= 0)
  {
    uint key_length, tmp_key_length, tmp, csid;
    bzero((char*) fileinfo,64);
    /* header */
    fileinfo[0]=(uchar) 254;
    fileinfo[1]= 1;
    fileinfo[2]= FRM_VER+3+ test(create_info->varchar);

    fileinfo[3]= (uchar) ha_legacy_type(
          ha_checktype(thd,ha_legacy_type(create_info->db_type),0,0));
    fileinfo[4]=1;
    int2store(fileinfo+6,IO_SIZE);        /* Next block starts here */
    /*
      Keep in sync with pack_keys() in unireg.cc
      For each key:
      8 bytes for the key header
      9 bytes for each key-part (MAX_REF_PARTS)
      NAME_LEN bytes for the name
      1 byte for the NAMES_SEP_CHAR (before the name)
      For all keys:
      6 bytes for the header
      1 byte for the NAMES_SEP_CHAR (after the last name)
      9 extra bytes (padding for safety? alignment?)
    */
    for (i= 0; i < keys; i++)
    {
      DBUG_ASSERT(test(key_info[i].flags & HA_USES_COMMENT) == 
                 (key_info[i].comment.length > 0));
      if (key_info[i].flags & HA_USES_COMMENT)
        key_comment_total_bytes += 2 + key_info[i].comment.length;
    }

    key_length= keys * (8 + MAX_REF_PARTS * 9 + NAME_LEN + 1) + 16
                + key_comment_total_bytes;

    length= next_io_size((ulong) (IO_SIZE+key_length+reclength+
                                  create_info->extra_size));
    int4store(fileinfo+10,length);
    tmp_key_length= (key_length < 0xffff) ? key_length : 0xffff;
    int2store(fileinfo+14,tmp_key_length);
    int2store(fileinfo+16,reclength);
    int4store(fileinfo+18,create_info->max_rows);
    int4store(fileinfo+22,create_info->min_rows);
    /* fileinfo[26] is set in mysql_create_frm() */
    fileinfo[27]=2;                // Use long pack-fields
    /* fileinfo[28 & 29] is set to key_info_length in mysql_create_frm() */
    create_info->table_options|=HA_OPTION_LONG_BLOB_PTR; // Use portable blob pointers
    int2store(fileinfo+30,create_info->table_options);
    fileinfo[32]=0;                // No filename anymore
    fileinfo[33]=5;                             // Mark for 5.0 frm file
    int4store(fileinfo+34,create_info->avg_row_length);
    csid= (create_info->default_table_charset ?
           create_info->default_table_charset->number : 0);
    fileinfo[38]= (uchar) csid;
    /*
      In future versions, we will store in fileinfo[39] the values of the
      TRANSACTIONAL and PAGE_CHECKSUM clauses of CREATE TABLE.
    */
    fileinfo[39]= 0;
    fileinfo[40]= (uchar) create_info->row_type;
    /* Next few bytes where for RAID support */
    fileinfo[41]= (uchar) (csid >> 8);
    fileinfo[42]= 0;
    fileinfo[43]= 0;
    fileinfo[44]= 0;
    fileinfo[45]= 0;
    fileinfo[46]= 0;
    int4store(fileinfo+47, key_length);
    tmp= MYSQL_VERSION_ID;          // Store to avoid warning from int4store
    int4store(fileinfo+51, tmp);
    int4store(fileinfo+55, create_info->extra_size);
    /*
      59-60 is reserved for extra_rec_buf_length,
      61 for default_part_db_type
    */
    int2store(fileinfo+62, create_info->key_block_size);
    bzero(fill,IO_SIZE);
    for (; length > IO_SIZE ; length-= IO_SIZE)
    {
      if (mysql_file_write(file, fill, IO_SIZE, MYF(MY_WME | MY_NABP)))
      {
        (void) mysql_file_close(file, MYF(0));
        (void) mysql_file_delete(key_file_frm, name, MYF(0));
    return(-1);
      }
    }
  }
  else
  {
    if (my_errno == ENOENT)
      my_error(ER_BAD_DB_ERROR,MYF(0),db);
    else
      my_error(ER_CANT_CREATE_TABLE,MYF(0),table,my_errno);
  }
  return (file);
} /* create_frm */

open_binary_frm()函數對對frm索引部分定義的代碼

for (i=0 ; i < keys ; i++, keyinfo++)
  {
    keyinfo->table= 0;                           // Updated in open_frm
    if (new_frm_ver >= 3)
    {
      keyinfo->flags=       (uint) uint2korr(strpos) ^ HA_NOSAME;
      keyinfo->key_length= (uint) uint2korr(strpos+2);
      keyinfo->key_parts=  (uint) strpos[4];
      keyinfo->algorithm=  (enum ha_key_alg) strpos[5];
      keyinfo->block_size= uint2korr(strpos+6);
      strpos+=8;
    }
    else
    {
      keyinfo->flags=     ((uint) strpos[0]) ^ HA_NOSAME;
      keyinfo->key_length= (uint) uint2korr(strpos+1);
      keyinfo->key_parts=  (uint) strpos[3];
      keyinfo->algorithm= HA_KEY_ALG_UNDEF;
      strpos+=4;
    }

    keyinfo->key_part=     key_part;
    keyinfo->rec_per_key= rec_per_key;
    for (j=keyinfo->key_parts ; j-- ; key_part++)
    {
      *rec_per_key++=0;
      key_part->fieldnr=    (uint16) (uint2korr(strpos) & FIELD_NR_MASK);
      key_part->offset= (uint) uint2korr(strpos+2)-1;
      key_part->key_type=    (uint) uint2korr(strpos+5);
      // key_part->field=    (Field*) 0;    // Will be fixed later
      if (new_frm_ver >= 1)
      {
    key_part->key_part_flag= *(strpos+4);
    key_part->length=    (uint) uint2korr(strpos+7);
    strpos+=9;
      }
      else
      {
    key_part->length=    *(strpos+4);
    key_part->key_part_flag=0;
    if (key_part->length > 128)
    {
      key_part->length&=127;        /* purecov: inspected */
      key_part->key_part_flag=HA_REVERSE_SORT; /* purecov: inspected */
    }
    strpos+=7;
      }
      key_part->store_length=key_part->length;
    }
  }
  keynames=(char*) key_part;
  strpos+= (strmov(keynames, (char *) strpos) - keynames)+1;

  //reading index comments
  for (keyinfo= share->key_info, i=0; i < keys; i++, keyinfo++)
  {
    if (keyinfo->flags & HA_USES_COMMENT)
    {
      keyinfo->comment.length= uint2korr(strpos);
      keyinfo->comment.str= strmake_root(&share->mem_root, (char*) strpos+2,
                                         keyinfo->comment.length);
      strpos+= 2 + keyinfo->comment.length;
    } 
    DBUG_ASSERT(test(keyinfo->flags & HA_USES_COMMENT) == 
               (keyinfo->comment.length > 0));
  }

hexdump是Linux下的一個二進制文件查看工具,可以將二進制文件轉換為ASCII、10進制、16進制或8進制進行查看。

hexdump 參數
-C 每一字節以16進制顯示,一行共16個字節,顯示十六進制存儲的文本內容
-b 每一字節以八進制顯示,一行共16個字節,一行開始以十六進制顯示偏移值;
  0000000 177 105 114 106 002 001 001 000 000 000 000 000 000 000 000 000
-c 每一字節以ASCII字符顯示,其余同上;
  0000000 177 E L F 002 001 001 \0 \0 \0 \0 \0 \0 \0 \0 \0
-n 只解釋指定長度字節
  單位:默認十進制,0x或0X開頭則為16進制,0開頭則為8進制。默認為字節,b則為512字節,k則為1024字節,m則為1048576字節
-d 雙字節十進制顯示
-o 雙字節八進制顯示
-v 去除中間顯示的“*”字符
-x 雙字節十六進制顯示
-e 格式化參數

實例版本與表字符集:

參考:https://www.percona.com/blog/2015/07/09/obtain-mysql-version-frm-file/

建表的實例版本0x033
語句hexdump -s 0x33 -n 2 -v -d table.frm 
[root@test1 ~]# hexdump -s 0x33 -n 2 -v -d /data/3308/test/test1.frm
0000033   50153
0000035
所以版本為5.1.53,因為5.1/5.5和5.6在字段類型定義上有不同,所以確定好建表實例版本很重要,字段類型定義見下面

表字符集0x026 
21=utf8
08=latin1
1c=GBK
語句hexdump -s 0x26 -n 1 table.frm

frm列屬性:

、列序號(初始列序號為4)
、字段長度,整形長度
、字段長度,latin1字符集字符類型長度,GBK字符集字符類型varchar長度*2,varchar(30)相當于就是60字節長度,換成16進制是3c,utf8字符集字符類型varchar長度*3,varchar(30)相當于就是90字節長度,換成16進制是5a
、
、
、
、
、Flags for zerofill, unsigned, etc.(int 1b)
、Additional flags,and scale if decimal/numeric(DEFAULT NULL 80,NOT NULL 40,DEFAULT 'VALUE' 00)
、代碼定義unireg_type,AUTO_INCREMENT of
、
、代碼定義interval_nr
、字段類型
、字符集
、備注長度
、備注長度

字段類型(注意5.6版本字段類型有不同,會影響數據恢復):

Data type for v5.1&v5.5 (v5.6)
fe=char
fa=mediumtext
f6=decimal
fc=text
of=varchar
01=tinyint
02=smallint
03=int
04=float
05=real
07=timestamp (v5.6 11=timestamp)
08=bigint
09=mediumint
10=bit
ob=time (v5.6 13=time)
oc=datetime (v5.6 12=datetime)
0d=year
0e=date

表中所含索引:

偏移量在0x1000之后的一段是frm索引部分,用hexdump -C打開后很容易找到
0x1000:有幾個索引
0x1001:全部索引包含幾個字段
索引名是明文,具體索引結構見示例。

表:

CREATE TABLE `test3` (
  `a` int(11) NOT NULL,
  `b` varchar(10) DEFAULT NULL,
  `c` int(11) NOT NULL,
  PRIMARY KEY (`a`),
  UNIQUE KEY `uniq_1` (`b`,`c`),
  KEY `idx_1` (`c`,`b`),
  KEY `idx_2` (`c`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

十六進制文件打開:

[root@test1 ~]# hexdump -C /data/3308/test/test3.frm 
00000000  fe 01 0a 0c 03 00 00 10  01 00 00 30 00 00 74 05  |...........0..t.|
00000010  28 00 00 00 00 00 00 00  00 00 00 02 79 00 09 00  |(...........y...|
00000020  00 05 00 00 00 00 21 00  00 00 00 00 00 00 00 74  |......!........t| #表字符集
00000030  05 00 00 e9 c3 00 00 10  00 00 00 00 00 00 00 00  |................| #標紅的是建表實例版本號
00000040  2f 2f 00 00 20 00 00 00  00 00 00 00 00 00 00 00  |//.. ...........|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  04 06 00 00 1d 00 00 00  04 00 01 00 00 00 01 80  |................|
00001010  02 00 00 1b 40 04 00 68  00 22 00 02 00 00 00 02  |....@..h."......|
00001020  80 06 00 00 00 80 1e 00  03 80 25 00 00 1b 40 04  |..........%...@.|
00001030  00 69 00 22 00 02 00 00  00 03 80 25 00 00 1b 40  |.i.".......%...@|
00001040  04 00 02 80 06 00 00 00  80 1e 00 01 00 04 00 01  |................|
00001050  00 00 00 03 80 25 00 00  1b 40 04 00 ff 50 52 49  |.....%...@...PRI|
00001060  4d 41 52 59 ff 75 6e 69  71 5f 31 ff 69 64 78 5f  |MARY.uniq_1.idx_|
00001070  31 ff 69 64 78 5f 32 ff  00 00 00 00 00 00 00 00  |1.idx_2.........|
00001080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001570  00 00 00 00 ff 00 00 00  00 00 00 00 00 00 00 00  |................|
00001580  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001590  00 00 00 00 00 00 00 00  00 00 00 00 00 00 06 00  |................|
000015a0  49 6e 6e 6f 44 42 00 00  00 00 00 00 00 00 00 00  |InnoDB..........|
000015b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002000  9a 01 00 10 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00002010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002100  01 00 03 00 3f 00 34 00  00 00 28 00 08 00 00 00  |....?.4...(.....|
00002110  00 00 00 00 00 00 50 00  16 00 01 00 00 00 00 00  |......P.........|
00002120  3f 00 04 03 02 14 29 20  20 20 20 20 20 20 20 20  |?.....)         |
00002130  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
00002140  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 00  |               .|
00002150  04 00 02 61 00 05 00 02  62 00 06 00 02 63 00 04  |...a....b....c..|
00002160  02 0b 0b 00 02 00 00 1b  40 00 00 00 03 3f 00 00  |........@....?..|
00002170  05 02 1e 1e 00 06 00 00  00 80 00 00 00 0f 21 00  |..............!.|
00002180  00 06 02 0b 0b 00 25 00  00 1b 40 00 00 00 03 3f  |......%...@....?|
00002190  00 00 ff 61 ff 62 ff 63  ff 00                    |...a.b.c..|

通過上面的顏色區分,圈出的黃色部分是索引屬性,下面紅藍綠三色是三列屬性。

列屬性結構:

mysql的frm文件報錯怎么修復

  • 紅色部分:字段序號(4開始,4、5、6就是字段第一第二第三)

  • 藍色部分:字段長度

  • 棕色部分:是否為空

  • 綠色部分:字段類型

  • 黃色部分:字符集

索引屬性結構:

mysql的frm文件報錯怎么修復

索引頭部:

  • 淡藍色部分:索引統計數

  • 粉色部分:索引總共有多少列

索引主體:

  • 棕色部分:是否唯一索引

  • 紅色部分:表中列的序號

  • 綠色部分:表中對應列的屬性

字段默認值:

字段默認值不保存在字段屬性中,而是保存在描述表引擎的那段中
int類型默認值保存為十六進制需轉換十進制,char類型默認值保存為十六進制文本可通過hexdump -C直接看到
如果沒有索引段則默認值在,0x1011后,如果有索引段,則位置順延
例如表
CREATE TABLE `test1` (
  `a` int(11) NOT NULL DEFAULT '2010',
  `b` varchar(10) NOT NULL DEFAULT '2011' ,
  `c` int(11) default '30',
  `d` varchar(10) NOT NULL DEFAULT 'Yes' 
)engine=innodb default charset=utf8;

*
00001000  00 00 00 00 02 00 ff 00  00 00 00 00 00 00 00 00  |................|
00001010  fe da 07 00 00 04 32 30  31 31 00 00 00 00 00 00  |......2011......|
00001020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001030  00 00 00 00 1e 00 00 00  03 59 65 73 00 00 00 00  |.........Yes....|
00001040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001050  00 00 00 00 00 00 00 00  00 06 00 49 6e 6e 6f 44  |...........InnoD|
00001060  42 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |B...............|
00001070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
column a:da 07 00 00
column b:04 32 30 31 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
column c:1e 00 00 00 
column d:03 59 65 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00需要注意char字段的默認值是根據字段長度和字符集相關的,如上表varchar(10),utf8是3bit,就是30個十六進制長度。

讀到這里,這篇“mysql的frm文件報錯怎么修復”文章已經介紹完畢,想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會,如果想了解更多相關內容的文章,歡迎關注億速云行業資訊頻道。

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

龙陵县| 东阿县| 镇远县| 平阳县| 玉屏| 寿宁县| 合川市| 迁安市| 翁源县| 康保县| 鸡西市| 宁都县| 吕梁市| 宁蒗| 高青县| 红原县| 崇文区| 香河县| 霸州市| 衡南县| 绥芬河市| 金秀| 赤水市| 荥阳市| 广饶县| 平阳县| 英山县| 二连浩特市| 犍为县| 邢台县| 陈巴尔虎旗| 余干县| 满洲里市| 盐池县| 同江市| 望城县| 聂拉木县| 全南县| 昌都县| 吴忠市| 玛沁县|