本文共 21828 字，大约阅读时间需要 72 分钟。
一、MySQL数据库文件介绍 MySQL的每个数据库都对应存放在一个与数据库同名的文件夹中，MySQL数据库文件包括MySQL所建数据库文件和MySQL所用存储引擎创建的数据库文件。 1、MySQL创建并管理的数据库文件： .frm文件：存储数据表的框架结构，文件名与表名相同，每个表对应一个同名frm文件，与操作系统和存储引擎无关，即不管MySQL运行在何种操作系统上，使用何种存储引擎，都有这个文件。 除了必有的.frm文件，根据MySQL所使用的存储引擎的不同（MySQL常用的两个存储引擎是MyISAM和InnoDB），存储引擎会创建各自不同的数据库文件。 2、MyISAM数据库表文件： .MYD文件：即MY Data，表数据文件 .MYI文件：即MY Index，索引文件 .log文件：日志文件 3、InnoDB采用表空间（tablespace）来管理数据，存储表数据和索引， InnoDB数据库文件（即InnoDB文件集，ib-file set）： ibdata1、ibdata2等：系统表空间文件，存储InnoDB系统信息和用户数据库表数据和索引，所有表共用 .ibd文件：单表表空间文件，每个表使用一个表空间文件（file per table），存放用户数据库表数据和索引 日志文件： ib_logfile1、ib_logfile2 二、MySQL数据库存放位置： 1、MySQL如果使用MyISAM存储引擎，数据库文件类型就包括.frm、.MYD、.MYI，默认存放位置是C:\Documentsand Settings\All Users\Application Data\MySQL\MySQL Server 5.1\data 2、MySQL如果使用InnoDB存储引擎，数据库文件类型就包括.frm、ibdata1、.ibd，存放位置有两个，.frm文件默认存放位置是C:\Documents and Settings\All Users\ApplicationData\MySQL\MySQL Server 5.1\data，ibdata1、.ibd文件默认存放位置是MySQL安装目录下的data文件
Innodb存储引擎管理主要基于两个文件：表空间数据文件和日志文件。
InnoDB存储它的表＆索引在一个表空间中，表空间可以包含数个文件（或原始磁盘分区）。
如果没有指定InnoDB配置选项，MySQL将在MySQL数据目录下创建一个名为ibdata1的10MB大小的自动扩展数据文件，以及两个名为ib_logfile0和ib_logfile 1的5MB大小的日志文件。
ibdata1的大小在my.cnf文件中配置：innodb_data_file_path = ibdata1:10G:autoextend
可以设置最大数据文件限制，以免超过系统支持的最大文件：
innodb_data_file_path = ibdata1:100M:autoextend:max:500M
日志文件大小在my.cnf文件中配置：innodb_log_file_size = 256M innodb_log_files_in_group = 2
Innodb存储引擎可以使用共享表空间或独立表空间，使用独立表空间时，需要将innodb_file_per_table加到配置文件中，也可以在variables中开启。
共享表空间是将所有的表的数据和索引保存在ibdata1中，这样的缺点是拷贝时必须拷贝整个大文件，而且删除表后容易产生碎片。
独立表空间是为每个表建立一个.ibd文件用来存储数据和.frm用来存数据词典信息，这样，mysql就将innodb表的数据存入各自对应的.ibd文件中了，但结构等信息还是会写入ibdata。
innodb_file_per_table变量只能在配置文件里修改，不能使用set global ...
将innodb_file_per_table关闭之后，建立innoDB表时只生成.frm文件，数据和索引都保存在共享表空间ibdata1中。
mysql data文件夹下的ibdata1 文件作用
这个文件超级大， 查了一下， 大概的作用如下
是储存的格式 INNODB类型数据状态下， ibdata用来储存文件的数据 而库名的文件夹里面的那些表文件只是结构而已 由于mysql4.1默认试innodb，所以这个文件默认就存在了http://man.chinaunix.net/database/mysql/inonodb_zh/2.htm 这个链接试innodb的中文参考， innodb的东西可以在my.ini中设置 innodo中文参考全文如下 为了在 MySQL-Max-3.23 中使用 InnoDB 表，你必须在配置文件‘my.cnf’或‘my.ini’（WINDOWS系统）中的[mysqld] 区中详细指定配置参数。
作为最小设置，在 3.23 中你必须在 innodb_data_file_path 上指定数据文件名能及大小。如果在‘my.cnf’中没有指定innodb_data_home_dir，系统将在 MySQL 的 datadir 目录下创建数据文件。如果将 innodb_data_home_dir 设为一个空串，那可以在 innodb_data_file_path 中给定一个绝对路径。在 MySQL-4.0 中可以不设定 innodb_data_file_path ：MySQL-4.0 将默认地在 datadir 目录下建立一个 10 MB 大小自扩充(auto-extending)的文件‘ibdata1’(在MySQL-4.0.0 与 4.0.1 中数据文件的大小为 64 MB 并且是非自扩充的(not auto-extending))。
为了得到更好的性能你必须所示的例子明确地设定 InnoDB 启动参数。
从 3.23.50 版和 4.0.2 版开始，InnoDB 允许在 innodb_data_file_path 中设置的最一个数据文件描述为 auto-extending。 innodb_data_file_path 语法如下所示：
pathtodatafile:sizespecification;pathtodatafile:sizespec;... ...;pathtodatafile:sizespec[:autoextend[:max:sizespecification]]
如果用 autoextend 选项描述最后一个数据文件，当 InnoDB 用尽所有表自由空间后将会自动扩充最后一个数据文件，每次增量为 8 MB。示例：
innodb_data_home_dir = innodb_data_file_path = /ibdata/ibdata1:100M:autoextend
指定 InnoDB 只建立一个最初大小为 100 MB 并且当表空间被用尽时以 8MB 每块增加的数据文件。如果硬盘空间不足，可以再添加一个数据文件并将其放在其它的硬盘中。 举例来说：先检查硬盘空间的大小，设定 ibdata1 文件使它接近于硬盘空余空间大小并为 1024 * 1024 bytes (= 1 MB)的倍数， 将 ibdata1 明确地指定在 innodb_data_file_path 中。在此之后可以添加另一个数据文件：
innodb_data_home_dir = innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
注意：设定文件大小时一定要注意你的OS是否有最大文件尺寸为2GB的限制！InnoDB是不会注意你的OS文件尺寸限制的， 在一些文件系统中你可能要设定最大容量限制：
innodb_data_home_dir = innodb_data_file_path = /ibdata/ibdata1:100M:autoextend:max:2000M
一个简单的 my.cnf 例子。 假设你的计算机有 128 MB RAM 和一个硬盘。下面的例子是为了使用 InnoDB 而在 my.cnf或 my.ini 文件中可能所作的一些配置。我们假设你运行的是 MySQL-Max-3.23.50 及以上版本，或 MySQL-4.0.2 及以上版本。
这个示例适合大部分不需要将 InnoDB 数据文件和日志文件放在几个盘上的 Unix 和 Windows 用户。这个例子在 MySQL 的datadir 目录(典型的为 /mysql/data)中创建一个自扩充(auto-extending)的数据文件 ibdata1 和两个 InnoDB 运行日志文件ib_logfile0 和 ib_logfile1 以及 ib_arch_log_0000000000 档案文件。
[mysqld] #在这里加入其它 的 MySQL 服务器配置 #... # 数据文件必须 # 能够容下数据与索引 # 确定有足够的 # 磁盘空间 innodb_data_file_path = ibdata1:10M:autoextend # 设置缓冲池的大小为 # 你的主内存大小的 # 50 - 80 % set-variable = innodb_buffer_pool_size=70M set-variable = innodb_additional_mem_pool_size=10M # 设置日志文件的大小约为 # 缓冲池(buffer pool) # 大小的 25 % set-variable = innodb_log_file_size=20M set-variable = innodb_log_buffer_size=8M # 如果丢失最近几个事务影响 # 不大的话可以设置 # .._flush_log_at_trx_commit = 0 innodb_flush_log_at_trx_commit=1
InnoDB 不会自己建立目录，必须自己使用操作系统命令建立相应的目录。检查你的 MySQL 服务程序在 datadir 目录里 有足够的权限建立文件。
注意：在某些文件系统中 数据文件大小必须小于2G！ 所有运行日志文件的大小总和必须小于 2G 或 4G,这依赖于具体的 MySQL 系统版本。 数据文件的总和必须大于等于 10 MB.
当第一次建立 InnoDB 数据库时，建议最好以命令行方式启动 MySQL 服务。这样 InnoDB 数据库建立时的提示信息将在屏幕上显示，从而可以看到建立过程。 下面第 3 节所示就是 InnoDB 数据库建立时的屏幕显示。例如，在 Windows 下使用下列指令启动 mysqld-max.exe ：
your-path-to-mysqld>mysqld-max --console
在 Windows 系统下 my.cnf 或 my.ini 放在哪里？规则如下 ：
SET 命令查看 WINDIR 目录值
Unix 下在哪里指定配置文件？在 Unix 下 mysqld 按下列顺序搜索配置文件：
--defaults-extra-file=.... 设置的默认文件 COMPILATION_DATADIR 是 MySQL 的数据文件目录，它是在 mysqld 被编译时以 ./configure 设置指定 (典型的是/usr/local/mysql/data 二进制安装或 /usr/local/var 以源安装)。
如果不有确定 mysqld 从哪里读取 my.cnf 或 my.ini，可以在第一命令行上详细指定它的目录：mysqld --defaults-file=your_path_to_my_cnf。
InnoDB 的数据文件目录是对 innodb_data_home_dir 与 innodb_data_file_path 的数据文件名或目录联合 ，如果需要将在它们之间增加一个“/”或“\”。如果关键字 innodb_data_home_dir 没有在 my.cnf 中明确指定，它的默认值为“.”，即目录“./”，这意味着 MySQL 的 datadir of MySQL.
一个高级的 my.cnf 示例。假设你有一台 2 GB RAM 和3个 60 GB 硬盘(路径分别为 "/", "/dr2" 和 “/dr3”)装有 Linux。下面的例子是为了使用 InnoDB 而在 my.cnf 文件中可能所作的一些配置。
注意：InnoDB 不会自己创建文件目录：你必须自己创建它们。使用 Unix 或 MS-DOS mkdir 命令建立相应的数据与日志文件目录。
[mysqld] #在这里加入其它 的 MySQL 服务器配置 #... # 如果不使用InnoDB表将一列一行注释去除 # skip-innodb # # 数据文件必须 # 能够容下数据与索引 # 确定有足够的 # 磁盘空间 innodb_data_file_path = /ibdata/ibdata1:2000M;/dr2/ibdata/ibdata2:2000M:autoextend # 设置缓冲池的大小为 # 你的主内存大小的 # 50 - 80 %，但是 # 在 Linux x86 总内存 # 使用必须小于 2 GB set-variable = innodb_buffer_pool_size=1G set-variable = innodb_additional_mem_pool_size=20M innodb_log_group_home_dir = /dr3/iblogs # .._log_arch_dir 必须和 # .._log_group_home_dir一样； # 从 4.0.6开始，可以省略它 innodb_log_arch_dir = /dr3/iblogs set-variable = innodb_log_files_in_group=3 # 设置日志文件的大小约为 # 缓冲池(buffer pool) # 大小的 15 % set-variable = innodb_log_file_size=150M set-variable = innodb_log_buffer_size=8M # 如果丢失最近几个事务影响 # 不大的话可以设置 # .._flush_log_at_trx_commit = 0 innodb_flush_log_at_trx_commit=1 set-variable = innodb_lock_wait_timeout=50 #innodb_flush_method=fdatasync #set-variable = innodb_thread_concurrency=5
注意：我们已在不同的硬盘上放置了两个数据文件， InnoDB 将从数据文件的底部填充表空间。在某些情况下所有的数据被分配到不同的物理硬盘中会提高数据库的性能。 将日志文件与数据文件分别放在不同的物理硬盘中对提高性能通常是很有益的。你同样可以使用一个 RAW 磁盘分区( raw disk partitions(raw devices)) 作为数据文件， 在一些 Unixe 系统中这将提高 I/O 能力。 如何在 my.cnf 中详细指定它们请查看第 12.1 节。
警告：在 Linux x86 上必须小心不能将内存使用设置太高， glibc 会把进程堆增长到线程堆栈之上，这将会使服务器崩溃。下面的接近或超过于 2G 将会很危险：
innodb_buffer_pool_size + key_buffer + max_connections * (sort_buffer + record_buffer) + max_connections * 2 MB
每个线程将使用 2MB(MySQL AB 二进制版本为 256 KB)的堆栈，在最坏的环境下还会使用 sort_buffer + record_buffer的附加内存。
如何调整其它的 mysqld 服务器参数？查看 可以得到更详细的信息。适合大多数用户的典型参数如下所示：
skip-locking set-variable = max_connections=200 set-variable = record_buffer=1M set-variable = sort_buffer=1M # 设置索引缓冲(key_buffer)大小为 # 你的 RAM 的 5 - 50% ，这主要依赖于 # 系统中 MyISAM 表使用量。 # 但是必须保证索引缓冲(key_buffer)与 InnoDB # 的缓冲池(buffer pool)大小总和 # 小于 RAM 的 80%。 set-variable = key_buffer=...
注意：在 my.cnf 文件中有些参数是为了设置数字的，它们的设置格式为：set-variable = innodb... = 123，而其它(字符串和逻辑型)的采用另一设置格式：innodb_... = ... .
各设置参数的含义如下：
innodb_data_home_dir | 这是InnoDB表的目录共用设置。如果没有在 my.cnf 进行设置，InnoDB 将使用MySQL的 |
innodb_data_file_path | 单独指定数据文件的路径与大小。数据文件的完整路径由 innodb_data_home_dir 与这里所设定值的组合。 文件大小以 MB 单位指定。因此在文件大小指定后必有“M”。 InnoDB 也支持缩写“G”， 1G = 1024M。从 3.23.44 开始，在那些支持大文件的操作系统上可以设置数据文件大小大于 4 GB。而在另一些操作系统上数据文件必须小于 2 GB。数据文件大小总和至少要达到 10 MB。在 MySQL-3.23 中这个参数必须在 my.cnf中明确指定。在 MySQL-4.0.2 以及更新版本中则不需如此，系统会默认在 MySQL 的datadir 目录下创建一个 16 MB 自扩充(auto-extending)的数据文件 ibdata1。你同样可以使用一个 原生磁盘分区(RAW raw disk partitions(raw devices)) 作为数据文件， 如何在 my.cnf 中详细指定它们请查看第 12.1 节。 |
innodb_mirrored_log_groups | 为了保护数据而设置的日志文件组的拷贝数目，默认设置为 1。在 my.cnf 中以数字格式设置。 |
innodb_log_group_home_dir | InnoDB 日志文件的路径。必须与 innodb_log_arch_dir 设置相同值。 如果没有明确指定将默认在 MySQL 的 datadir 目录下建立两个 5 MB 大小的 ib_logfile... 文件。 |
innodb_log_files_in_group | 日志组中的日志文件数目。InnoDB 以环型方式(circular fashion)写入文件。数值 3 被推荐使用。在 my.cnf 中以数字格式设置。 |
innodb_log_file_size | 日志组中的每个日志文件的大小(单位 MB)。如果 n 是日志组中日志文件的数目，那么理想的数值为 1M 至下面设置的缓冲池(buffer pool)大小的 1/n。较大的值，可以减少刷新缓冲池的次数，从而减少磁盘 I/O。但是大的日志文件意味着在崩溃时需要更长的时间来恢复数据。 日志文件总和必须小于 2 GB，3.23.55 和 4.0.9 以上为小于 4 GB。在my.cnf 中以数字格式设置。 |
innodb_log_buffer_size | InnoDB 将日志写入日志磁盘文件前的缓冲大小。理想值为 1M 至 8M。大的日志缓冲允许事务运行时不需要将日志保存入磁盘而只到事务被提交(commit)。 因此，如果有大的事务处理，设置大的日志缓冲可以减少磁盘I/O。 在 my.cnf 中以数字格式设置。 |
innodb_flush_log_at_trx_commit | 通常设置为 1，意味着在事务提交前日志已被写入磁盘， 事务可以运行更长以及服务崩溃后的修复能力。如果你愿意减弱这个安全，或你运行的是比较小的事务处理，可以将它设置为 0 ，以减少写日志文件的磁盘 I/O。这个选项默认设置为 0。 |
innodb_log_arch_dir | The directory where fully written log files would be archived if we used log archiving. 这里设置的参数必须与 innodb_log_group_home_dir 相同。 从 4.0.6 开始，可以忽略这个参数。 |
innodb_log_archive | 这个值通常设为 0。 既然从备份中恢复(recovery)适合于 MySQL 使用它自己的 log files，因而通常不再需要 archive InnoDB log files。这个选项默认设置为 0。 |
innodb_buffer_pool_size | InnoDB 用来高速缓冲数据和索引内存缓冲大小。 更大的设置可以使访问数据时减少磁盘 I/O。在一个专用的数据库服务器上可以将它设置为物理内存的 80 %。 不要将它设置太大，因为物理内存的使用竞争可能会影响操作系统的页面调用。在 my.cnf 中以数字格式设置。 |
innodb_additional_mem_pool_size | InnoDB 用来存储数据字典(data dictionary)信息和其它内部数据结构(internal data structures)的存储器组合(memory pool)大小。理想的值为 2M，如果有更多的表你就需要在这里重新分配。如果 InnoDB 用尽这个池中的所有内存，它将从操作系统中分配内存，并将错误信息写入 MySQL 的错误日志中。在 my.cnf 中以数字格式设置。 |
innodb_file_io_threads | InnoDB 中的文件 I/O 线程。 通常设置为 4，但是在 Windows 下可以设定一个更大的值以提高磁盘 I/O。在 my.cnf 中以数字格式设置。 |
innodb_lock_wait_timeout | 在回滚(rooled back)之前，InnoDB 事务将等待超时的时间(单位 秒)。InnoDB 会自动检查自身在锁定表与事务回滚时的事务死锁。如果使用 LOCK TABLES 命令，或在同一个事务中使用其它事务安全型表处理器(transaction safe table handlers than InnoDB)，那么可能会发生一个 InnoDB 无法注意到的死锁。在这种情况下超时将用来解决这个问题。这个参数的默认值为 50 秒。在 my.cnf 中以数字格式设置。 |
innodb_flush_method | 这个参数仅仅与 Unix 相关。这个参数默认值为 fdatasync。 另一个设置项为O_DSYNC。这仅仅影响日志文件的转储，在 Unix 下以 fsync 转储数据。InnoDB 版本从 3.23.40b 开始，在 Unix 下指定 fdatasync 为使用 fsync 方式、指定 O_DSYNC 为使用O_SYNC 方式。由于这在某些 Unix 环境下还有些问题所以在 'data' versions 并没有被使用。 |
innodb_force_recovery | 警告：此参数只能在你希望从一个被损坏的数据库中转储(dump)数据的紧急情况下使用！ 可能设置的值范围为 1 - 6。查看下面的章节 'Forcing recovery' 以了解这个参数的具体含义。参数设置大于 0 的值代表着 InnoDB 防止用户修改数据的安全度。从 3.23.44 开始，这个参数可用。在 my.cnf 中以数字格式设置。 |
innodb_fast_shutdown | InnoDB 缺少在关闭之前清空插入缓冲。这个操作可能需要几分钟，在极端的情况下可以需要几个小时。如果这个参数据设置为 1 ，InnoDB 将跳过这个过程而直接关闭。从 3.23.44 和 4.0.1 开始，此参数可用。从 3.23.50 开始，此参数的默认值为 1。 |
innodb_thread_concurrency | InnoDB 会试图将 InnoDB 服务的使用的操作系统进程小于或等于这里所设定的数值。此参数默认值为 8。如果计算机系统性能较低或 innodb_monitor 显示有很多线程等侍信号，应该将这个值设小一点。如果你的计算机系统有很我的处理器与磁盘系统，则可以将这个值设高一点以充分利用你的系统资源。建议设值为处理器数目+ 磁盘数目。 从 3.23.44 和 4.0.1 开始，此参数可用。在 my.cnf 中以数字格式设置。 |
mysql数据库表文件的整理
MySQL数据表类型有：ISAM、MyISAM、MERGE、BDB、InnoDB和HEAP。每种数据表在文件系统中都有不同的表示方式，有一个共同点就是每种数据表至少有一个存放数据表结构定义的.frm文件。
下面介绍每种数据表文件：
ISAM数据表是最原始的数据表，有三个文件，分别是：
frm，存放数据表的结构定义;
ISD，数据文件，存放数据表中的各个数据行的内空;
ISM，索引文件，存放数据表的所有索引信息。
MyISAM数据表是ISAM数据表的继承者，也有三个文件，分别是：
frm，结构定义文件;
MYD，数据文件;
MYI，索引文件。
MERGE数据表是一个逻辑结构，代表一组结构完全相同的MyISAM数据表构成的集合。它在文件系统中有二个文件，分别是：
frm，结构定义文件;
MRG，构成MERGE表的MyISAM数据表清单，每个MyISAM数据表名占一行。也就是说可通过改变该表的内容来改变MERGE数据表的结构。修改前请先刷新缓存(flush tables)，但不建议这样修改MERGE数据表。
BDB数据表用两个文件来表示，分别是：
frm，结构定义文件;
db，数据表数据和索引文件
InnoDB由于采用表空间的概念来管理数据表，所以它只有一个与数据表对应.frm文件，同一目录下的其它文件表示为表空间，存储数据表的数据和索引。
HEAP数据表是一个存在于内存中的表，所以它的数据和索引都存在于内存中，文件系统中只有一个.frm文件，以定义结构。
了解MySQL数据表在文件系统中表现形式后，我们可知道，创建、修改或删除数据表，其实就是对这些文件进行操作。例如一些数据表(除InnoDB和HEAP数据表外)，我们可直接在文件系统中删除相应的文件来删除数据表。
% cd datadir
% rm -f mydb/mydb.*
以上命令可删除mydb数据库中的mydb数据表。
我们知道，MySQL数据库的每一个数据库对应一个子目录，每个子目录中包含了对应于这个数据库中的数据表的文件。每一个数据表对应三个文件，它们和表名相同，但是具有不同的扩展名。tblName.frm文件是表的定义，它保存了表中包含的数据列的内容和类型。tblName.MYD文件包含了表中的数据。tblName.MYI文件包含了表的索引(例如，它可能包含lookup表以帮助提高对表的主键列的查询)。
要检查一个表的错误，只需要运行myisamchk(在MySQL的bin目录下)并提供文件的位置和表名，或者是表的索引文件名：
% myisamchk /usr/local/mysql/var/dbName/tblName % myisamchk /usr/local/mysql/var/dbName/tblName.MYI
上面的两个命令都可以执行对指定表的检查。要检查数据库中所有的表，可以使用通配符：
% myisamchk /usr/local/mysql/var/dbName*.MYI
如果不带任何选项，myisamchk将对表文件执行普通的检查。如果你对一个表有怀疑，但是普通的检查不能发现任何错误，你可以执行更彻底的检查(但是也更慢！)，这需要使用--extend-check选项：
% myisamchk --extend-check /path/to/tblName
对错误的检查是没有破坏性的，这意味着你不必担心执行对你的数据文件的检查会使已经存在的问题变得更糟。另一方面，修复选项，虽然通常也是安全的，但是它对你的数据文件的更改是无法撤消的。因为这个原因，我们强烈推荐你试图修复一个被破坏的表文件时首先做个备份，并确保在制作这个备份之前你的MySQL服务是关闭的。
在windows 2003下通过命令提示符，输入：
注：此为记录我当时操作的全部过程
D:\Documents and Settings\Administrator>c: C:\>cd mysql C:\mysql>cd data C:\mysql\data>cd hw_enterprice C:\mysql\data\hw_enterprice>myisamchk function_products.frm
'myisamchk' 不是内部或外部命令，也不是可运行的程序或批处理文件。
C:\mysql\data\hw_enterprice>cd\ C:\>cd mysql C:\mysql>cd bin
注：查看myisamchk的帮助信息
C:\mysql\bin>myisamchk myisamchk Ver 2.6 for Win95/Win98 at i32 By Monty, for your professional use This software comes with NO WARRANTY: see the PUBLIC for details. Description, check and repair of ISAM tables. Used without options all tables on the command will be checked for errors Usage: myisamchk [OPTIONS] tables[.MYI] Global options: -#, --debug=... Output debug log. Often this is 'd:t:o,filename' -?, --help Display this help and exit. -O, --set-variable var=option Change the value of a variable. Please note that this option is deprecated; you can set variables directly with '--variable-name=value'. -t, --tmpdir=path Path for temporary files -s, --silent Only print errors. One can use two -s to make myisamchk very silent -v, --verbose Print more information. This can be used with --description and --check. Use many -v for more verbosity! -V, --version Print version and exit. -w, --wait Wait if table is locked. Check options (check is the default action for myisamchk): -c, --check Check table for errors -e, --extend-check Check the table VERY throughly. Only use this in extreme cases as myisamchk should normally be able to find out if the table is ok even without this switch -F, --fast Check only tables that haven't been closed properly -C, --check-only-changed Check only tables that have changed since last check -f, --force Restart with '-r' if there are any errors in the table. States will be updated as with '--update-state' -i, --information Print statistics information about table that is checked -m, --medium-check Faster than extend-check, but only finds 99.99% of all errors. Should be good enough for most cases -U --update-state Mark tables as crashed if you find any errors -T, --read-only Don't mark table as checked Repair options (When using '-r' or '-o') -B, --backup Make a backup of the .MYD file as 'filename-time.BAK' --correct-checksum Correct checksum information for table. -D, --data-file-length=# Max length of data file (when recreating data file when it's full) -e, --extend-check Try to recover every possible row from the data file Normally this will also find a lot of garbage rows; Don't use this option if you are not totally desperate. -f, --force Overwrite old temporary files. -k, --keys-used=# Tell MyISAM to update only some specific keys. # is a bit mask of which keys to use. This can be used to get faster inserts! -r, --recover Can fix almost anything except unique keys that aren't unique. -n, --sort-recover Forces recovering with sorting even if the temporary file would be very big. -p, --parallel-recover Uses the same technique as '-r' and '-n', but creates all the keys in parallel, in different threads. THIS IS ALPHA CODE. USE AT YOUR OWN RISK! -o, --safe-recover Uses old recovery method; Slower than '-r' but can handle a couple of cases where '-r' reports that it can't fix the data file. --character-sets-dir=... Directory where character sets are --set-character-set=name Change the character set used by the index -q, --quick Faster repair by not modifying the data file. One can give a second '-q' to force myisamchk to modify the original datafile in case of duplicate keys -u, --unpack Unpack file packed with myisampack. Other actions: -a, --analyze Analyze distribution of keys. Will make some joins in MySQL faster. You can check the calculated distribution by using '--description --verbose table_name'. -d, --description Prints some information about table. -A, --set-auto-increment[=value] Force auto_increment to start at this or higher value If no value is given, then sets the next auto_increment value to the highest used value for the auto key + 1. -S, --sort-index Sort index blocks. This speeds up 'read-next' in applications -R, --sort-records=# Sort records according to an index. This makes your data much more localized and may speed up things C:\mysql\bin>myisamchk c:\mysql\data\hw_enterprice\function_products.frm myisamchk: error: 'c:\mysql\data\hw_enterprice\function_products.frm' is not a M yISAM-table C:\mysql\bin>myisamchk c:\mysql\data\hw_enterprice\function_products.myi Checking MyISAM file: c:\mysql\data\hw_enterprice\function_products.myi Data records: 85207 Deleted blocks: 39 myisamchk: warning: Table is marked as crashed myisamchk: warning: 1 clients is using or hasn't closed the table properly - check file-size - check key delete-chain - check record delete-chain myisamchk: error: record delete-link-chain corrupted - check index reference - check data record references index: 1 - check data record references index: 2 - check data record references index: 3 - check record links myisamchk: error: Wrong bytesec: 0-195-171 at linkstart: 841908 MyISAM-table 'c:\mysql\data\hw_enterprice\function_products.myi' is corrupted Fix it using switch "-r" or "-o"
继续进行操作：
C:\mysql\bin>myisamchk --recover --quick c:\mysql\data\hw_enterprice\function_p roducts.myi - check key delete-chain - check record delete-chain myisamchk: error: record delete-link-chain corrupted myisamchk: error: Quick-recover aborted; Run recovery without switch 'q' Updating MyISAM file: c:\mysql\data\hw_enterprice\function_products.myi MyISAM-table 'c:\mysql\data\hw_enterprice\function_products.myi' is not fixed be cause of errors Try fixing it by using the --safe-recover (-o) or the --force (-f) option
系统提示我使用--safe-recover (-o) or the --force (-f) option进行修复操作，于是
C:\mysql\bin>myisamchk --safe-recover c:\mysql\data\hw_enterprice\function_prod ucts.myi - recovering (with keycache) MyISAM-table 'c:\mysql\data\hw_enterprice\function_ products.myi' Data records: 85207 Wrong bytesec: 0-195-171 at 841908; Skipped Data records: 85215
将修复后的物理文件复制到mysql\data下之后，通过phpMyAdmin进行访问，OK正常！
本次数据修复操作成功，数据已被正常恢复，总计85215条记录，其中恢复数据共计85207条。
总结本次经验及查找资料，如下：
当你试图修复一个被破坏的表的问题时，有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立，删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。
这三种修复方法如下所示：
% myisamchk --recover --quick /path/to/tblName % myisamchk --recover /path/to/tblName % myisamchk --safe-recover /path/to/tblName
第一种是最快的，用来修复最普通的问题；而最后一种是最慢的，用来修复一些其它方法所不能修复的问题。
检查和修复MySQL数据文件
如果上面的方法无法修复一个被损坏的表，在你放弃之前，你还可以试试下面这两个技巧：
如果你怀疑表的索引文件(*.MYI)发生了不可修复的错误，甚至是丢失了这个文件，你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上，使用下面的命令删除表的内容：mysql> DELETE FROM tblName;
在删除表的内容的同时，会建立一个新的索引文件。退出登录并重新关闭服务，然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。最后，使用myisamchk执行标准的修复(上面的第二种方法)，根据表的数据的内容和表的格式文件重新生成索引数据。
如果你的表的格式文件(tblName.frm)丢失了或者是发生了不可修复的错误，但是你清楚如何使用相应的CREATE TABLE语句来重新生成这张表，你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题，使用上面的方法重建一个新的)一起使用。首先制作一个数据和索引文件的拷贝，然后删除原来的文件(删除数据目录下有关这个表的所有记录)。
启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了，但是最好你还是执行一下标准的修复(上面的第二种方法)。
关于MySQL数据库.frm .MYD .MYI损坏的修复方法就介绍到这里了，希望本次的介绍能够给您带来一些收获！
转载地址：http://gdhvi.baihongyu.com/