第 2 章 MySQL 架构组成

2.1MySQL物理文件组成

2.1.1 日志文件

1、错误日志:Error Log

如果要开启系统记录错误日志的功能,需要在
启动时开启-log-error 选项。错误日志的默认存放位置在数据目录下,以hostname.err

名。但是可以使用命令:--log-error[=file_name],修改其存放目录和文件名。
为了方便维护需要,有时候会希望将错误日志中的内容做备份并重新开始记录,这时候
就可以利用MySQL
的FLUSH LOGS 命令来告诉MySQL 备份旧日志文件并生成新的日志文件。
备份文件名以“.old”结尾。

2、二进制日志:Binary Log & Binary Log Index

二进制日志,也就是我们常说的binlog,也是MySQL Server
中最为重要的日志之一。
当我们通过“--log-bin[=file_name]”打开了记录的功能之后,MySQL
会将所有修改数据
库数据的query 以二进制形式记录到日志文件中。当然,日志中并不仅限于query 语句这么
简单,还包括每一条query
所执行的时间,所消耗的资源,以及相关的事务信息,所以binlog
是事务安全的。

“--binlog-ignore-db=db_name”与“--binlog-do-db=db_name”两个参数有一个共同
的概念需要大家理解清楚,参数中的db_name
不是指query 语句更新的数据所在的数据库,
而是执行query 的时候当前所处的数据库。不论更新哪个数据库的数据,MySQL
仅仅比较当
前连接所处的数据库(通过use db_name 切换后所在的数据库)与参数设置的数据库名,而
不会分析query
语句所更新数据所在的数据库。

mysql-bin.index 文件(binary log index)的功能是记录所有Binary Log 的绝对路
径,保证MySQL
各种线程能够顺利的根据它找到所有需要的Binary Log 文件。

3、更新日志:update log

自从MySQL 增加了binlog 功能之后,
就很少使用更新日志了。从版本5.0 开始,MySQL 已经不再支持更新日志了。

4、查询日志:query log

--log[=fina_name]”来打开该功能,一般只用于跟踪某些特殊的sql 性能问题才会短暂打开该功能。

5、慢查询日志:slow query log

  顾名思义,慢查询日志中记录的是执行时间较长的query,也就是我们常说的slow
query,通过设--log-slow-queries[=file_name]来打开该功能并设置记录位置和文件名,
默认文件名为hostname-slow.log,默认目录也是数据目录。

  慢查询日志采用的是简单的文本格式,可以通过各种文本编辑器查看其中的内容。其中
记录了语句执行的时刻,执行所消耗的时间,执行用户,连接主机等相关信息。MySQL
还提
供了专门用来分析满查询日志的工具程序mysqlslowdump,用来帮助数据库管理人员解决可
能存在的性能问题。

6、Innodb 的在线redo 日志:innodb redo log

  Innodb 是一个事务安全的存储引擎,其事务安全性主要就是通过在线redo 日志和记录
在表空间中的undo 信息来保证的。redo
日志中记录了Innodb 所做的所有物理变更和事务
信息,通过redo 日志和undo 信息,Innodb 保证了在任何情况下的事务安全性。Innodb
的redo
日志同样默认存放在数据目录下,可以通过innodb_log_group_home_dir
来更改设置日志的
存放位置,通过innodb_log_files_in_group 设置日志的数量。

2.1.2 数据文件

  在MySQL
中每一个数据库都会在定义好(或者默认)的数据目录下存在一个以数据库名
字命名的文件夹,用来存放该数据库中各种表数据文件。不同的MySQL
存储引擎有各自不同
的数据文件,存放位置也有区别。多数存储引擎的数据文件都存放在和MyISAM
数据文件位
置相同的目录下,但是每个数据文件的扩展名却各不一样。如MyISAM 用“.MYD”作为扩展
名,Innodb
用“.ibd”,Archive 用“.arc”,CSV 用“.csv”,等等。

1、“.frm”文件
与表相关的元数据(meta)信息都存放在“.frm”文件中,包括表结构的定义信息等。
不论是什么存储引擎,每一个表都会有一个以表名命名的“.frm”文件。所有的“.frm”文
件都存放在所属数据库的文件夹下面。

2、“.MYD”文件
“.MYD”文件是MyISAM 存储引擎专用,存放MyISAM 表的数据。每一个MyISAM
表都会
有一个“.MYD”文件与之对应,同样存放于所属数据库的文件夹下,和“.frm”文件在一起。

3、“.MYI”文件
“.MYI”文件也是专属于MyISAM 存储引擎的,主要存放MyISAM 表的索引相关信息。对
于MyISAM
存储来说,可以被cache
的内容主要就是来源于“.MYI”文件中。每一个MyISAM
表对应一个“.MYI”文件,存放于位置和“.frm”以及“.MYD”一样。

4、“.ibd”文件和ibdata 文件
这两种文件都是存放Innodb 数据的文件,之所以有两种文件来存放Innodb
的数据(包
括索引),是因为Innodb
的数据存储方式能够通过配置来决定是使用共享表空间存放存储数
据,还是独享表空间存放存储数据。独享表空间存储方式使用“.ibd”文件来存放数据,且
每个表一个“.ibd”文件,文件存放在和MyISAM
数据相同的位置。如果选用共享存储表空
间来存放数据,则会使用ibdata 文件来存放,所有表共同使用一个(或者多个,可自行配
置)ibdata
文件。ibdata 文件可以通过innodb_data_home_dir 和innodb_data_file_path
两个参数共同配置组成,
innodb_data_home_dir 配置数据存放的总目录, 而
innodb_data_file_path 配置每一个文件的名称。当然,
也可以不配置
innodb_data_home_dir 而直接在innodb_data_file_path
参数配置的时候使用绝对路径来
完成配置。innodb_data_file_path 中可以一次配置多个ibdata
文件。文件可以是指定大
小,也可以是自动扩展的,但是Innodb 限制了仅仅只有最后一个ibdata
文件能够配置成自
动扩展类型。当我们需要添加新的ibdata
文件的时候,只能添加在innodb_data_file_path
配置的最后,而且必须重启MySQL 才能完成ibdata
的添加工作。不过如果我们使用独享表
空间存储方式的话,就不会有这样的问题,但是如果要使用裸设备的话,每个表一个裸设备,
可能造成裸设备数量非常大,而且不太容易控制大小,实现比较困难,而共享表空间却不会
有这个问题,容易控制裸设备数量。我个人还是更倾向于使用独享表空间存储方式。当然,
两种方式各有利弊,看大家各自应用环境的侧重点在那里了。

2.1.3 Replication相关文件:

1、master.info 文件:

  master.info 文件存在于Slave 端的数据目录下,里面存放了该Slave 的Master 端的
相关信息,包括Master
的主机地址,连接用户,连接密码,连接端口,当前日志位置,已
经读取到的日志位置等信息。

2、relay log 和relay log index

  mysql-relay-bin.xxxxxn 文件用于存放Slave 端的I/O 线程从Master 端所读取到
的Binary Log
信息,然后由Slave 端的SQL 线程从该relay log 中读取并解析相应的
日志信息,转化成Master 所执行的SQL 语句,然后在Slave
端应用。
mysql-relay-bin.index 文件的功能类似于mysql-bin.index
,同样是记录日志的存
放位置的绝对路径,只不过他所记录的不是Binary Log,而是Relay Log。

3、relay-log.info 文件:
  类似于master.info,它存放通过Slave 的I/O 线程写入到本地的relay log
的相关信
息。供Slave 端的SQL 线程以及某些管理操作随时能够获取当前复制的相关信息。

2.1.4 其他文件:

1、system config file

1、system config file
MySQL 的系统配置文件一般都是“my.cnf”,Unix/Linux
下默认存放在"/etc"目录下,
Windows
环境一般存放在“c:/windows”目录下面。“my.cnf”文件中包含多种参数选项组
(group),每一种参数组都通过中括号给定了固定的组名,如“[mysqld]”组中包括了mysqld
服务启动时候的初始化参数,“[client]”组中包含着客户端工具程序可以读取的参数,此
外还有其他针对于各个客户端软件的特定参数组,如mysql
程序使用的“[mysql]”,mysqlchk
使用的“[mysqlchk]”,等等。如果读者朋友自己编写了某个客户端程序,也可以自己设定
一个参数组名,将相关参数配置在里面,然后调用mysql
客户端api 程序中的参数读取api
读取相关参数。

2、pid file
  pid file 是mysqld 应用程序在Unix/Linux
环境下的一个进程文件,和许多其他
Unix/Linux 服务端程序一样,存放着自己的进程id。

3、socket file
  socket 文件也是在Unix/Linux 环境下才有的,用户在Unix/Linux
环境下客户端连接
可以不通过TCP/IP 网络而直接使用Unix Socket 来连接MySQL。

时间: 2024-10-06 11:56:17

第 2 章 MySQL 架构组成的相关文章

高性能Mysql(第一章MySQL架构与历史)

逻辑架构 mysql的逻辑架构分为3层, 连接线程处理. 服务器的核心功能,查询解析.分析.优化.缓存以及所有的内至函数. 存储引擎,负责MySQL中数据的存储和提取,每个存储引擎都有它的优势和劣势,服务器通过API与存储引擎进行通信,这些接口屏蔽了不同存储引擎之间的差异. 并发控制 读写锁通常也称为共享锁和排他锁, 读锁是共享的,多个客户在同一时间可以同时读取同一个资源,而互不干扰. 写锁则是排他的,也就是说一个写锁会阻塞其它的写锁和读锁. 锁粒度 表锁是MySQL中的最基本的策略,它会锁定整

高性能MySQL笔记:第1章 MySQL架构

MySQL 最重要.最与众不同的特性是他的存储引擎架构,这种架构的设计将查询处理(Query Precessing)及其系统任务(Server Task)和数据的存储/提取相分离. 1.1 MySQL 逻辑架构 基础服务层 第一层构架 :包含连接处理.授权认证.安全等基础服务功能: 核心服务层 第二层构架 :包含查询解析.分析.优化(包括重写查询.决定表的读取顺序.选择合适的索引等).缓存以及内置函数,所有跨存储引擎的功能也在这一层实现:存储过程.触发器.视图等: 存储引擎层 第三层构架 :响应

第01章 MySQL架构与历史

MySQL最重要的特性是它的存储引擎架构,它将查询处理与其他的系统任务和数据存储,提取相分离. 1 MySQL逻辑架构 最上层的是客户端:主要负责链接处理,授权认证,安全等 中间一层是MySQL的核心,服务器:主要负责查询解析,分析优化,缓存以及所有的内置函数,所有跨存储引擎的功能都在这一层实现,例如:存储过程,触发器,视图等 最下一层是存储引擎:存储引擎负责MySQL中数据的存储和提取,可以使用不同的存储引擎,不同的存储引擎有各自的优势和劣势,不同的存储引擎之间不能通信,只相应上层服务器的请求

高性能mysql 第1章 mysql架构与历史(1)

mysql逻辑架构图: 第一层 客户端 第二层(服务层):针对所有类型的存储引擎可以公共提取的部分.将存储引擎抽离之后的其他部分都在这里.如:查询解析,分析优化,内置函数,存储过程,触发器,视图. 第三层(存储引擎层):存储引擎负责mysql数据的存储和提取.服务器通过API与存储引擎进行通信.这些API屏蔽了不同存储引擎的具体实现差异.存储引擎API包含"开始一个事务","根据主键获取一行数据"等操作.存储引擎本身不会去解析sql. 注:mongdb也有存储引擎.

高性能MySQL_第一章-MySQL架构和历史

事务:一组原子性的SQL查询.如果数据库能够成功的对数据库应用该组查询的全部语句,那么就执行改组查询:否则所有的语句都不会执行. ACID:原子性(atomocity),一致性(consistency),隔离性(isolation),持久性(durability). 原子性:一个事务必须被视为不可分割的最小执行单元.整个事物的操作要么全部提交成功,要么全部失败回滚,不可能存在只执行了一部分的操作. 一致性:数据库总是从一个一致性的状态转移到另一个一致性的状态.即使中间出现问题,因为事务没有提交,

高性能MySQL-第一章MySQL架构与历史

并发控制 锁粒度 MySQL 中提供了两种锁粒度:表级锁.行级锁. 表锁:写锁的优先级高于读锁:写锁的请求可以插入到读锁的前面,但读锁的请求却不能插入到写锁的前面: 行级锁:行级锁只在存储引擎层实现,在服务器层没有实现: 尽量只锁定需要修改的那部分数据,而不是所有的资源.锁定的数据量越少,发生锁争用的可能就越小,系统的并发程度就越高. 但是加锁需要消耗资源,锁的各种操作(包括获取锁.释放锁.以及检查锁状态)都会增加系统开销.因此锁粒度越小,系统开销就越大. 锁类型 1.读写锁 互斥锁(Exclu

ch2 MySQL 架构组成

第 2 章 MySQL 架构组成 前言 麻雀虽小,五脏俱全.MySQL????虽然以简单著称,但其内部结构并不简单.本章从 MySQL 物理组成.逻辑组成,以及相关工具几个角度来介绍????MySQL????的整体架构组成,希望能够让读者对????MySQL????有一个更全面深入的了解. 2.1 MySQL 物理文件组成 2.1.1 日志文件 错误日志:Error????Log 错误日志记录了 MyQL????Server 运行过程中所有较为严重的警告和错误信息,以及 MySQL Server

MySQL性能调优与架构设计——第9章 MySQL数据库Schema设计的性能优化

MySQL性能调优与架构设计——第9章 MySQL数据库Schema设计的性能优化 前言: 很多人都认为性能是在通过编写代码(程序代码或者是数据库代码)的过程中优化出来的,其实这是一个非常大的误区.真正影响性能最大的部分是在设计中就已经产生了的,后期的优化很多时候所能够带来的改善都只是在解决前妻设计所遗留下来的一些问题而已,而且能够解决的问题通常也比较有限.本章将就如何在 MySQL 数据库 Schema 设计的时候保证尽可能的高效,尽可能减少后期的烦恼. 9.1 高效的模型设计 最规范的就一定

MySQL性能调优与架构设计——第1章 MySQL 基本介绍

MySQL性能调优与架构设计——第1章 MySQL 基本介绍 前言:作为最为流行的开源数据库软件之一, MySQL 数据库软件已经是广为人知了. 但是为了照顾对MySQL还不熟悉的读者,这章我们将对 MySQL 做一个简单的介绍.主要内容包括MySQL 各功能模块组成,各模块协同工作原理, Query 处理的流程等. 1.1 MySQLServer 简介 1.1.1 什么是 MySQLMySQL 是由MySQL AB公司(目前已经被SUN公司收归麾下,SUN已经被Oracle收购)自主研发的,目