linux 修改mysql字段长度

总是提示错误

ERROR 1064 (42000): You have an error in your SQL syntaxcheck the manual that

corresponds to your MySQL server version for the right syntax to use near 'alert

TABLE toymusiclist CHANGE musiclist musiclist VARCHAR(8000)' at line 1

mysql创建表字段长度范围_Mysql的建表规范与注意事项⼀、 表设计规范

库名、表名、字段名必须使⽤⼩写字母，“_”分割。

库名、表名、字段名必须不超过12个字符。

库名、表名、字段名见名知意，建议使⽤名词⽽不是动词。

建议使⽤InnoDB存储引擎。

存储精确浮点数必须使⽤DECIMAL替代FLOAT和DOUBLE。

建议使⽤UNSIGNED存储⾮负数值。

建议使⽤INT UNSIGNED存储IPV4。

整形定义中不添加长度，⽐如使⽤INT，⽽不是INT(4)。

使⽤短数据类型，⽐如取值范围为0-80时，使⽤TINYINT UNSIGNED。

不建议使⽤ENUM类型，使⽤TINYINT来代替。

尽可能不使⽤TEXT、BLOB类型。

VARCHAR(N)，N表⽰的是字符数不是字节数，⽐如VARCHAR(255)，可以最⼤可存储255个汉字，需要根据实际的宽度来选择N。

VARCHAR(N)，N尽可能⼩，因为MySQL⼀个表中所有的VARCHAR字段最⼤长度是65535个字节，进⾏排序和创建临时表⼀类的内存 *** 作时，会使⽤N的长度申请内存。

表字符集选择UTF8。

使⽤VARBINARY存储变长字符串。

存储年使⽤YEAR类型。

存储⽇期使⽤DATE类型。

存储时间(精确到秒)建议使⽤TIMESTAMP类型，因为TIMESTAMP使⽤4字节，DATETIME使⽤8个字节。

建议字段定义为NOT NULL。

将过⼤字段拆分到其他表中。

禁⽌在数据库中使⽤VARBINARY、BLOB存储图⽚、⽂件等。

表结构变更需要通知DBA审核。

⼆、 索引规范

⾮唯⼀索引必须按照“idx_字段名称_字段名称[_字段名]”进⾏命名。

唯⼀索引必须按照“uniq_字段名称_字段名称[_字段名]”进⾏命名。

索引名称必须使⽤⼩写。

索引中的字段数建议不超过5个。

单张表的索引数量控制在5个以内。

唯⼀键由3个以下字段组成，并且字段都是整形时，使⽤唯⼀键作为主键。

没有唯⼀键或者唯⼀键不符合5中的条件时，使⽤⾃增(或者通过发号器获取)id作为主键。

唯⼀键不和主键重复。

索引字段的顺序需要考虑字段值去重之后的个数，个数多的放在前⾯。

ORDER BY，GROUP BY，DISTINCT的字段需要添加在索引的后⾯。

使⽤EXPLAIN判断SQL语句是否合理使⽤索引，尽量避免extra列出现：Using File Sort，UsingTemporary。

UPDATE、DELETE语句需要根据WHERE条件添加索引。

不建议使⽤%前缀模糊查询，例如LIKE “%weibo”。

对长度过长的VARCHAR字段建⽴索引时，添加crc32或者MD5 Hash字段，对Hash字段建⽴索引。

合理创建联合索引(避免冗余)，(a,b,c) 相当于 (a) 、(a,b) 、(a,b,c)。

合理利⽤覆盖索引。

SQL变更需要确认索引是否需要变更并通知DBA。

三、 SQL语句规范

使⽤prepared statement，可以提供性能并且避免SQL注⼊。

SQL语句中IN包含的值不应过多。

UPDATE、DELETE语句不使⽤LIMIT。

WHERE条件中必须使⽤合适的类型，避免MySQL进⾏隐式类型转化。

SELECT语句只获取需要的字段。

SELECT、INSERT语句必须显式的指明字段名称，不使⽤SELECT *，不使⽤INSERTINTO table()。

使 ⽤SELECT column_name1, column_name2 FROM table WHERE[condition]⽽不是SELECT column_name1 FROM table WHERE[condition]和SELECT column_name2 FROM table WHERE [condition]。

WHERE条件中的⾮等值条件(IN、BETWEEN、、>=)会导致后⾯的条件使⽤不了索引。

避免在SQL语句进⾏数学运算或者函数运算，容易将业务逻辑和DB耦合在⼀起。

INSERT语句使⽤batch提交(INSERT INTO tableVALUES(),(),()……)，values的个数不应过多。

避免使⽤存储过程、触发器、函数等，容易将业务逻辑和DB耦合在⼀起，并且MySQL的存储过程、触发器、函数中存在⼀定的bug。

避免使⽤JOIN。

使⽤合理的SQL语句减少与数据库的交互次数。

不使⽤ORDER BY RAND()，使⽤其他⽅法替换。

建议使⽤合理的分页⽅式以提⾼分页的效率。

统计表中记录数时使⽤COUNT(*)，⽽不是COUNT(primary_key)和COUNT(1)。

禁⽌在从库上执⾏后台管理和统计类型功能的QUERY。

四、 散表规范

每张表数据量建议控制在5000w以下。

可以结合使⽤hash、range、lookup table进⾏散表。

散表如果使⽤md5(或者类似的hash算法)进⾏散表，表名后缀使⽤16进制，⽐如user_ff。

推荐使⽤CRC32求余(或者类似的算术算法)进⾏散表，表名后缀使⽤数字，数字必须从0开始并等宽，⽐如散100张表，后缀从00-99。

使⽤时间散表，表名后缀必须使⽤特定格式，⽐如按⽇散表user_20110209、按⽉散表user_201102。

五、 其他

批量导⼊、导出数据需要DBA进⾏审查，并在执⾏过程中观察服务。

批量更新数据，如update,delete *** 作，需要DBA进⾏审查，并在执⾏过程中观察服务。

产品出现⾮数据库平台运维导致的问题和故障时，如前端被抓站，请及时通知DBA，便于维护服务稳定。

业务部门程序出现bug等影响数据库服务的问题，请及时通知DBA，便于维护服务稳定。

业务部门推⼴活动，请提前通知DBA进⾏服务和访问评估。

如果出现业务部门⼈为误 *** 作导致数据丢失，需要恢复数据，请在第⼀时间通知DBA，并提供准确时间，误 *** 作语句等重要线索。

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

FAQ

1-1.库名、表名、字段名必须使⽤⼩写字母，“_”分割。

a)MySQL有配置参数lower_case_table_names，不可动态更改，Linux系统默认为0，即库表名以实际情况存储，⼤⼩写敏感。如果是1，以⼩写存储，⼤⼩写不敏感。如果是2，以实际情况存储，但以⼩写⽐较。

b) 如果⼤⼩写混合⽤，可能存在abc,Abc,ABC等多个表共存，容易导致混乱。

c) 字段名显⽰区分⼤⼩写，但实际使⽤不区分，即不可以建⽴两个名字⼀样但⼤⼩写不⼀样的字段。

d) 为了统⼀规范， 库名、表名、字段名使⽤⼩写字母。

1-2.库名、表名、字段名必须不超过12个字符。

库名、表名、字段名⽀持最多64个字符，但为了统⼀规范、易于辨识以及减少传输量，必须不超过12字符。

1-3.库名、表名、字段名见名知意，建议使⽤名词⽽不是动词。

a) ⽤户评论可⽤表名usercomment或者comment。

b) 库表是⼀种客观存在的事物，⼀种对象，所以建议使⽤名词。

1-4.建议使⽤InnoDB存储引擎。

a) 5.5以后的默认引擘，⽀持事务，⾏级锁，更好的恢复性，⾼并发下性能更好，对多核，⼤内存，ssd等硬件⽀持更好。

b) 具体⽐较可见附件的官⽅⽩⽪书。

1-5.存储精确浮点数必须使⽤DECIMAL替代FLOAT和DOUBLE。

a) mysql中的数值类型(不包括整型)：

IEEE754浮点数：float (单精度) ， double 或real (双精度)

定点数： decimal或 numeric

单精度浮点数的有效数字⼆进制是24位，按⼗进制来说，是8位；双精度浮点数的有效数字⼆进制是53位，按⼗进制来说，是16 位

⼀个实数的有效数字超过8位，⽤单精度浮点数来表⽰的话，就会产⽣误差！同样，如果⼀个实数的有效数字超过16位，⽤双精度浮点数来表⽰，也会产⽣误差

b)IEEE754标准的计算机浮点数，在内部是⽤⼆进制表⽰的，但在将⼀个⼗进制数转换为⼆进制浮点数时，也会造成误差，原因是不是所有的数都能转换成有限长度的⼆进制数。

即⼀个⼆进制可以准确转换成⼗进制，但⼀个带⼩数的⼗进制不⼀定能够准确地⽤⼆进制来表⽰。

实例：

drop table if exists t

create table t(value float(10,2))

insert into t values(131072.67),(131072.68)

select value from t

+-----------+

|value |

+-----------+

| 131072.67 |

| 131072.69 |

+-----------+

1-6.建议使⽤UNSIGNED存储⾮负数值。

同样的字节数，存储的数值范围更⼤。如tinyint 有符号为 -128-127，⽆符号为0-255

1-7. 如何使⽤INT UNSIGNED存储ip？

使⽤INTUNSIGNED⽽不是char(15)来存储ipv4地址，通过MySQL函数inet_ntoa和inet_aton来进⾏转化。Ipv6地址⽬前没有转化函数，需要使⽤DECIMAL或者两个bigINT来存储。例如：

SELECT INET_ATON('209.207.224.40')

3520061480

SELECT INET_NTOA(3520061480)

209.207.224.40

1-8. INT[M]，M值代表什么含义？

注意数值类型括号后⾯的数字只是表⽰宽度⽽跟存储范围没有关系，⽐如INT(3)默认显⽰3位，空格补齐，超出时正常显⽰，Python、Java客户端等不具备这个功能。

1-10.不建议使⽤ENUM、SET类型，使⽤TINYINT来代替。

a)ENUM，有三个问题：添加新的值要做DDL，默认值问题(将⼀个⾮法值插⼊ENUM(也就是说，允许的值列之外的字符串)，将插⼊空字符串以作为特殊错误值)，索引值问题(插⼊数字实际是插⼊索引对应的值)

实例：

drop table if exists t

create table t(sex enum('0','1'))

insert into t values(1)

insert into t values('3')

select * from t

+------+

| sex |

+------+

| 0 |

| |

+------+

2 rows in set (0.00 sec)

1-11.尽可能不使⽤TEXT、BLOB类型。

a) 索引排序问题，只能使⽤max_sort_length的长度或者⼿⼯指定ORDER BY SUBSTRING(column,length)的长度来排序

b) Memory引擘不⽀持text,blog类型，会在磁盘上⽣成临时表

c) 可能浪费更多的空间

d) 可能⽆法使⽤adaptive hash index

e) 导致使⽤where没有索引的语句变慢

1-13. VARCHAR中会产⽣额外存储吗？

VARCHAR(M)，如果M<256时会使⽤⼀个字节来存储长度，如果M>=256则使⽤两个字节来存储长度。

1-14.表字符集选择UTF8。

a) 使⽤utf8字符集，如果是汉字，占3个字节，但ASCII码字符还是1个字节。

b) 统⼀，不会有转换产⽣乱码风险

c) 其他地区的⽤户(美国、印度、台湾)⽆需安装简体中⽂⽀持，就能正常看您的⽂字，并且不会出现乱码

d)ISO-8859-1编码(latin1)使⽤了单字节内的所有空间，在⽀持ISO-8859-1的系统中传输和存储其他任何编码的字节流都不会被抛弃。即把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题，保存的是原封不动的字节流。

1-15.使⽤VARBINARY存储变长字符串。

⼆进制字节流，不存在编码问题

1-18. 为什么建议使⽤TIMESTAMP来存储时间⽽不是DATETIME？

DATETIME和TIMESTAMP都是精确到秒，优先选择TIMESTAMP，因为TIMESTAMP只有4个字节，⽽DATETIME8个字节。同时TIMESTAMP具有⾃动赋值以及⾃动更新的特性。

如何使⽤TIMESTAMP的⾃动赋值属性？

a) 将当前时间作为ts的默认值：ts TIMESTAMP DEFAULTCURRENT_TIMESTAMP。

b) 当⾏更新时，更新ts的值：ts TIMESTAMP DEFAULT 0 ONUPDATE CURRENT_TIMESTAMP。

c) 可以将1和2结合起来：ts TIMESTAMP DEFAULTCURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP。

1-19.建议字段定义为NOT NULL。

a)如果null字段被索引，需要额外的1字节

b)使索引，索引统计，值的⽐较变得更复杂

c)可⽤0，''代替

d)如果是索引字段，⼀定要定义为not null

1-21.禁⽌在数据库中使⽤VARBINARY、BLOB存储图⽚、⽂件等。

采⽤分布式⽂件系统更⾼效

2. 为什么MySQL的性能依赖于索引？

MySQL的查询速度依赖良好的索引设计，因此索引对于⾼性能⾄关重要。合理的索引会加快查询速度(包括UPDATE和DELETE的速

度，MySQL会将包含该⾏的page加载到内存中，然后进⾏UPDATE或者DELETE *** 作)，不合理的索引会降低速度。

MySQL索引查找类似于新华字典的拼⾳和部⾸查找，当拼⾳和部⾸索引不存在时，只能通过⼀页⼀页的翻页来查找。当MySQL查询不能使⽤索引时，MySQL会进⾏全表扫描，会消耗⼤量的IO。

2-5. 为什么⼀张表中不能存在过多的索引？

InnoDB的secondaryindex使⽤b+tree来存储，因此在UPDATE、DELETE、INSERT的时候需要对b+tree进⾏调整，过多的索引会减慢更新的速度。

2-11. EXPLAIN语句

EXPLAIN语句(在MySQL客户端中执⾏)可以获得MySQL如何执⾏SELECT语句的信息。通过对SELECT语句执⾏EXPLAIN，可以知晓MySQL执⾏该SELECT语句时是否使⽤了索引、全表扫描、临时表、排序等信息。尽量避免MySQL进⾏全表扫描、使⽤临时表、排序等。详见官⽅⽂档。

2-13.不建议使⽤%前缀模糊查询，例如LIKE “%weibo”。

会导致全表扫描

2-14. 如何对长度⼤于50的VARCHAR字段建⽴索引？

下⾯的表增加⼀列url_crc32，然后对url_crc32建⽴索引，减少索引字段的长度，提⾼效率。

CREATE TABLE url(

……

url VARCHAR(255) NOT NULL DEFAULT 0,

url_crc32INT UNSIGNED NOT NULL DEFAULT 0,

……

index idx_url(url_crc32)

)

2-16. 什么是覆盖索引？

InnoDB 存储引擎中，secondaryindex(⾮主键索引)中没有直接存储⾏地址，存储主键值。如果⽤户需要查询secondaryindex中所不包含的数据列时，需要先通过secondaryindex查找到主键值，然后再通过主键查询到其他数据列，因此需要查询两次。

覆盖索引的概念就是查询可以通过在⼀个索引中完成，覆盖索引效率会⽐较⾼，主键查询是天然的覆盖索引。

合理的创建索引以及合理的使⽤查询语句，当使⽤到覆盖索引时可以获得性能提升。

⽐如SELECT email,uid FROM user_email WHEREuid=xx，如果uid不是主键，适当时候可以将索引添加为index(uid,email)，以获得性能提升。

3-3.UPDATE、DELETE语句不使⽤LIMIT。

a) 可能导致主从数据不⼀致

b) 会记录到错误⽇志，导致⽇志占⽤⼤量空间

3-4. 为什么需要避免MySQL进⾏隐式类型转化？

因为MySQL进⾏隐式类型转化之后，可能会将索引字段类型转化成=号右边值的类型，导致使⽤不到索引，原因和避免在索引字段中使⽤函数是类似的。

3-6. 为什么不建议使⽤SELECT *?

增加很多不必要的消耗(cpu、io、内存、⽹络带宽)；增加了使⽤覆盖索引的可能性；当表结构发⽣改变时，前段也需要更新。

3-13. 如何减少与数据库的交互次数？

使⽤下⾯的语句来减少和db的交互次数：

INSERT ... ON DUPLICATE KEY UPDATE

REPLACE

INSERT IGNORE

INSERT INTO values(),()如何结合使⽤多个纬度进⾏散表散库？

例如微博message，先按照crc32(message_id)将message散到16个库中，然后针对每个库中的表，⼀天⽣成⼀张新表。

3-14. 为什么不能使⽤ORDER BY rand()？

因为ORDER BYrand()会将数据从磁盘中读取，进⾏排序，会消耗⼤量的IO和CPU，可以在程序中获取⼀个rand值，然后通过在从数据库中获取对应的值。

3-15. MySQL中如何进⾏分页？

假如有类似下⾯分页语句：

SELECT * FROM table ORDER BY TIME DESC LIMIT 10000,10

这种分页⽅式会导致⼤量的io，因为MySQL使⽤的是提前读取策略。

推荐分页⽅式：

SELECT * FROM table WHERE TIME

SELECT * FROM tableinner JOIN(SELECT id FROM table ORDER BY TIME LIMIT 10000,10) as t USING(id)

3-17.为什么避免使⽤复杂的SQL？

拒绝使⽤复杂的SQL，将⼤的SQL拆分成多条简单SQL分步执⾏。原因：简单的SQL容易使⽤到MySQL的querycache；减少锁表时间特别是MyISAM；可以使⽤多核cpu。

2. InnoDB存储引擎为什么避免使⽤COUNT(*)?

InnoDB表避免使⽤COUNT(*) *** 作，计数统计实时要求较强可以使⽤memcache或者Redis，⾮实时统计可以使⽤单独统计表，定时更新。

￥

5

百度文库VIP限时优惠现在开通,立享6亿+VIP内容

立即获取

mysql创建表字段长度范围_Mysql的建表规范与注意事项

mysql创建表字段长度范围_Mysql的建表规范与注意事项⼀、 表设计规范

库名、表名、字段名必须使⽤⼩写字母，“_”分割。

库名、表名、字段名必须不超过12个字符。

库名、表名、字段名见名知意，建议使⽤名词⽽不是动词。

建议使⽤InnoDB存储引擎。

存储精确浮点数必须使⽤DECIMAL替代FLOAT和DOUBLE。

建议使⽤UNSIGNED存储⾮负数值。

建议使⽤INT UNSIGNED存储IPV4。

第 1 页

整形定义中不添加长度，⽐如使⽤INT，⽽不是INT(4)。

使⽤短数据类型，⽐如取值范围为0-80时，使⽤TINYINT UNSIGNED。

不建议使⽤ENUM类型，使⽤TINYINT来代替。

尽可能不使⽤TEXT、BLOB类型。

VARCHAR(N)，N表⽰的是字符数不是字节数，⽐如VARCHAR(255)，可以最⼤可存储255个汉字，需要根据实际的宽度来选择N。

VARCHAR(N)，N尽可能⼩，因为MySQL⼀个表中所有的VARCHAR字段最⼤长度是65535个字节，进⾏排序和创建临时表⼀类的内存 *** 作时，会使⽤N的长度申请内存。

第 2 页

表字符集选择UTF8。

使⽤VARBINARY存储变长字符串。

存储年使⽤YEAR类型。

存储⽇期使⽤DATE类型。

存储时间(精确到秒)建议使⽤TIMESTAMP类型，因为TIMESTAMP使⽤4字节，DATETIME使⽤8个字节。

建议字段定义为NOT NULL。

将过⼤字段拆分到其他表中。

禁⽌在数据库中使⽤VARBINARY、BLOB存储图⽚、⽂件等。

表结构变更需要通知DBA审核。

第 3 页

⼆、 索引规范

⾮唯⼀索引必须按照“idx_字段名称_字段名称[_字段名]”进⾏命名。

唯⼀索引必须按照“uniq_字段名称_字段名称[_字段名]”进⾏命名。

索引名称必须使⽤⼩写。

索引中的字段数建议不超过5个。

单张表的索引数量控制在5个以内。

唯⼀键由3个以下字段组成，并且字段都是整形时，使⽤唯⼀键作为主键。

没有唯⼀键或者唯⼀键不符合5中的条件时，使⽤⾃增(或者通过发号器获取)id作为主键。

第 4 页

唯⼀键不和主键重复。

索引字段的顺序需要考虑字段值去重之后的个数，个数多的放在前⾯。

ORDER BY，GROUP BY，DISTINCT的字段需要添加在索引的后⾯。

使⽤EXPLAIN判断SQL语句是否合理使⽤索引，尽量避免extra列出现：Using File Sort，UsingTemporary。

UPDATE、DELETE语句需要根据WHERE条件添加索引。

不建议使⽤%前缀模糊查询，例如LIKE “%weibo”。

对长度过长的VARCHAR字段建⽴索引时，添加crc32或者MD5 Hash字段，对Hash字段建⽴索引。

FAT32的一个重要的特点是完全支持长文件名。长文件名依然是记录在目录项中的。为了低版本的OS或程序能正确读取长文件名文件，系统自动为所有长文件名文件创建了一个对应的短文件名，使对应数据既可以用长文件名寻址，也可以用短文件名寻址。不支持长文件名的OS或程序会忽略它认为不合法的长文件名字段，而支持长文件名的OS或程序则会以长文件名为显式项来记录和编辑，并隐藏起短文件名。

    当创建一个长文件名文件时，系统会自动加上对应的短文件名，其一般有的原则：

    (1)、取长文件名的前6个字符加上"~1"形成短文件名，扩展名不变。

    (2)、如果已存在这个文件名，则符号"~"后的数字递增，直到5。

    (3)、如果文件名中"~"后面的数字达到5，则短文件名只使用长文件名的前两个字母。通过数学 *** 纵长文件名的剩余字母生成短文件名的后四个字母，然后加后缀"~1"直到最后(如果有必要，或是其他数字以避免重复的文件名)。

    (4)、如果存在老OS或程序无法读取的字符，换以"_"

长文件名的实现有赖于目录项偏移为0xB的属性字节，当此字节的属性为：只读、隐藏、系统、卷标，即其值为0FH时，DOS和WIN32会认为其不合法而忽略其存在。这正是长文件名存在的依据。将目录项的0xB置为0F，其他就任由系统定义了，Windows9x或Windows 2000、XP通常支持不超过255个字符的长文件名。系统将长文件名以13个字符为单位进行切割，每一组占据一个目录项。所以可能一个文件需要多个目录项，这时长文件名的各个目录项按倒序排列在目录表中，以防与其他文件名混淆。

    长文件名中的字符采用unicode形式编码(一个巨大的进步哦)，每个字符占据2字节的空间。其目录项定义如表15。

表15   FAT32长文件目录项32个字节的表示定义
字节偏移 (16进制)	字节数	定义
0x0	1	属性字节位意义	7	保留未用
6	1表示长文件最后一个目录项
5	保留未用
4	顺序号数值
3
2
1
0
0x1~0xA	10	长文件名unicode码①
0xB	1	长文件名目录项标志，取值0FH
0xC	1	系统保留
0xD	1	校验值(根据短文件名计算得出)
0xE~0x19	12	长文件名unicode码②
0x1A~0x1B	2	文件起始簇号(目前常置0)
0x1C~0x1F	4	长文件名unicode码③

   系统在存储长文件名时，总是先按倒序填充长文件名目录项，然后紧跟其对应的短文件名。从表15可以看出，长文件名中并不存储对应文件的文件开始簇、文件大小、各种时间和日期属性。文件的这些属性还是存放在短文件名目录项中，一个长文件名总是和其相应的短文件名一一对应，短文件名没有了长文件名还可以读，但长文件名如果没有对应的短文件名，不管什么系统都将忽略其存在。所以短文件名是至关重要的。在不支持长文件名的环境中对短文件名中的文件名和扩展名字段作更改(包括删除，因为删除是对首字符改写E5H)，都会使长文件名形同虚设。长文件名和短文件名之间的联系光靠他们之间的位置关系维系显然远远不够。其实，长文件名的0xD字节的校验和起很重要的作用，此校验和是用短文件名的11个字符通过一种运算方式来得到的。系统根据相应的算法来确定相应的长文件名和短文件名是否匹配。这个算法不太容易用公式说明，我们用一段c程序来加以说明。

    假设文件名11个字符组成字符串shortname[],校验和用chknum表示。得到过程如下：

int i，j,chknum=0

    for (i=11i>0i--)

        chksum = ((chksum &1) ? 0x80 : 0) + (chksum >>1) + shortname[j++]

如果通过短文件名计算出来的校验和与长文件名中的0xD偏移处数据不相等。系统无论如何都不会将它们配对的。

    依据长文件名和短文件名对目录项的定义，加上对簇的编号和链接，FAT32上数据的读取便游刃有余了。

---