MySQL数据目录结构

从概念上讲 大多数关系数据库系统是相似的 它们有一系列数据库组成 每个数据库包含一系列数据库表 但每个系统有各自组织其管理的数据方式 MySQL也不例外 缺省地 所有由MySQL服务器mysqld管理的数据存储在一个称为MySQL数据目录的地方 所有数据库都存放在哪儿 也包括提供服务器 *** 作信息的状态文件 如果你对一个MySQl安装执行管理任务 你应该熟知数据目录的布局及用途 本文介绍下列专题 如何确定数据目录的位置 服务器如何组织并提供对数据库和它管理的表的访问 在哪里找到由服务器生成的状态文件记忆它们包含什么内容 如何改变缺省地点或数据目录或单独数据库的组织结构 数据目录的位置 一个缺省数据目录被编译进了服务器 如果你从一个源代码分发安装MySQL 典型的缺省目录为/usr/local/var 如果从RPM文件安装则为/var/lib/mysql 如果从一个二进制分发安装则是/usr/local/mysql/data 在你启动服务器 通过使用一个 datadir=/path/to/dir选项可以明确指定数据目录位置 如果你想把数据目录置于其它缺省位置外的某处 这很有用 作为一名MySQL管理员 你应该知道你的数据目录在哪里 如果你运行多个服务器 你应该是到所有数据目录在哪里 但是如果你不知道确切的位置 由多种方法找到它 使用mysqladmin variables从你的服务器直接获得数据目录路径名 查找datadir变量的值 在Unix上 其输出类似于 %mysqladmin variables+ + +| variable_name | Value |+ + +| back_log | || connect_timeout | || basedir | /var/local/ || datadir | /usr/local/var/ | 在Windows上 输出可能看上去像这样 c:mysqladmin variables+ + +| variable_name | Value |+ + +| back_log | || connect_timeout | || basedir | c:mysql || datadir | c:mysqldata | 如果你有多个服务器在运行 它们将在不同的TCP/IP端口或套接字上监听 通过提供连接服务器正在监听的端口或套接字的 port或 socket选项 你可以轮流获得它们每一个的数据目录信息 %msqladmin port=port_name variables%mysqladmin socket=/path/to/socket variablesmysqladmin命令可运行在任何你能从其连接服务器的主机上 如果你想在一个远程主机连接服务器 使用一个 host=host_name选项 %mysqladmin host=host_name variables在Windows上 你可以通过使用 pipe强制一个命令管道连接和 socket=pipe_name指定管道名来连接监听一个命令管道的NT服务器 c:mysqladmin pipe socket=pipe_name variables你可以使用ps命令查看任何正在运行mysqld 进程的命令行 试一下下列命令之一并寻找 datadir %ps axww | grep mysql BSD风格%ps ef | grep mysqld System V风格如果你的系统运行多个服务器 ps命令可能特别有用 因为你能马上发现多个数据目录位置 缺点是必须在服务器上运行 而且可能没有有用的信息产生 除非在mysqld命令行上明确指定了 datadir选项 如果MySQL是从一个源代码分发安装的 你可以检查其配置信息确定数据目录位置 例如 位置可从顶级Makefile中获得 但是注意 位置是Makefile中的localstatedir值 不是datadir 而且 如果分发位于一个NFS挂载的文件系统并用来为多个主机构建MySQL 配置信息反映了分发被最新构建的主机 这可能不能提供你感兴趣的主机的数据目录信息 如果上述方式失败 你可以用find寻找数据库文件 下列命令寻找 frm 文件 它是任何MySQL安装的一部分 % find / name frm print在下文各例中 用DATADIR表示MySQL数据目录位置 数据目录结构 MySQL数据目录包含了服务器管理的所有数据目录 这些文件被组织成一个树状结构 通过利用Unix或Windows文件系统的层次结构直接实现 每个数据库对应于数据目录下的一个目录 在一个数据库中的表对应于数据目录下的文件 数据目录也包含由服务器产生的几个状态文件 如日志文件 这些文件提供了关于服务器 *** 作的重要信息 对管理特别在出了问题而试图确定问题原因时很有价值 例如 如果某个特定查询杀死服务器 你可以通过检查日志文件判别捣乱的查询 MySQL服务器怎样提供对数据的访问 在数据目录下的一切由一个单独的实体 MySQL服务器mysqld管理 客户程序绝不直接 *** 作数据 相反 服务器提供数据可访问的切入点 它是客户程序与它们想使用的数据之间的中介 当服务器启动时 如果有需要 它打开日志文件 然后通过监听网络连接位数据目录呈现一个网络接口 要访问数据 客户程序建立对服务器的一个连接 然后以MySQL查询传输请求来执行希望的 *** 作 服务器执行每一个 *** 作并将结果发回用户 服务器是多线程的并能服务多个同时的客户连接 然而 因为修改 *** 作一个执行一个 实际效果是顺序化请求 以使两个客户决不能在同一时刻改变同一记录 在正常的情况下 让服务器作为数据库访问的唯一仲裁者提供了避免可从同时访问数据库表的多个进程的破坏的保证 管理员应该知道有时服务器没有对数据目录的独裁控制 当你在一个单个数据目录上运行多个服务器 一般倪云新一个服务器管理主机上的所有数据库 但是有可能运行多个服务器 如果这完成提供对多个独立数据目录的访问 没有相互影响的问题 但哟也能启动多个服务器并指向同一个目录 一般地 这不是一个好主意 如果你试图这样 最好是你的系统提供良好的文件锁定功能 否则服务器将不能正确协作 如果你将多个服务器同时写入日志文件 你也冒着你的日志文件称为混乱的根源的风险 在你运行isamc和myisamc时 isamc和myisamc实用程序用于表的维护 诊错和修复 就想你想的那样 因为这些程序可以修改表内容 允许它们与服务器正在 *** 作的同时对表 *** 作 这样能导致表损坏 理解如何限制这种相互影响是很重要的 这样你不会损坏你的表 数据目表示 每个MySQL服务器管理的数据库有自己的数据库表 它是数据目录下的一个子目录 其名字与它表示的数据库相同 例如数据库my_db对应于数据库目录DATADIR/my_db 这种表示允许多个数据库级的语句在其实现中十分简单 CREATE DATABASE db_name在数据目录中创建一个db_name空目录 具有只允许MySQL服务器用户(运行服务器的Unix用户)的属主和模式 这等价于下列手工在服务器主机上创建数据库 %mkdir DATADIR/db_name%chmod DADADIR/db_name用一个空目录表示一个新数据库的最简单方法与其它数据库甚至为一个空数据库创建大量的控制文件或系统文件正好相反 DROP DATABASE语句实现同样简单 DROP DATABASE db_name删除数据库中的db_name目录和所有表文件 这几乎与下列命令一样 %rm rf DATADIR/db_name(差别是服务器只删除具有已知用于表的后缀名的文件 如果你在数据库目录创建了其它文件 则服务器保留它们 而且目录本身不被删除 SHOW DATABASE基本上不做什么 只是列出位于数据目录中的目录名 有些数据库系统保持一个主表 用于维护所有数据库 但在MySQL无此构件 由于赋予数据目录结构的简洁性 数据库列表隐含在数据目录的内容中 而且这样的表不必有额外的开销 数据库表的表示 每个数据库在数据库目录中有 个文件 一个样式（描述文件） 一个数据文件和一个索引文件 每个文件的基本名是表名 文件名扩展名代表文件类型 扩展名如下表 数据和索引文件的扩展名指出表使用老式IASM索引或新式MyISAM索引 表 MySQL文件类型文件类型 文件名扩展名 文件内容样式文件 frm 描述表的结构（它的列 列类型 索引等） 数据文件 ISD(ISAM)或 MYD(MyISAM) 包含数据文件上的所有索引的索引树 索引文件 ISM(ISAM)或 MYI(MyISAM) 该索引文件依赖表是否有索引而存在 当你发出一条CREATE TABLE tbl_name时语句定义表的结构时 服务器创建一个名为tbl_name frm的文件 它包括该结构的内部编码 同时也创建一个空数据和索引文件 初始化为包含指出无记录和无索引的信息（如果CREATE TABLE语句包括索引指定 索引文件反映出这些索引） 对应于表的文件的属主和模式被设置为只允许MySQL服务器用户访问 当你发出一条ALTER TABLE tbl_name语句时 服务器重新编码tbl_name frm 并修改数据和索引文件的内容以反映语句指定的结构改变 对于CREATE INDEX和DROP INDEX也是一样 因为它们被服务器视为与ALTER TABLE等价 DROP TABLE通过删除对应于表的三个文件来实现 虽然你可以通过删除数据库目录中对应于表的三个文件 但不能手工创建或修改一个表 如 如果my_db是当前数据库 DROP TABLE my_tbl大概等价于下列命令 <b lishixinzhi/Article/program/MySQL/201311/29333

一、数据场景 1、表结构简介 任何工具类的东西都是为了解决某个场景下的问题，比如Redis缓存系统热点数据，ClickHouse解决海量数据的实时分析，MySQL关系型数据库存储结构化数据。数据的存储则需要设计对应的表结构，清楚的表结构，有助于快速开发业务，和理解系统。表结构的设计通常从下面几个方面考虑：业务场景、设计规范、表结构、字段属性、数据管理。

2、用户场景

例如存储用户基础信息数据，通常都会下面几个相关表结构：用户信息表、单点登录表、状态管理表、支付账户表等。

用户信息表

存储用户三要素相关信息：姓名，手机号，身份z，登录密码，邮箱等。

CREATE TABLE `ms_user_center` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户ID', `user_name` varchar(20) NOT NULL COMMENT '用户名', `real_name` varchar(20) DEFAULT NULL COMMENT '真实姓名', `pass_word` varchar(32) NOT NULL COMMENT '密码', `phone` varchar(20) NOT NULL COMMENT '手机号', `email` varchar(32) DEFAULT NULL COMMENT '邮箱', `head_url` varchar(100) DEFAULT NULL COMMENT '用户头像URL', `card_id` varchar(32) DEFAULT NULL COMMENT '身份z号', `user_sex` int(1) DEFAULT '1' COMMENT '用户性别:0-女,1-男', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表'; 单点登录表

用意是在多个业务系统中，用户登录一次就可以访问所有相互信任的业务子系统，是聚合业务平台常用的解决方案。

CREATE TABLE `ms_user_sso` ( `user_id` int(11) NOT NULL COMMENT '用户ID', `sso_id` varchar(32) NOT NULL COMMENT '单点信息编号ID', `sso_code` varchar(32) NOT NULL COMMENT '单点登录码,唯一核心标识', `log_ip` varchar(32) DEFAULT NULL COMMENT '登录IP地址', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户单点登录表'; 状态管理表

系统用户在使用时候可能出现多个状态，例如账户冻结、密码锁定等，把状态聚合到一起，可以更加方便的管理和验证。

CREATE TABLE `ms_user_status` ( `user_id` int(11) NOT NULL COMMENT '用户ID', `account_status` int(1) DEFAULT '1' COMMENT '账户状态：0-冻结,1-未冻结', `real_name_status` int(1) DEFAULT '0' COMMENT '实名认证状态：0-未实名,1-已实名', `pay_pass_status` int(1) DEFAULT '0' COMMENT '支付密码是否设置：0-未设置,1-设置', `wallet_pass_status` int(1) DEFAULT '0' COMMENT '钱包密码是否设置：0-未设置,1-设置', `wallet_status` int(1) DEFAULT '1' COMMENT '钱包是否冻结:0-冻结,1-未冻结', `email_status` int(1) DEFAULT '0' COMMENT '邮箱状态:0-未激活,1-激活', `message_status` int(1) DEFAULT '1' COMMENT '短信提醒开启：0-未开启,1-开启', `letter_status` int(1) DEFAULT '1' COMMENT '站内信提醒开启：0-未开启,1-开启', `emailmsg_status` int(1) DEFAULT '0' COMMENT '邮件提醒开启：0-未开启,1-开启', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户状态表'; 支付账户表

用户交易的核心表，存储用户相关的账户资金信息。

CREATE TABLE `ms_user_wallet` ( `wallet_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '钱包ID', `user_id` int(11) NOT NULL COMMENT '用户ID', `wallet_pwd` varchar(32) DEFAULT NULL COMMENT '钱包密码', `total_account` decimal(20,2) DEFAULT '000' COMMENT '账户总额', `usable_money` decimal(20,2) DEFAULT '000' COMMENT '可用余额', `freeze_money` decimal(20,2) DEFAULT '000' COMMENT '冻结金额', `freeze_time` datetime DEFAULT NULL COMMENT '冻结时间', `thaw_time` datetime DEFAULT NULL COMMENT '解冻时间', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', `state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用', PRIMARY KEY (`wallet_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户钱包'; 二、设计规范 1、涉及模块

通过上面几个表设计的案例，可以看到表设计关联到数据库的各个方面知识：数据类型，索引，编码，存储引擎等。表设计是一个很大的命题，不过也遵循一个基本规范：三范式。

2、三范式 基础概念

一范式

表的列的具有原子性,不可再分解，即列的信息，不能分解,关系型数据库MySQL、Oracle等自动的满足。

二范式

每个事实的数据记录只会出现一次, 不会冗余, 通常设计一个主键来实现。

三范式

要求一个表中不包含已经存在于其它表的非主键信息，例如部门和员工的信息，员工表包含部门表的主键ID，则可以关联获取相关信息，没必要在员工表保存相关信息。

优缺点对比

范式化设计

范式化结构设计通常更新快，因为冗余数据较少，表结构轻巧，也更好的写入内存中。但是查询起来涉及到关联，代价非常高，非常损耗查询性能。

反范式化设计

所有的数据都在一张表中，避免关联查询，索引的有效性更高，但是数据的冗余性极高。

建议结论

上述的两种设计方式在实际开发中都是不存在的，在实际开发中都是混合使用。比如汇总统计，缓存数据，都会基于反范式化的设计。

三、字段属性

合适的字段类型对于高性能来说非常重要，基本原则如下：简单的类型占用资源更少；在可以正确存储数据的情况下，选最小的数据类型。

1、数据类型选择 整数类型

TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，根据数据类型范围合理选择即可。

实数类型

FLOAT、DOUBLE、DECIMAL，建议资金货币相关类型使用高精度DECIMAL存储，或者把数据成倍扩大为整数，采用BIGINT存储，不过处理相对麻烦。

字符类型

CHAR、VARCHAR，长度不确定建议采用VARCHAR存储，不过VARCHAR类型需要额外开销记录字符串长度。CHAR适合存储短字符，或者定长字符串，例如MD5的加密结构。

时间类型

DATETIME、TIMESTAMP，DATETIME保存大范围的值，精度秒。TIMESTAMP以时间戳的格式，范围相对较小，效率也相对较高，所以通常情况建议使用。

MySQL的字段类型有很多种，可以根据数据特性选择合适的，这里只描述常见的几种类型。

2、基础用法 *** 作 数据类型

修改字段类型

ALTER TABLE ms_user_sso MODIFY state CHAR(1) DEFAULT '0' ; ALTER TABLE ms_user_sso MODIFY state INT(1) DEFAULT '1' COMMENT '状态：0不可用,1可用';

修改名称位置

ALTER TABLE ms_user_sso CHANGE log_ip login_ip VARCHAR(32) AFTER update_time ; 索引使用

索引类型：主键索引，普通索引，唯一索引，组合索引，全文索引。这里演示普通索引的 *** 作。MySQL的核心模块，后续详说。

添加索引

ALTER TABLE ms_user_wallet ADD INDEX user_id_index(user_id) ; CREATE INDEX state_index ON ms_user_wallet(state) ;

查看索引

SHOW INDEX FROM ms_user_wallet;

删除索引

DROP INDEX state_index ON ms_user_wallet ;

修改索引

不具有真正意义上的修改，可以把原有的索引删除之后，再次添加索引。

外键关联

用处：外键关联的作用保证多个数据表的数据一致性和完整性，建表时先有主表，后有从表；删除数据表，需要先删从表，再删主表。复杂场景不建议使用，实际开发中用的也不多。

添加外键

ALTER TABLE ms_user_wallet ADD CONSTRAINT user_id_out_key FOREIGN KEY(user_id) REFERENCES ms_user_center(id) ;

删除外键

ALTER TABLE ms_user_wallet DROP FOREIGN KEY user_id_out_key ; 四、表结构管理 1、查看结构 DESC ms_user_status ; SHOW CREATE TABLE ms_user_status ; 2、字段结构 添加字段 ALTER TABLE ms_user_status ADD `delete_time` datetime DEFAULT NULL COMMENT '删除时间' ; 删除字段 ALTER TABLE ms_user_status DROP COLUMN delete_time ; 3、修改表名 ALTER TABLE ms_user_center RENAME ms_user_info ; 4、存储引擎 存储引擎 SELECT VERSION() ; SHOW ENGINES ;

MySQL 56 支持的存储引擎有InnoDB、MyISAM、Memory、Archive、CSV、BLACKHOLE等。一般默认使用InnoDB，支持事务管理。该模块MySQL核心，后续详解。

修改引擎

数据量大的场景下，存储引擎修改是一个难度极大的 *** 作，容易会导致表的特性变动，引起各种后续反应，后续会详说。

ALTER TABLE ms_user_sso ENGINE = MyISAM ; 5、修改编码

表字符集默认使用utf8，通用，无乱码风险，汉字3字节，英文1字节，utf8mb4是utf8的超集，有存储4字节例如表情符号时使用。

查看编码 SHOW VARIABLES LIKE 'character%'; 修改编码 ALTER TABLE ms_user_sso DEFAULT CHARACTER SET utf8mb4; 五、数据管理 1、增删改查

添加数据

INSERT INTO ms_user_sso ( user_id,sso_id,sso_code,create_time,update_time,login_ip,state ) VALUES ( '1','SSO7637267','SSO78631273612', '2019-12-24 11:56:57','2019-12-24 11:57:01','127001','1' );

更新数据

UPDATE ms_user_sso SET user_id = '1',sso_id = 'SSO20191224',sso_code = 'SSO20191224', create_time = '2019-11-24 11:56:57',update_time = '2019-11-24 11:57:01', login_ip = '127001',state = '1' WHERE user_id = '1';

查询数据

一般情况下都是禁止使用 select *** 作。

SELECT user_id,sso_id,sso_code,create_time,update_time,login_ip,state FROM ms_user_sso WHERE user_id = '1';

删除数据

DELETE FROM ms_user_sso WHERE user_id = '2' ;

不带where条件，就是删除全部数据。原则上不允许该 *** 作，优化篇会详解。TRUNCATE TABLE也是清空表数据，但是占用的资源相对较少。

2、数据安全 不可逆加密

这类加密算法，多用来做数据验证 *** 作，比如常见的密码验证。

SELECT MD5('cicada')='94454b1241ad2cfbd0c44efda1b6b6ba' ; SELECT SHA('cicada')='0501746a2e4fd34e1d14015fc4d58309585edc7d'; SELECT PASSWORD('smile')='B4FB95D86DCFC3F33A3852714DC742C77504479D' ; 可逆加密

安全性要求高的系统，需要做三级等保，对数据的安全性极高，数据在存储时必须加密入库，取出时候需要解密，这些就需要可逆加密。

SELECT DECODE(ENCODE('123456','key_salt'),'key_salt') ; SELECT AES_DECRYPT(AES_ENCRYPT('cicada','salt123'),'salt123');

上述数据安全的管理，也可以基于应用系统的服务(代码)层进行处理，相对专业的流程是从数据生成源头处理，规避数据传递过程泄露，造成不必要的风险。

以上就是关于MySQL数据目录结构全部的内容，包括:MySQL数据目录结构、数据库表结构设计，常见的数据库管理系统、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！