关系型数据库的常见组件
数据库：database
表：table
行：row
列：column
索引：index
试图：view
用户：user
权限：privilege
存储过程：procedure
存储函数：function
触发器：trigger
事件调度器：event scheduler错误日志：Error log
默认情况下错误日志大概记录以下几个方面的信息：
1、服务器启动和关闭过程中的信息（未必是错误信息，例如，mysql如何启动INNODB的表空间文件的、如何初始化自己的存储引擎的等）
2、服务器运行过程中的错误信息
3、事件调度器运行一个事件时产生的信息
4、在从服务器上启动服务器进程时产生的信息
注意：
1、可以根据自身需求设定不同错误日志的值
1=只记录 Errors 级别的日志
2=记录Errors、warnings 级别的日志
3=记录Errors、warnings、notes（defaults）级别的日志
2、如何删除旧的错误日志
在mysql5.7之前：数据库管理员可以删除很长时间之前的错误日志，以保证mysql服务器上的硬盘空间。mysql数据库中，可以使用mysqladmin命令开启新的错误日志：
命令语法如下：mysqladmin -u root -p flush_logs 也可以登陆mysql数据库中使用flush logs 语句来开启新的错误日志
在5.7之后：服务器将关闭此项功能。只能使用重命名原来的错误日志文件，手动冲洗日志创建一个新的
方式如下：mv mysqld.err mysqld.err.old二进制日志：Binary Log & Binary Log Index
二进制日志也就是我们常说的binlog日志，也是MySQL server 中最重要的日志之一，主要用于记录修改数据或有可能引起数据改变的mysql语句，并记录了：
1、语句发生时间
2、执行时长
3、操作的数据
4、等等
所以说通过二进制日志可以查询mysql数据库中进行了那些变化
一般体积上限为1G
当我们通过“log-bin=file_name”打开了记录的功能之后，MySQL会将所有修改数据库数据的query以二进制形式记录到日志文件中。当然，日志中不仅有query语句这么简单，还包括每一条query所执行的时间，所消耗的资源，以及相关的事务信息，所以binlog是事务安全的。
和错误日志一样，binlog记录功能同样需要“bin-log=file_name”参数的显示指定才能开启，如果未指定file_name，则会在数据目录下记录为mysql-bin.（代表0~9之间的某一个数字，来表示该日志的序号）
bin-log还有其他一些附加选项参数：
max_binlog_size:来设置binlog的最大存储上限，一般设为512M或1G，一般不能超过1G，当日志达到该上限时，MySQL会重新创建一个日志继续记录。不过偶尔也有超过该设置的binlog产生，一般都是因为在即将达到上限时，产生了一个较大的事务，为了保证事务的安全，mysql不会将同一个事务记录到两个binlog中。
binlog-do-db=db_name：如果有了该参数的显示指定，MySQL会忽略针对其他数据库执行的query，而仅仅记录针对指定数据库执行的query。
“binlog_ignore_db=db_name”与“binlog-do-db=db_name” 完全相反，他显示指定忽略某个数据库的binlog记录，当指定了这个参数之后，MySQL会记录指定数据库以外所有的数据库的binlog。
“binlog-do-db=db_name”与“binlog_ignore_db=db_name”两个参数有一个共同的概念：
参数中的db_name不是值query语句更新的数据库所在的数据库，而是执行query的时候当前所处的数据库。不论更新那个数据库的数据，MySQL仅仅比较当前连接所处的数据库（通过use db_name 切换后所在的数据库）与参数设置的数据库同名，而不会分析query语句所更新数据所在的数据库。
其中，mysql_bin.index文件（binary log index）的功能是记录所有Binary Log 的绝对路径，保证MySQL 各种线程能够顺利的根据他找到所有需要的Binary Log 文件。
bin_cache_size=32768（默认）
bin_cache_size ：一个事务，在没提交（uncommitted）的时候，产生的日志，记录到cache中：等到事务提交（committed）需要提交的时候，则把日志持久化到磁盘。一般来说，如果我们数据库中没有什么大事务，写入也不是特别频繁，2MB~4MB是一个合适的选择。但是如果我们的数据库大事务较多，写入量较大，可以适当调高binlog_cache_size。同时，我们可以通过binlog_cache_use以及binlog_cache_disk_use来分析设置的binlog_cache_size是否足够，是否有大量的binlog_cache由于内存大小不够而使用临时文件来缓存了
binlog_stmt_cache_size=32768 #当非事务语句使用二进制日志缓存，但是超出binlog_stmt_cache_size时，使用一个临时文件来存放这些语句。
binlog-format={ROW|STATEMENT|MIXED}#指定二进制日志的类型，默认为MIXED。
1、STATEMENT模式（SBR）
每一条会修改数据的sql语句会记录到binlog中。
优点是并不需要记录每一行的数据变化，减少了binlog日质量，节约IO，提高性能，
缺点是在某些情况下会导致master-slave中的数据不一致（如sleep（）函数，last__insert_id()，以及user-defind functions（udf）等会出现问题）
2、ROW模式（RBR）
不记录每条sql语句的信息，仅需记录那条数据被修改了，修改成什么样了
缺点是会产生大量的日志，使日志暴涨。
3、MIXED模式（MBR）
以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的sql语句选择日志保存方式。即交替使用行和语句、由MySQL服务器自行判断。
其中基于行的定义格式数据量会大一些但是可以保证数据的准确性。
sync_binlog=10 #设定多久同步一次二进制日志至磁盘文件中，0表示不同步，任何正数值都表示对二进制没多少次写操作之后同步一次。当autocommit的值为一时，每条语句执行都会引起二进制日志同步，否则，每个事务的提交会引起二进制日志的同步。
max_binlog_cache_size #二进制日志缓存空间大小，5.5.9即以后的版本仅用于事务缓存，其上线由max_stmt_cache_size决定。
expire_log_days={0，99} #设定二进制日志日志的过期天数，超过次天数的二进制日志将会自动删除，默认为0，表示不启用过期自动删除功能。如果启用此功能，自动删除通常发生在MySQL启动时或FLUSH日志时。
当前二进制文件及所处位置
show binary logs；
查看二进制文件信息
show master status；
查看所有的二进制信息
show binlog event\G
查看指定日志的二进制信息
show binlog events in 'mysql-bin.*' \G
**命令行下查看二进制日志
mysqlbinlog “binlog_name”
删除二进制日志信息
purge {binary|master} logs {to ‘log_name’ | before datetime_expr}
例：purge binary logs to 'mysql-bin.000006'
删除所有的二进制日志（慎用）
reset master；
不建议生产环境使用此操作事务日志：（或称redo日志）
事务日志（InnoDB特有的日志）可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据持久到硬盘。事务日志采用追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在多个地方移动磁头，所以采用事务日志的方式相对来说要快的多。事务日志持久以后，内存中被修改的数据在后台可以慢慢刷回磁盘。目前大多数的存储引擎都是这样实现的。
如果事务的修改已经记录到了事务日志并持久化，单数据本身还没有写会磁盘，此时系统崩溃，存储引擎再重启时能够自动恢复这部分修改的数据。具有的恢复方式则视存储引擎而定。
查看mysql已提供什么养的搜索引擎
show engines
查看mysql当前默认的存储引擎
show variables like '%storage_engine%'
查看某个表用了什么引擎
show create teble 表名；
改变表的存储引擎
create table 库名.表明 engine=“innodb”
查看事务日志的定义
show global variables like 'innodb_flush_log_at%'
#在事务提交时innodb是否同步日志从缓冲区到文件中，
当这个值为1（默认值）之时，在每个事务提交时，日志被写到日志文件，对日志文件做到磁盘操作的刷新，性能会很差造成大量的磁盘I/O但这种方式最安全：
如果设为2，每次提交事务都会写到日志，但并不会执行刷操作。每秒定时刷到日志文件,并不能保证100%每秒一定会刷新到磁盘，这要取决于进程的调度。
设置为0，日至缓冲每秒一次的被写入到日志文件，并且对日志文件做到磁盘操作的刷新，但是在一个事物提交不做任何操作。
**刷写的概念
刷写其实是两个操作，刷（flush）和写（write），区分这两个概念是很重要的。在大多数的操作系统中，把InnoDB的log buffer （内存）写入日志（调用系统调用write），只是简单的把数据转移到操作系统缓存中，操作系统缓存同样指的是内存。并没有持久化数据。
所以在0和2的时候，在崩溃或断电的时候会丢失最后一秒的数据，因为这个时候数据只存在于操作系统的缓存。之所以说通常，可能会丢失不止一秒的数据的情况，比如说执行flush操作的时候阻塞了。
总结：
设为1当然是最安全的，但是性能也是最差的（相对于其他两个参数而言，但不是不能接受）。如果对数据一致性和完整性要求不高，完全可以设为2，如果只要求性能，例如高并发写的日志服务器，设为0来获得更高的性能。慢查询日志： slow query log
顾名思义，慢查询日志中记录的是执行时间较长的query，也就是我们常说的 slow query。慢查询日志采用的是简单的文本格式，可以通过各种文本编辑器查看其中的内容。其中记录了语句执行的时刻，执行所消耗的时间，执行用户，连接主机等相关信息。
慢查询日志的作用：
慢查询日志是用来记录执行时间较长的query，也就是我们常说的slow query 。
通过慢查询日志可以查出来那些查询语句执行效率比较低，以便进行优化，一般建议开启，他对服务器性能的影响微乎其微，但是可以记录mysql服务器上执行了很长时间的查询语句。可以帮助我们定位性能问题。mysql还提供了专门用来分析慢查询日志的工具程序mysqldumpslow，用来帮助数据库管理人员解决可能存在的性能问题。
查看慢查询日志的定义
show global variables like '%slow_query_log%'
启动和设置慢查询日志
方法一：通过my.cnf开启慢查询日志
方法二：登陆MySQL服务器直接设置（使用set_query_log=1）
大多是版本都可以使用show variables like '%slow%' 或 show variables like '%long%'
其中
slow_query_log； off关闭状态，on开启状态
slow_query_log_file: 慢查询日志存放地点
long_query_time： 设置时间值，时间以秒为单位，可以精确到微秒，如果超过了这个时间（默认是10秒）这个查询语句将记录到慢查询日志当中。设置为0的话，表示记录所有的查询。
注：
1、如果不指定路径，默认存储到mysql数据库的数据文件下，如果不指定文件名，默认文件名为hostname-slow.log
2、将Unix时间转成一个可读的时间，可以使用date -d@日志中的时间戳
3、mysqldumpslow 选项 参数
-s 是表示按照何种方式排序 ，c，t，l，r 分别是按照记录次数，时间，查询时间，返回的记录数来排序，ac，at，al，ar表示相应的倒序。
-t ，是top n的意思，即为返回前面多少条的数据
-g，后面可以写一个正则表达式，大小写不敏感的
文件类型：
1、.frm 文件
与表相关的元数据（meta）信息都存放在“.frm”文件中，包括表结构的定义信息等。不论是什存储引擎专用么存储引擎，每一个表都会有一个以表命名的.frm文件。存放在所属数据库的文件夹下面
2、MyISAM数据库表文件：.MYD文件：表数据文件 .MYI：表索引文件
3、InnoDB采用表空间（tablespace）来管理数据，存储表数据和索引
.ibd文件：但表表空间文件，每个表使用一个表空间文件（file per table），存放用户数据库表数据和索引
InnoDB共享表空间（即InnoDB文件集，ib-file set）：ibdata1、ibdata2等，存储InnoDB系统信息和用户数据库表数据和索引，所有表共用
4、.ibd文件和ibdata文件
这两种文件都是存放InnoDB数据的文件，之所以有两种文件来存放InnoDB的数据（包括索引），是因为InnoDB的数据存储方式能够通过配置来决定是使用共享表空间存放存储数据，还是独享表空间来存储数据。
独享表空间：.ibd
共享表空间：.ibdata
ibdata文件可以通过
innodb_data_file_path 配置数据存放的总目录
可以一次配置多个idbata文件，文件可以指定大小，也可以设为自动扩展，但只有最后一个ibdata文件可以设置为自动扩展。
必须重启才能完成ibdata的添加工作
总结：
共享表空间以及独占表空间都是针对数据的存储方式而言的
共享表空间：某一个数据库的所有表数据，索引文件全部放在一个文件中
独占表空间：每一个都将会生成以独立的文件方式来进行存储，每一个表都有一个.frm表描述文件，还有一个。ibd文件，其中这个文件包括了单独一个表的数据内容以及索引内容
两者之间的优缺点：
共享表空间
优点：
可以放表空间分成多个文件存放到各个磁盘上。数据和文件放在一起方便管理
缺点：
所有数据和索引都放在一个文件中，多个表及索引在表空间中混合存储，这样对于一个表做了大量删除操作后表空间中将会有大量的空隙，特别是对于统计分析，日值系统这类应用最不适合用共享表空间。
独立表空间
优点：
1、每个表都有自己独立的表空间
2、每个表的数据和索引都会存在自己的表空间中
3、可以实现单表在不同数据库中移动
4、空间可以回收
a、Drop table 操作自动回收表空间，如果对于统计分析或是日值表，删除大量数据以后，可以通过：altertable TableName engine = innodb;回缩不用的空间
b、对于使用独立表空间的表，不管怎么删除，表空间的碎片不会太严重的影响性能，而且还有机会处理。
缺点：
单表增加过大，如超过100个G
相比之下，使用独占表空间的效率和性能会更高一点
ON代表独立表空间， OFF代表共享表空间
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.index文件
类似于master.info ，它存放通过Slave的I/O线程写入到本地的relay log 的相关信息，共slave端的SQL线程及某些管理操作随时能够获取当前复制的相关信息。
其他文件：
1、system config file
MySQL的系统配置文件一般是 my.cnf
2、pid file
pid file 是mysql应用程序在unix/linux环境下的一个进程文件
3、socket file
socket文件只在unix/linux 环境下才有，可直接只用socket文件来连接mysql，，速度比TCP的要快，但是只适用于mysql和应用在一台PC上。总结：
1、查看系统设置
show [global|session] variables [like_or_where]
2、运行状态
show [global|session] status [like_or_where]
3、刷新日志
flush log