Почему столько строк в файле mysql?

347
scrapy
cat -A dfs.MYI  M-~M-~^G^A^@^@^AT^@M-0^@d^@M-D^@^A^@^@^A^@^X^A^@^@^@^@^@M-^?^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@M-^?M-^?M-^?M-^?M-^?M-^?M-^?M-^?^@^@^@^@^@^@^D^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@"M-,^@^@^@^@^@^@^@^@^@^@^@^@M-^?M-^?M-^?M-^?M-^?M-^?M-^?M-^?M-^?M-^?M-^?M-^?M-^?M-^?M-^?M-^?^@^@^@^@^@^@^@^@Q:^UM-a^@^@^@^@^@^@^@^A^@^@^@^@Q:^UM-a^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^D^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^D^@^@^@^G^@^@^@^D^@^@^@^D^@^@^@^T^@^@^@^B^@^@^@^@^F^F^A^@^@^@^@^@^D^@^@^P^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^A^@^A^D^@^@^I^@^I^@^I^L?^@^@^@^@^@@^@^C^@^@^@^A^@^@^@^@^@^@^@^A^@^@^@^@^@^@^C^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 

^ @ - это специальный символ в vim, который означает перевод строки. Почему в файле mysql столько строк перевода?

0
* «^ @ - это специальный символ в vim, означающий перевод строки» * - На старых телетайпах (или терминалах), `^ @` является альтернативной нотацией для Control- @, который является нажатием клавиши для генерирования символа ASCII NUL, он же 0x00. «^ J» - перевод строки, а «^ M» - возврат каретки. sawdust 5 лет назад 1
Я знаю смысл, нужно ли вставлять так много строк в файл mysql? scrapy 5 лет назад 0
Ответ на этот вопрос должен быть да, так как это формат, определенный для файла MYI. Что-нибудь после этого ответа должно быть предположением, не подходящим для SU. davidgo 5 лет назад 0
Отображение двоичных (т.е. нетекстовых) данных в инструменте, предназначенном для работы с текстовыми данными, приводит к бессмысленным результатам. Там действительно не так много, чтобы сказать, чем это. Bob 5 лет назад 2

1 ответ на вопрос

4
Deltik

Несколько вещей, чтобы прояснить:

Вот пример файла .MYI, напечатанного с hexdump -C:

root@host1 [/var/lib/mysql/deltik_main]# hexdump -C nodes.MYI 00000000 fe fe 07 01 00 01 01 8c 00 b0 00 64 00 c4 00 01 |...........d....| 00000010 00 00 01 00 08 01 00 00 00 00 00 ff 00 00 00 00 |................| 00000020 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 06 ff ff ff ff ff ff ff ff 00 00 00 00 |................| 00000040 00 00 08 00 00 00 00 00 00 00 03 14 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 00 00 00 06 00 00 00 00 6d c0 14 47 00 00 05 85 |........m..G....| 00000070 00 00 01 d5 00 00 00 00 00 00 00 03 00 00 00 00 |................| 00000080 00 00 04 00 ff ff ff ff ff ff ff ff 00 00 00 00 |................| 00000090 00 00 00 00 5a f0 11 99 00 00 00 00 00 00 00 01 |....Z...........| 000000a0 00 00 00 00 5a 85 b3 8e 00 00 00 00 00 00 00 00 |....Z...........| 000000b0 00 00 00 00 5a f0 11 99 00 00 00 00 00 00 00 06 |....Z...........| 000000c0 00 00 00 01 00 00 00 00 00 00 04 00 00 00 00 00 |................| 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000000f0 00 00 0a e0 00 00 0a e5 00 00 00 08 80 00 0a ef |................| 00000100 00 00 00 14 00 00 00 0a 00 00 00 03 06 05 01 01 |................| 00000110 00 01 00 01 04 00 00 10 00 00 00 00 00 00 00 00 |................| 00000120 00 00 00 00 00 00 00 00 01 01 00 11 04 00 00 0a |................| 00000130 00 0a 00 0a 04 3f 00 00 00 00 00 40 00 04 00 00 |.....?.....@....| 00000140 00 00 00 00 00 00 00 03 00 04 00 00 00 00 03 00 |................| 00000150 04 00 00 00 00 08 00 81 00 00 00 00 08 01 02 00 |................| 00000160 00 00 00 04 00 0c 00 00 00 00 08 00 41 00 00 00 |............A...| 00000170 00 08 02 02 00 00 00 00 08 02 02 00 00 00 00 08 |................| 00000180 01 02 00 00 00 00 08 04 02 00 00 00 00 00 00 00 |................| 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 00 3e 00 00 00 01 00 00 00 00 00 00 00 00 00 02 |.>..............| 00000410 00 00 00 00 00 8c 00 00 00 03 00 00 00 00 01 1c |................| 00000420 00 00 00 04 00 00 00 00 02 40 00 00 00 05 00 00 |.........@......| 00000430 00 00 01 a8 00 00 00 06 00 00 00 00 02 e0 00 00 |................| 00000440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000800 

Из этого примера вы можете более четко увидеть шаблон байтов NUL. Структура файла определяется в Руководстве по внутренним компонентам MySQL » Механизм хранения MyISAM » Файл .MYI .

Есть четыре раздела:

  • состояние - происходит один раз в начале файла
  • база - происходит один раз после состояния
  • keydef - происходит один раз для каждого ключа
  • recinfo - происходит один раз для каждого поля

Где начинается базовый раздел, определяется значением base_posin state, которое начинается с двух байтов 0xd. В приведенном выше примере это значение 0x00c4означает, что база начинается с 196 байтов в 5- й позиции 000000c0строки.

Вы можете найти указатели на странице руководства, чтобы точно определить, почему файл .MYI так структурирован.

Чтобы ответить на ваши вопросы:

Почему так много строк [NUL байтов] в файле MySQL?

Большая часть байтов NUL является просто членами структуры данных, которые имеют низкие значения, так же, как 1может храниться как маленькое 32-битное целое число 00 00 00 01.

Это необходимо для вставки так много перевода строки [NUL байт] в файл MySQL?

Да. Взгляните на state->state.recordsпример. Это 64-битное число, которое объясняет 2 64 строки максимального числа, поддерживаемых MyISAM . В моем примере (начиная с 0000001c) у меня есть только 6 строк в этой таблице ( 00 00 00 00 00 00 00 06), но у меня было бы 18,446,744,073,709,551,616, если бы 0xffвместо этого был каждый байт члена ( ff ff ff ff ff ff ff ff).

Эти «заполняющие» нули необходимы для разметки размера члена структуры, state->state.recordsа также всех остальных членов. Каждый член и его размер воспроизводится в разделе «Дополнительные ресурсы» ниже.


Дополнительные ресурсы

Структура "состояния" в соответствии с MySQL Internals Manual

Name Size Dump From Example File Comment ---- ---- ---------------------- -------  file_version 4 FE FE 07 01 from myisam_file_magic options 2 00 02 HA_OPTION_COMPRESS_RECORD etc. header_length 2 01 A2 this header example has 0x01A2 bytes state_info_length 2 00 B0 = MI_STATE_INFO_SIZE defined in myisamdef.h base_info_length 2 00 64 = MI_BASE_INFO_SIZE defined in myisamdef.h base_pos 2 00 D4 = where the base section starts key_parts 2 00 03 a key part is a column within a key unique_key_parts 2 00 00 key-parts+unique-parts keys 1 02 here are 2 keys -- I1 and I2 uniques 1 00 number of hash unique keys used internally in temporary tables (nothing to do with 'UNIQUE' definitions) language 1 08 "language for indexes" max_block_size 1 01 fulltext_keys 1 00 # of fulltext keys. = 0 if version <= 4.0 not_used 1 00 to align to 8-byte boundary  state->open_count 2 00 01 state->changed 1 39 set if table updated; reset if shutdown (so one can examine this to see if there was an update without proper shutdown) state->sortkey 1 FF "sorted by this key" (not used) state->state.records 8 00 00 00 00 00 00 00 02 number of actual, un-deleted, records state->state.del 8 00 00 00 00 00 00 00 01 # of deleted records state->split 8 00 00 00 00 00 00 00 03 # of "chunks" (e.g. records or spaces left after record deletion) state->dellink 8 00 00 00 00 00 00 00 07 "Link to next removed "block". Initially = HA_OFFSET_ERROR state->state.key_file_length 8 00 00 00 00 00 00 0c 00 2048 state->state.data_file_length 8 00 00 00 00 00 00 00 15 = size of .MYD file state->state.empty 8 00 00 00 00 00 00 00 00 state->state.key_empty 8 00 00 00 00 00 00 00 00 state->auto_increment 8 00 00 00 00 00 00 00 00 state->checksum 8 00 00 00 00 00 00 00 00 state->process 4 00 00 09 E6 from getpid(). process of last update state->unique 4 00 00 00 0B initially = 0 state->status 4 00 00 00 00 state->update_count 4 00 00 00 04 updated for each write lock (there were 3 inserts + 1 delete, total 4 operations) state->key_root 8 00 00 00 00 00 00 04 00 offset in file where I1 keys start, can be = HA_OFFSET_ERROR 00 00 00 00 00 00 08 00 state->key_root occurs twice because there are two keys state->key_del 8 FF FF FF FF FF FF FF FF delete links for keys (occurs many times if many delete links) state->sec_index_changed 4 00 00 00 00 sec_index = secondary index (presumably) not currently used state->sec_index_used 4 00 00 00 00 "which extra indexes are in use" not currently used state->version 4 3F 3F EB F7 "timestamp of create" state->key_map 8 00 00 00 03 "what keys are in use" state->create_time 8 00 00 00 00 3F 3F EB F7 "time when database created" (actually: time when file made) state->recover_time 8 00 00 00 00 00 00 00 00 "time of last recover" state->check_time 8 00 00 00 00 3F 3F EB F7 "time of last check" state->rec_per_key_rows 8 00 00 00 00 00 00 00 00 state->rec_per_key_parts 4 00 00 00 00 (key_parts = 3, so 00 00 00 00 rec_per_key_parts 00 00 00 00 occurs 3 times) 

Структура «базы» в соответствии с MySQL Internals Manual

Name Size Dump From Example File Comment ---- ---- ---------------------- -------  base->keystart 8 00 00 00 00 00 00 04 00 keys start at offset 1024 (0x0400) base->max_data_file_length 8 00 00 00 00 00 00 00 00 base->max_key_file_length 8 00 00 00 00 00 00 00 00 base->records 8 00 00 00 00 00 00 00 00 base->reloc 8 00 00 00 00 00 00 00 00 base->mean_row_length 4 00 00 00 00 base->reclength 4 00 00 00 07 length(s1)+length(s2) +length(s3)=7 base->pack_reclength 4 00 00 00 07 base->min_pack_length 4 00 00 00 07 base->max_pack_length 4 00 00 00 07 base->min_block_length 4 00 00 00 14 base->fields 4 00 00 00 04 4 fields: 3 defined, plus 1 extra base->pack_fields 4 00 00 00 00 base->rec_reflength 1 04 base->key_reflength 1 04 base->keys 1 02 was 0 at start base->auto_key 1 00 base->pack_bits 2 00 00 base->blobs 2 00 00 base->max_key_block_length 2 04 00 length of block = 1024 bytes (0x0400) base->max_key_length 2 00 10 including length of pointer base->extra_alloc_bytes 2 00 00 base->extra_alloc_procent 1 00 base->raid_type 1 00 base->raid_chunks 2 00 00 base->raid_chunksize 4 00 00 00 00 [extra] that is, filler 6 00 00 00 00 00 00