数据⽬录的位置
MySQL数据⽬录的默认位置已经被编译到MySQL服务器程序⾥了。 在启动服务器时，通过使⽤⼀个--datadir=dir_name选项可以明确指定数据⽬录位置。把MySQL数据⽬录安排到其他地⽅的另⼀种办法是把它列在MySQL服务器在启动时会读取的某个选项⽂件⾥。这样，就不必在每次启动MySQL服务器时都在命令⾏上写出其数据⽬录的路径了。
如果你运⾏多个服务器，你应该知道它们各⾃的数据⽬录在什么地⽅，但是如果你不知道确切的位置，可以⽤下⾯⼏种⽅法把它查出来：
1. mysqladmin -uroot -p123456 -P3306 -h127.0.0.1 variables | grep datadir
2. show variables like 'datadir';
3. ps axww | grep datadir
4. 查看服务器在启动时所读取的选项⽂件，通常可以在[mysqld]选项组⾥看到⼀个下⾯这样的datadir⾏：datadir=/path/to/data/directory
5. 使⽤find命令搜索数据库⽂件的办法来查明MySQL服务器的数据⽬录位置。寻.frm（数据库定义）⽂件：find / -name "*.frm" -print 数据⽬录的结构 MySQL数据⽬录收录着MySQL服务器所管理的全部数据库和数据表，这些⽂件被组织成⼀个树状结构，通过利⽤Unix或Windows⽂件系统的层次结构直接实现，即： （1）每个数据库对应于数据⽬录下的⼀个⽬录。
（2）同⼀个数据库⾥的数据表对应于数据库⽬录中的各有关⽂件。
这种以⽬录和⽂件来实现数据库和数据表的层次化的做法有⼀个例外，即InnoDB数据表处理程序把所有数据库⾥的所有InnoDB数据表全部存放在同⼀个公共表空间⾥。这个表空间是⽤⼀个或者多个⾮常⼤的⽂件⽽实现的，这些⽂件将被视为⼀个连接统⼀的数据结构，各InnoDB数据表的数据和索引都将存放在这个连接统⼀的数据结构中。在默认情况下，InnoDB表空间⽂件也都存放在MySQL数据⽬录⾥。MySQL数据⽬录还可能包含有其他⼀些⽂件，例如：
（1）MySQL服务器的选项⽂件f。
（2）MySQL服务器的进程ID（PID）⽂件。
（3）MySQL服务器所⽣成的状态和⽇志⽂件。
（4）把DES密钥⽂件或服务器的SSL证书与密钥⽂件存放在MySQL数据⽬录也是常见的做法。
MySQL数据库在⽂件系统⾥如何表⽰
MySQL服务器所管理的每⼀个数据库都有它⾃⼰的数据库⽬录，这个数据库⽬录其实是MySQL数据⽬录中的⼀个⼦⽬录，这个⼦⽬录的名字与它代表的数据库名字相同。例如，对应于数据库mydb的数据库⽬录就是DATADIR/my_db。这种表⽰⽅法使MySQL数据库系统中⼀些与数据库有关的语句实现起来相当简单。
例如，CREATE DATABASE db_name命令将在MySQL数据⽬录⾥创建⼀个名为db_name的空⽬录。在UNIX系统上，新创建的⽬录的属主就是启动MySQL服务器时使⽤的登录账户，并且只能通过该登录账户去访问它。换⽽⾔之，CREATE DATABASE命令相当于在使⽤那个账户登录到MySQL服务器主机上之后执⾏下列shell命令：
cd DATADIR
mkdir db_name
chmod u=rwx, go-rwx db_name
⽤⼀个空⽬录来代表⼀个新数据库可以说是最简单的做法了。在其他的数据库系统⾥，即使是创建⼀个“空的”数据库也需要创建好⼏个控制⽂件或系统⽂件。
DROP DATABASE语句实现同样简单。DROP DATABASE db_name删除数据库中的db_name⽬录和所有表⽂件，这⼏乎与下列命令⼀样：
cd DATADIR
rm-rf DATADIR/db_name
DROP DATABASE语句与shell命令之间的区别如下：
1. 如果使⽤的是DROP DATABASE命令，MySQL服务器仅通过查看有关⽂件的扩展名删除那些与数据表有关的⽂件。如果还在数据库
⽬录⾥创建过其他⽂件，MySQL服务器将保留这些⽂件，⽽且⽬录本⾝也不会被删除。
2. InnoDB数据表及其索引的内容都存放在InnoDB表空间⾥，⽽不是被存放为MySQL数据⽬录中的⽂件。如果某个数据库⾥包含着
InnoDB数据表，就必须使⽤DROP DATABASE语句才能让InnoDB处理程序从InnoDB表空间⾥把该数据表删掉，⽤rm或del命令删除数据库⽬录的⽅法对InnoDB数据表是⽆效的。
MySQL数据表在⽂件系统⾥如何表⽰
MySQL⽀持以下⼏种针对不同数据表类型的处理程序：ISAM、MyISAM、MERGE、BOB、InnoDB和HEAP。MySQL中的每⼀个数据表在磁盘上⾄少被表⽰为⼀个⽂件，即存放着该数据表的结构定义的.frm⽂件；⼤部分数据表类型还有其他⼏个⽤来存放数据⾏和索引信息的⽂件。这些⽂件会随着数据表类型的不同⽽变化。
ISAM数据表
MySQL中最原始的数据表类型就是ISAM类型。在MySQL⾥，每个ISAM数据表⽤包含着该数据表的数据库⽬录⾥的三个⽂件来代表。这些⽂件的基本名与数据表的名字相同，扩展名则分别表明了有关⽂件的具体⽤途。例如：名为mytb1的ISAM数据表将被表⽰为以下三个⽂件：
mytb1.frm——定义⽂件，存放着该数据表的格式（结果）定义。
mytb.ISD——ISAM数据⽂件，存放着该数据表中的各个数据⾏的内容。
mytb.ISM——ISAM索引⽂件，存放着该数据表的全部索引信息。
MyISAM数据表
MySQL3. 23版本引⼊了MyISAM数据表类型作为ISAM类型的后继者，MyISAM数据表类型也要使⽤三个⽂件来代表⼀个数据表，这三个⽂件的扩展名分别是.frm（结构定义⽂件）、.MYD（数据⽂件）和.MYI（索引⽂件）。
MERGE数据表
.MERGE数据表其实是⼀个逻辑结构。它代表着由⼀组结构完全相同的MyISAM数据表所构成的集合；有关的查询命令将把它当作⼀个⼤数据表来对待。在数据库⽬录⾥，每⼀个MERGE数据表将被表⽰为⼀个.frm⽂件和⼀个.MRG⽂件，.MRG⽂件其实就是⼀份由各MyISAM数据表的名单构成的MERGE数据表。
BDB数据表
BDB处理程序⽤两个⽂件来代表每个数据表，其⼀是⽤来存放数据表结构定义的.frm⽂件，其⼆是⽤来存放数据表的数据和索引信息的.db⽂件。
InnoDB数据表
上述⼏种数据表类型都是⽤多个⽂件来表⽰⼀个数据表的。InnoDB数据表与它们有所不同。与⼀个给定InnoDB数据表直接对应的⽂件只有⼀个，即数据表的.frm结构定义⽂件，这个⽂件存放在包含着数据表的数据库⽬录⾥。所有InnoDB数据表的数据和索引都被存放到同⼀个专⽤的表空间⾥统⼀管理。⼀般来说，这个表空间本⾝将被表⽰为MySQL数据⽬录⾥的⼀个或者多个⼤⽂件。构成表空间的这些⽂件将形成⼀个在逻辑上连续不断的存储区域，表空间的总长度等于各组成⽂件的长度之和。
HEAP数据表
HEAP数据表是创建在内存中的数据表。因为MySQL服务器把HEAP数据表的数据和索引都存放在内存⾥⽽不是存放在硬盘上，所以除相应的.frm⽂件外，HEAP数据表在⽂件系统⾥根本没有相应的代表⽂件。
SQL语句如何映射为数据表⽂件操作
每⼀种数据表类型都要使⽤⼀个.frm⽂件来保存数据表的结构定义，所以，应⽤show table my_name命令所得到的输出结果，与列出数据库⽬录db_name中所有.frm⽂件基本名所得到的结果是相同的。有些数据库系统使⽤⼀个注册表来记录某数据库⾥的所有数据表，但MySQL没有这样做，因为，系统不需要这样设置，MySQL数据⽬录的层次结构已经把“注册表”隐藏在其中了。
创建数据表
要想创建⼀个MySQL所⽀持的任意类型的数据表，需要发出⼀条CREATE TABLE语句定义数据表的结构。⽆论哪⼀种数据表类
型，MySQL服务器都将创建⼀个.frm⽂件来保存数据表的结构定义的内部编码。MySQL服务器还会根据指定数据表的具体类型创建出其他必要的⽂件。例如，它将为⼀个MyISAM数据表创建出⼀个.MYD数据⽂件和⼀个.MYI索引⽂件；为⼀个BDB数据表创建出⼀个.db数据/索引⽂件。对于InnoDB数据表，InnoDB处理程序将在InnoDB表空间⾥为数据表初始化⼀些数据和索引信息。在UNIX系统上为新数据表⽽创建的各个⽂件的属主和存在模式将被设置为只允许⽤来运⾏MySQL服务器的账户进⾏访问。
更新数据表
当发出⼀条ALTER TABLE tbl_name语句时，MySQL服务器将对有关数据表的.frm⽂件重新进⾏编码以反映出这条语句所表明的结构性变化，还要对有关的数据⽂件和索引⽂件的内容进⾏相应的修改。CREATE INDEX和DROP INDEX也是⼀样能引起类似的动作，因为MySQL 服务器在内部是把它们当作等效的ALTER TABLE语句来处理的。改变InnoDB数据表的结构会引起InnoDB处理程序修改InnoDB表空间中数据表的数据，同时也对索引做出相应的修改。
删除数据表
DROP TABLE语句是通过删除代表该数据表的各种有关⽂件⽽实现的。丢弃⼀个InnoDB数据表将是数据表在InnoDB表空间⾥占⽤的空间被标注为“未使⽤”。
对于某些数据表类型，可以通过在相应的数据库⽬录⾥删除与数据表有关的各个⽂件的办法来⼿动删除这个数据表，例如，假设mydb是当前数据库，mytb1是⼀个ISAM、MyISAM、BOB或MERGE数据表，那么drop table mytb1语句就⼤致等效于下⾯这两条UNIX命令：
cd DATADIR
rm -f mydb/mytb1.*
对于InnoDB或HEAP数据表，因为它们的某些组成部分在⽂件系统⾥没有实体性的⽂件来代表，所以针对这两种数据表类型的DROP TABLE语句没有等效的⽂件系统级命令。例如，InnoDB数据表在⽂件系统⾥只有⼀个相应的.frm⽂件，⽤⽂件系统级命令删除这个⽂件将使该数据表在InnoDB表空间数据和索引成为“流离失所的孤⼉”。
操作系统对数据库和数据表命名的限制
MySQL对数据库和数据表的命名有其⾃⼰的⼀套命名规则，下⾯是命名中的⼏个要点：
（1）名字可以由当前字符集中的字母和数字字符以及下划线（_）和美元符号（＄）构成。
（2）名字的最⼤长度是64个字符。
从MySQL3.23.6版本开始，其他字符也可以出现在名字⾥，但它们必须⽤反引号引起来。如果想把保留字⽤做数据列的名字，那最好⽤反引号把它们引起来。可是，因为数据库和数据表的名字将被MySQL⽤做相应的⽬录和⽂件的基本⽂件名，所以数据库和数据表的名字往往还要遵守MySQL服务器在其运⾏的操作系统中的⽂件系统命名规则的限制，譬如（$在linux是特殊字符，⼤⼩写敏感）。
数据⽬录的结构对系统性能的影响
MySQL数据⽬录的结构很容易理解，因为它以⼀种相当⾃然的⽅式使⽤⽂件系统的层次结构。但这种结构对性能也有着隐含的影响。因为每打开⼀个数据表都需要打开⼀个或者多个与该数据表相关联的⽂件，所以这种层次结构对性能往往会产⽣很⼤的影响。
MySQL数据⽬录的结构繁多，这将导致数据表处理程序需要使⽤多个⽂件来代表⼀个数据表，⽽打开⼀个数据表需要⽤到多个⽽不是⼀个⽂件描述符。MySQL服务器智能化地将⽂件描述符缓存起来，但⼀个繁忙的MySQL服务器仍有可能因为需要同时向多个客户连接提供服务器，或者执⾏⼀些涉及多个数据表的复杂查询⽽耗尽⽂件描述符，这很可能会是⼀个问题。因为⽂件描述符在许多系统，尤其是那些把每个进程所能使⽤的⽂件描述符个数（即允许每个进程打开的⽂件个数）设置得相当低的系统上都是⼀种稀缺的资源。
⽤多个⽂件来代表⼀个数据表的做法还会导致数据表打开操作的时间随查询命令所涉及的数据表个数的增加⽽延长。因为MySQL⾥的数据表打开操作将被映射为操作系统中的⽆连接打开操作，所以系统⽬录搜索例程的执⾏效率就会影响到数据表打开操作的执⾏效率。这⼀般算不上是个问题，但如果数据库⾥有很多个数据表的话，这个因素就很值得考虑了。例如，我们知道，每个MyISAM数据表都将被表⽰为3个⽂件。假如数据库⾥有10000个MyISAM数据表，则数据库⽬录就将有30000个⽂件，⽤户就肯定会注意到⽂件打开操作明显地慢了下来。（Linux ext2和Solaris⽂件系统会遇到这个问题）。如果系统性能因此⽽下降到⾜以引起关注的程度，就应该考虑换⽤⼀种能够⾼效率地处理⼤量⽂件的⽂件系统。例如，ReiserFS⽂件系统就是⼀种在存在⼤量⼩⽂件的情况下，依然有着良好性能的⽂件系统。如果系统⽆法换⽤另⼀种⽂件系统，就应该根据应⽤软件的具体情况重新考虑那些数据表的结构，对数据表的结构做出必要的优化调整。例如，如果应⽤软件要为每个⽤户分别创建⼀个数据表，数据库⾥就会有很多结构完全相同的数据表。要想把这些数据表合并为⼀个数据表，可能需要增加⼀个数据列以表明各有关数据⾏都对应于哪⼀位⽤户。如果能⼤⼤减少数据表的数量，应⽤软件的性能就会有明显的改善。
⽤尽可能少的⽂件创建出多个数据表的办法是使⽤InnoDB数据表。每个InnoDB数据表只有⼀个与之相关联的.frm⽂件，所有InnoDB数据表的数据和索引信息都将存放在InnoDB表空间⾥。这就⼤⼤减少了⽤来表⽰InnoDB数据表的磁盘⽂件的数量，进⽽减少了打开⼀个数据表时需要⽤到的⽂件描述符的
个数。当⽤到InnoDB数据表的时候，InnoDB处理程序会先打开构成InnoDB表空间的各个组成⽂件（InnoDB表空间由⼏个组成⽂件构成，就要⽤到⼏个⽂件描述符；但这个数字在服务器运转期间将是⼀个常数）；然后，每打开⼀个InnoDB数据
表，InnoDB处理程序就要⽤⼀个⽂件描述符去打开该表的.frm⽂件，每关闭⼀个InnoDB数据表，与该数据表相关联的⽂件描述符就会被释放。
MySQL状态⽂件和⽇志⽂件
除数据库⽬录外，MySQL数据⽬录⾥还包含许多状态⽂件和⽇志⽂件，这些⽂件默认存放位置是相应的MySQL服务器的数据⽬录，其默认⽂件名是在服务器主机名上增加⼀些后缀⽽得到的。
1.进程ID⽂件
MySQL服务器会在启动时把⾃⼰的进程ID写⼊PID⽂件，等运⾏结束时⼜会删除该⽂件。PID⽂件是允许服务器本⾝被其他进程到的⼯具。例如，如果运⾏mysql.server，在系统关闭时，关闭MySQL服务器的脚本检查PID⽂件以决定它需要向哪个进程发出⼀个终⽌信号。
2.MySQL⽇志⽂件
MySQL能够维护多个不同的⽇志⽂件。⼤多数⽇志功能都是可选的；不仅可以在启动MySQL服务器时利⽤各种启动选项来激活⽇志（对不常⽤的⽇志可以不启⽤），还可以指定⽇志⽂件的名字。
（1）常规⽇志记录服务器操作的综合性信息；哪些⼈正从哪些地⽅试图连接MySQL服务器、他们发出哪些查询命令等。
（2）变更⽇志记录查询命令信息，但它只记录那些对数据库内容做出可修改的查询命令。变更⽇志的内容是⼀些SQL语句，可以把这些语句提供给mysql客户程序作为输⼊以执⾏。
（3）⼆进制变更⽇志与变更⽇志作⽤相同，但其内容是⽤效率更⾼的⼆进制格式写出来的。附属的⼆进制⽇志索引⽂件列出了MySQL服务器当前正在维护着哪些⼆进制⽇志⽂件。
变更⽇志和⼆进制变更⽇志主要⽤于MySQL数据库系统的崩溃恢复⼯作中。在发⽣系统崩溃后，先⽤备份⽂件把数据库恢复到当初进⾏备份时的状态，再把变更⽇志或⼆进制变更⽇志的内容写⼊MySQL服务器，让它再次执⾏⽇志中记载的各种修改操作，把数据库恢复到崩溃发⽣时所处的状态。
例如：下⾯的⽇志记录了在test数据库中创建⼀个my_tabl表，插⼊⼀⾏数据，然后删除表的会话：
990509 7：37：09 492 Connect Paul@localhost on test
492 Query CREATE TABLE my_tbl（val INT）
492 Query INSERT INTO my_tbl values（1）
492 Query DROP TABLE my_tbl
492 Quit
常规⽇志中的信息由以下⼏项内容组成：⽇期/时间、服务器线程（连接）ID、事情的类型、事情的具
体信息。如果后⼀事件与前⼀事件的发⽣⽇期/时间相同，则后⼀事件在常规⽇志中的记录项将省略⽇期/时间字段。
同⼀个会话出现在更新⽇志中看上去如下所⽰：
use test；
CREATE TABLE my_tbl（val int）；
INSERT INTO my_tbl VALUES（1）；
DROP TABLE my_tbl；
（4）对更新⽇志，⽤--log-long-format选项获得⼀个扩展形式的⽇志，扩展⽇志提供有关谁何时发出每⼀条查询，这使⽤更多的磁盘空间，但如果你想知道谁在做什么，⽽不⽤将更新⽇志对照⼀般⽇志的内容到连接事件。对上⾯的会话，扩展更新⽇志产⽣这样的信息：
#Time：990507 7：32：42
#User@Host：paul[paul]@localhost[]
use test；
CREATE TABLE my_tbl（val int）；
#User@Host：paul[paul]@localhost[]
INSERT INTO my_tbl VALUES（1）；
#Time：990507 7：32：43
#User@Host：paul[paul]@localhost[]
DROP TABLE my_tbl；
ps：新增加的记载内容都写在了以“#”字符开头的⾏上。这样，当把变更⽇志馈⼊mysql客户程序以传递给MySQL服务器去执⾏时，它们将被解释为注释。
（5）错误⽇志记载着MySQL服务器在发⽣异常情况时⽣成的诊断信息。如果MySQL服务器启动失败或意外退出，通常可以从这个⽇志⾥了解到其原因。
⽇志⽂件的尺⼨有可能变得⾮常⼤，⼀定要保证它们不⾄于填满⽂件系统。可以定期使⼀些⽇志⽂件
失效以保证它们使⽤的空间总量不会超过⼀定的界限。
因为⽇志⽂件中记载的查询命令⾥可能会有⼝令之类的敏感信息，所以应该注意加强⽇志⽂件的安全保护⼯作，避免它们遭受意外破坏或者被⽆关⽤户读取。例如，下列⽇志项⾥就⽤root⽤户的⼝令，这⼀定不是想让任何⼈看到的信息：
990509 7：23：31 4 Query UPDATE user SET
Password=PASSWORD（"secret"）
WHERE user="root"
在默认的情况下，⽇志将被写到MySQL数据⽬录⾥，所以加强⽇志⽂件的安全保护⼯作的主要措施之⼀就是不让MySQL管理员的登录账户进⼊并看到MySQL数据⽬录⾥的内容。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议