MYSQL宏观介绍

一、存储引擎介绍

• InnoDB 存储引擎

InnoDB 是 MySQL 的默认事务型引擎，也是最重要、使用最广泛的存储引擎。它被设计用来处理大量的短期(short-lived)事务，短期事务大部分情况是正常提交 的，很少会被回滚。InnoDB的性能和自动崩溃恢复特性，使得它在非事务型存 储的需求中也很流行。除非有非常特别的原因需要使用其他的存储引擎，否则应 该优先考虑InnoDB 引擎。

• MylSAM 存储引擎

在 MySQL 5.1 及之前的版本，MyISAM 是默认的存储引擎。MyISAM 提供了 大量的特性，包括全文索引、压缩、空间函数（GIS）等，但 MyISAM 不支持事 务和行级锁，而且有一个毫无疑问的缺陷就是崩溃后无法安全恢复。尽管MyISAM 引擎不支持事务、不支持崩溃后的安全恢复，但它绝不是一无是处的。对于只读 的数据，或者表比较小、可以忍受修复（repair）操作，则依然可以继续使用 MyISAM （但请不要默认使用 MyISAM，而是应当默认使用 InnoDB)。但是 MyISAM 对整 张表加锁，而不是针对行。读取时会对需要读到的所有表加共享锁,写入时则对 表加排他锁。MyISAM 很容易因为表锁的问题导致典型的的性能问题。

二、MYSQL目录结构

更多MYSQL运维命令，可参考:linux 下 mysql 安装

三、日志文件

在服务器运行过程中，会产生各种各样的日志，比如常规的查询日志、错误 日志、二进制日志、redo 日志、Undo 日志等等，日志文件记录了影响 MySQL 数据库的各种类型活动。
常见的日志文件有：错误日志（error log）、慢查询日志（slow query log）、 查询日志（query log）、二进制文件（bin log）。

• 错误日志
  错误日志文件对 MySQL 的启动、运行、关闭过程进行了记录。遇到问题时 应该首先查看该文件以便定位问题。该文件不仅记录了所有的错误信息，也记录 一些警告信息或正确的信息。
  通过下面的sql查询错误文件位置:

show variables like 'log_error'

当Mysql出现问题时，通过这个文件查看原因。

• 慢查询日志
  慢查询日志可以帮助定位可能存在问题的 SQL 语句，从而进行 SQL 语句层面 的优化。
• 查询日志
  查询日志记录了所有对 MySQL 数据库请求的信息，无论这些请求是否得到 了正确的执行。 默认文件名：主机名.log
• 二进制日志（binlog）
  二进制日志记录了对 MySQL 数据库执行更改的所有操作，若操作本身没有 导致数据库发生变化，该操作可能也会写入二进制文件。但是不包括 select 和 show 这类操作（因为这些操作对数据本身不会进行修改）。
  二进制日志的几种作用：
  恢复（recovery）：某些数据的恢复需要二进制日志，例如，在一个数据库 全备文件恢复后，用户可以通过二进制文件进行 point-in-time 的恢复
  复制（replication）：其原理与恢复类似，通过复制和执行二进制日志使一 台远程的 MySQL 数据库（一般称为 slave 或 standby）与一台 MySQL 数据库（一 般称为 master 或 primary）进行实时同步
  审计（audit）：用户可以通过二进制日志中的信息来进行审计，判断是否有 对数据库进行注入的攻击

log-bin 参数
该参数用来控制是否开启二进制日志，默认为关闭。
如果想要开启二进制日志的功能，可以在 MySQL 的配置文件中指定如下的 格式：“name”为二进制日志文件的名称。
如果不提供 name，那么数据库会使用默认的日志文件名（文件名为主机名， 后缀名为二进制日志的序列号），且文件保存在数据库所在的目录（datadir 下） --启用/设置二进制日志文件(name 可省略)log-bin=name;
配置以后，就会在数据目录下产生类似于：
bin_log.00001 即为二进制日志文件；bin_log.index 为二进制的索引文件，用 来存储过往产生的二进制日志序号，通常情况下，不建议手动修改这个文件。
二进制日志文件在默认情况下并没有启动，需要手动指定参数来启动。开启 这个选项会对 MySQL 的性能造成影响，但是性能损失十分有限。根据 MySQL 官 方手册中的测试指明，开启二进制日志会使性能下降 1%。

四、MYSQL自带库

MYSQL自带了几个数据库，我们一一看这几个数据库的作用。

performance_schema库:
这个数据库里主要保存 MySQL 服务器运行过程中的一些状态信息，算是对 MySQL 服务器的一个性能监控。包括统计最近执行了哪些语句，在执行过程的每 个阶段都花费了多长时间，内存的使用情况等等信息。

应用:

• 查看最近执行失败的 SQL 语句

使用代码对数据库的某些操作（比如：使用 Java 的 ORM 框架操作数据库） 报出语法错误，但是代码并没有记录 SQL 语句文本的功能，在 MySQL 数据库层 能否查看到具体的 SQL 语句文本，看看是否哪里写错了？这个时候，大多数人首 先想到的就是去查看错误日志。很遗憾，对于 SQL 语句的语法错误，错误日志并 不会记录。
实际上，在 performance_schema 的语句事件记录表中针对每一条语句的执 行状态都记录了较为详细的信息，例如：events_statements_表和 events_statements_summary_by_digest 表（events_statements_表记录了语句所有 的执行错误信息，而 events_statements_summary_by_digest 表只记录了语句在执 行过程中发生错误的语句记录统计信息，不记录具体的错误类型，例如：不记录 语法错误类的信息）。下面看看如何使用这两个表查询语句发生错误的语句信息。在events_statements_history表中，通过SQL_TEXT 和 MESSAGE_TEXT 字段可以查看sql失败的情况。

• 查看最近的事务执行信息
  我们可以通过慢查询日志查询到一条语句的执行总时长，但是如果数据库中 存在着一些大事务在执行过程中回滚了，或者在执行过程中异常中止，这个时候 慢查询日志就爱莫能助了，这时我们可以借助 performance_schema 的 events_transactions_*表来查看与事务相关的记录，在这些表中详细记录了是否 有事务被回滚、活跃（长时间未提交的事务也属于活跃事务）或已提交等信息。
  首先需要进行配置启用，事务事件默认并未启用 update setup_instruments set enabled=‘yes’,timed=‘yes’ where name like ‘transaction%’; update setup_consumers set enabled=‘yes’ where name like ‘%transaction%’;
  查询活跃事务，活跃事务表示当前正在执行的事务事件，需要从 events_transactions_current 表中查询。

sys库:
这个数据库主要是通过视图的形式把 information_schema 和 performance_schema 结合起来，让程序员可以更方便的了解 MySQL 服务器的一 些性能信息。

• 查询表的增、删、改、查数据量和 I/O 耗时统计
  select * from schema_table_statistics_with_buffer

information_schema库:
这个数据库保存着 MySQL 服务器维护的所有其他数据库的信息，比如有哪 些表、哪些视图、哪些触发器、哪些列、哪些索引。这些信息并不是真实的用户 数据，而是一些描述性信息，有时候也称之为元数据
mysql库:
这个数据库核心，它存储了 MySQL 的用户账户和权限信息，一些存储过程、 事件的定义信息，一些运行过程中产生的日志信息，一些帮助信息以及时区信息 等。