Tại sao rất nhiều nguồn cấp dữ liệu trong một tập tin mysql?


0
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^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

^ @ là một ký tự đặc biệt trong vim có nghĩa là nguồn cấp dữ liệu, Tại sao có nhiều nguồn cấp dữ liệu trong tệp mysql?


1
"^ @ là một ký tự đặc biệt trong vim có nghĩa là nguồn cấp dữ liệu" - Trên Teletypes cũ (còn gọi là thiết bị đầu cuối), ^@là một ký hiệu thay thế cho Control- @, là tổ hợp phím để tạo ký tự ASCII NUL, còn gọi là 0x00. ^Jlà linefeed, và ^Mlà vận chuyển trở lại.
mùn cưa

Tôi biết ý nghĩa, nó có phải là cần thiết để chèn quá nhiều nguồn cấp dữ liệu trong một tệp mysql không?
phế liệu

Câu trả lời cho câu hỏi này phải là có, vì đây là định dạng được xác định cho tệp MYI. Bất cứ điều gì qua câu trả lời này phải là suy đoán không phù hợp với SU.
davidgo

2
Hiển thị dữ liệu nhị phân (tức là phi văn bản) trong một công cụ được thiết kế để xử lý dữ liệu văn bản có xu hướng dẫn đến kết quả vô nghĩa. Thực sự không có nhiều điều để nói hơn thế.
Bob

Câu trả lời:


4

Một vài điều cần làm rõ:

Đây là một tập tin mẫu .MYI được in bằng 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

Từ ví dụ này, bạn có thể thấy rõ hơn mẫu byte NUL. Cách cấu trúc tệp được định nghĩa trong Hướng dẫn sử dụng nội bộ của MySQL » Công cụ lưu trữ MyISAM » Tệp .MYI .

Có bốn phần:

  • trạng thái - Xảy ra một lần ở đầu tập tin
  • cơ sở - Xảy ra một lần sau khi nhà nước
  • keydef - Xảy ra một lần cho mỗi phím
  • recinfo - Xảy ra một lần cho mỗi lĩnh vực

Trường hợp cơ sở phần bắt đầu được xác định bởi giá trị của base_postrong nhà nước , đó là hai byte bắt đầu từ 0xd. Trong mẫu ở trên, giá trị là 0x00c4, có nghĩa là cơ sở bắt đầu 196 byte ở vị trí thứ 5 trong 000000c0hàng.

Bạn có thể tìm thấy các con trỏ từ trang thủ công để xác định chính xác lý do tại sao tệp .MYI được cấu trúc theo cách của nó.

Để trả lời câu hỏi của bạn:

Tại sao rất nhiều nguồn cấp dữ liệu [NUL byte] trong tệp mysql?

Rất nhiều byte NUL chỉ là các thành viên cấu trúc dữ liệu có giá trị thấp, giống như cách một số nguyên 32 bit nhỏ 1có thể được lưu trữ như 00 00 00 01.

có cần thiết phải chèn quá nhiều nguồn cấp dữ liệu [NUL byte] trong tệp mysql không?

Đúng. Hãy xem state->state.recordsví dụ. Đó là số 64 bit giải thích 2 hàng số tối đa 64 được MyISAM hỗ trợ . Trong ví dụ của tôi (bắt đầu từ 0000001c), tôi chỉ có 6 hàng trong bảng này ( 00 00 00 00 00 00 00 06), nhưng tôi sẽ có 18.446.744.073.709.551.616 nếu mỗi byte của thành viên 0xffthay thế ( ff ff ff ff ff ff ff ff).

Các số không "filler" đó là cần thiết để loại bỏ kích thước của thành viên struct state->state.recordscũng như tất cả các thành viên khác. Mỗi thành viên và kích thước của họ được sao chép trong phần "Tài nguyên bổ sung" bên dưới.


Tài nguyên bổ sung

Cấu trúc của "trạng thái" theo Hướng dẫn sử dụng nội bộ của MySQL

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)

Cấu trúc của "cơ sở" theo Hướng dẫn sử dụng nội bộ của MySQL

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
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.