标签：SHOW MySql 查询 索引 高性能 InnoDB MySQL 附录 SELECT

A. MySQL分支与变种

Percona Server

• Percona Server 是个与 MySQL 向后兼容的替代品，任何运行在 MySQL 上的都可以运行在 Percona Server 上。
• Percona Server 包括 Percona XtraDB 存储引擎，即改进版本的 InnoDB，这同样是个向后兼容的替代品。

MariaDB

Drizzle

• Drizzle 是真正的 MySQL 的分支，而非只是个变种或增强版本。它并不与 MySQL 兼容。

B. MySQL服务器状态

系统变量

• MySQL 通过 SHOW VARIABLES SQL命令展示系统变量。

SHOW STATUS

• SHOW STATUS命令会显示每个服务器变量的名字和值。这些变量是只读的。如果使用 SQL 命令，可以使用 LIKE 或 WHERE 来限制结果。可以从 INFORMATION_SCHEMA.GLOBAL_STATUS 和 INFORMATION_SCHEMA.SESSION_STATUS 表中查询。

• 现在SHOW STATUS默认展示会话变量，如果查看全局变量，则需要运行SHOW GLOBAL STATUS。

• 线程和连接统计。这些变量用来跟踪尝试的连接、退出的连接、网络流量和线程统计等。
  

• 二进制日志状态。Binlog_cache_use和 Binlog_cache_disk_use状态变量显示了在二进制日志缓存中有多少事务被存储过，以及多少事务因超过二进制日志缓存而必须存储到一个临时文件中。

• 命令计数器。Com_*变量统计了每种类型的 SQL 或 C API 命令发起过的次数。

• 临时文件和表。

• 句柄操作。句柄 API 是 MySQL 和存储引擎之间的接口。Handle_* 变量用于统计句柄操作。

• MyISAM 键缓冲。 Key_*变量包含度量值和关于 MyISAM 键缓冲的计数。

• 文件描述符。对于 MyISAM 存储引擎，Open_*变量揭示 MySQL 每隔多久打开每个表的.frm、.MYI 和.MYD 文件。InnoDB 保持所有的数据在表空间文件中，所以对于 InnoDB这些变量并不准确。

• 查询缓存。查询 Qcache_*状态变量可以检查查询缓存。

• SELECT 类型。Select_*变量是特定类型的 SELECT 查询的计数器。它们展示各种查询计划的 SELECT 查询比率。

• 排序。当 MySQL 不能使用索引获取预先排序的行，则必须使用文件排序，这会增加 Sort_*状态变量。

• 表锁。Table_locks_immediate 和 Table_locks_waited 变量展示有多少锁被立即授权，有多少锁需要等待。

SHOW ENGINE INNODB STATUS

• InnoDB 存储引擎在SHOW ENGINE INNODB STATUS输出中，它的输出是单独的一个字符串，分为很多小段。
• SEMAPHORES。包含了两种数据：事件计数器、以及可选的当前等待线程的列表。如果有高并发的工作负载，则需要关注该端。
• LATEST FOREIGN KEY ERROR。展示服务器最新的外键错误。
• LATEST DETECTED DEADLOCK。展示服务器内最新的死锁信息。
• TRANSACTIONS。包含关于 InnoDB 事务的总结信息，紧随其后是当前活跃事务列表。
• FILE I/O。FILE IO 部分显示的是 IO 辅助线程的状态，还有性能计数器的状态。
• INSERT BUFFER AND ADAPTIVE HASH INDEX。显示关于插入缓存和自适应哈希索引的状态。
• LOG。显示关于 InnoDB 事务日志(重做日志)子系统的统计。
• BUFFER POOL AND MEMORY。显示关于 InnoDB 缓冲池机器如何使用内存的统计。
• ROW OPERATIONS。

SHOW PROCESSLIST

• 进程列表是当前连接到 MySQL 的连接或线程的清单。SHOW PROCESSLIST 列出了这些线程，以及每个线程的状态信息。Command 和 State 列真正表明了线程的状态。

SHOW ENGINE INNODB MUTEX

• 改命令返回 InnoDB 互斥体的详细信息，每个互斥体都保护着代码中一个临界区。

复制状态

• MySQL 有几个命令用以监测复制。在主库上执行SHOW MASTER STATUS 可显示主库的复制状态和配置。输出包含了主库当前的二进制日志位置。通过SHOW BINARY LOGS可以获取到二进制日志的列表。通过SHOW BINLOG EVENTS可以查看二进制日志中的事件。在备库上执行 SHOW SLAVE STATUS查看复制的状态和配置。

INFORMATION_SCHEMA

• INFORMATION_SCHEMA 库是一个 SQL 标准中定义的系统视图的集合。能够以标准的 SQL 来进行查询。

Performance Schema

• Performance Schema是 MySQL 增强仪表的新的汇总处。默认情况下，Performance Schema是禁用的，需要打开并且使其在一个想要手机的特定的仅表点启用。

C. 大文件传输

一个简单的示例

• 在server1的源服务器，将文件进行压缩，并使用scp方法复制到server2

$ gzip -c /backup/mydb/mytable.MYD > mytable.MYD.gz
$ scp mytable.MYD.gz root@server2:/var/lib/mysql/mydb/

• 在server2执行如下命令，进行解压

$ gunzip /var/lib/mysql/mydb/mytable.MYD.gz

• 这个方法效率不高，因为在server1上gzip需要读写，scp在server1上读在server2上写，gunzip在server2上既要读又要写。

一步到位的方法

• 下面这个方法将压缩、复制文件和在传输的另一端解压缩文件全部放在一个步骤里完成。这个方法只需要在server1读，在server2上写。

$ gzip -c /backup/mydb/mytable.MYD | ssh root@server2 "gunzip -c - > /var/lib/mysql/mydb/mytable.MYD" 

避免加密的系统开销

• SSH 部署跨网传输数据的最快方法，因为它增加了加解密的系统开销。如果不需要加密，可以使用netcat把“裸数据”进行跨网传输。

其他选项

• 另一个选项是rsync。rsync易于在源和目标直接做镜像，并且还可以断点续传。但是，如果它的二进制差异算法无法被很好的发挥时，它不太会得到很好应用。

D. EXPLAIN

调用 EXPLAIN

• 在 SELECT 关键字前增加 EXPLAIN 这个词，MySQL 在执行查询时，这个标记会使其返回关于在执行计划中的每一步的信息，而不是执行它。
• EXPLAIN 语句并不总是不执行查询，如果在 FROM 子句中包含子查询，那 MySQL 实际会执行子查询。
• EXPLAIN 只是一个近似结果，有时其结果与真相相差甚远。

EXPLAIN 中的列

• id 列。id 列包含一个编号，标识 SELECT 所属的行。如果语句中没有子查询或联合，那么只会有唯一的 SELECT，于是每一行在这个列中都将显示一个1。否则，内层的 SELECT 语句一般会顺序编号。

• select_type 列。这一列展示了对应行是简单查询还是复杂查询，如果是复杂查询，那么是三种复杂类型中的哪一种。SIMPLE值意味着查询不包括子查询和 UNION。如果查询有任何复杂的子部分，则最外层部分标记为 PRIMARY。其他部分标记如下：

  • SUBQUERY。包含在 SELECT 列表中子查询的 SELECT。(不在 FROM 子句中)。
  • DERIVED。包含在 FROM 子句的子查询中的 SELECT。
  • UNION。在 UNION 中的第二个和随后的 SELECT 被标记为 UNION。
  • UNION RESULT。用来从 UNION 的匿名临时表中检索结果的 SELECT 被标记为 UNION RESULT。

• table 列。展示对应行正在访问哪个表。

• type 列。代表访问类型，也就是 MySQL 决定如何查找表中的行。如下为重要的访问方法，依次从差到优。

  • ALL。俗称全表扫描，代表 MySQL 必须扫描整张表来查询数据。
  • index。这个同样是全部扫描，只不过扫描表时按索引顺序进行，而不是行顺序。它的主要优点是避免了排序，缺点是要承担按索引排序读取整个表的开销，因为这往往是随机读取。
  • range。范围扫描就是一个有限制的索引扫描。这比全索引扫描好一些，因为不用遍历全部索引。常见的范围扫描是带有 BETWEEN 或在 WHERE 子句中带有比较的查询。
  • ref。这是一种索引访问，返回所有匹配某个单个值的行，当然也可能有多个符合条件的行。
  • eq_ref。这也是一种索引访问，相比 ref，MySQL 确定最多只返回一条符合条件的记录。
  • const，system。当 MySQL 能对查询的某部分优化转化为常量时，则使用此种访问类型。
  • NULL。 这种访问方式意为着 MySQL 能够在优化阶段分解查询语句，在执行阶段甚至用不着再访问表或者索引。

• possible_keys 列。这一列显示了查询可以使用哪些索引，这是基于查询访问的列和使用的比较操作符来判断的，这里出现的索引不代表 MySQL 最终会选择他们。

• key 列。这一列展示 MySQL 最终选择了哪个索引来优化对该表的访问。如果该索引没有出现在 possible_keys 列中，那么 MySQL 选用它是由于另外的原因——例如，它可能选择了一个覆盖索引，哪怕没有 WHERE 子句。

• key_len列。该列显示了 MySQL 在索引里使用的字节数。如果 MySQL 正在使用的只是索引里的某些列，可以根据这个值进行推算，比如一个联合索引，但是只使用了其最左侧列的情况。

• ref列。这一列展示了之前的表在 key 列记录的索引中查找值所用的列或常量。

• rows 列。这一列是 MySQL 估计为了找到所需的行而要读取的行数。它不是 MySQL 认为最终要从表里读取出来的行数，而是 MySQL 为了查询而必须扫描的行数。

• filtered列。它显示的是针对表里符合某个条件(WHERE 子句或联接条件)的记录数的百分比所做的一个悲观估算，优化器只有在使用 ALL、index、range、和 index_merge 访问方法时才会使用这一估算。

• Extra 列。这一列显示不适合在其他列显示的额外信息。常见的重要的值如下：

  • Using index。表示 MySQL 将使用覆盖索引，以避免访问表。不要把覆盖索引和 index 访问类型弄混了。
  • Using where。这意味着 MySQL 服务器将在存储引擎检索行后再进行过滤。又是 Using where 的出现就是一个暗示：查询可受益于不同的索引。
  • Using temporary。代表 MySQL 在对查询结果排序时会使用一个临时表。
  • Using filesort。这意味着 MySQL 会对结果使用一个外部索引排序，而不是按索引次序从表里读取行。

MySQL5.6中的改进

• MySQL 5.6中包括一个对 EXPLAIN 的重要改进：能对类似 UPDATE、INSERT 等的查询进行解释。

E. 锁的调试

服务器级别的锁等待

• 锁等待可能发生在服务器级别或存储引擎级别。服务器级别的锁有表锁、全局锁、命名锁、字符锁等类型。
• 表锁
  • 表锁可以是显式的，也可以是隐式的。显示的锁用 LOCK TABLES 创建。可以执行如下命令，在 sakila.film 上获取一个显式的锁：LOCK TABLES sakila.film READ;
  • 如果在另一个会话中也获取这个表的锁，查询将被挂起并且不会执行：LOCK TABLES sakila.film WRITE;
  • 使用命令SHOW PROCESSLIST;可以看到等待线程的状态是 Locked。
  • 服务器在查询过程中也会隐式地锁住表。一个长时间的查询即可将表锁住：SELECT SLEEP(30) FROM sakila.film LIMIT 1;当这个查询运行时，尝试再次锁住 film 表将会因为隐式锁而挂起。
  • 隐式锁和显式锁会阻塞，隐式锁也会相互阻塞。
• 全局读锁
  • MySQL 服务器实现了一个全局读锁，可以如下获取该锁：FLUSH TABLES WITH READ LOCK;
  • 如果此时在另一个会话中尝试获取表锁，将会被挂起。而等待线程在 SHOW PROCESSLIST 中的状态将会是 Waiting for release of readlock，代表查询在等待一个全局读锁而不是表级锁。
• 命名锁
  • 命名锁是一种表锁：服务器在重命名或删除一个表时创建。命名锁与普通的表锁相冲突，无论是显式还是隐式的。
• 用户锁
  • 在服务器中实现的最后一种锁是用户锁，它是一个命名互斥量，需要指定锁的名称字符串，以及等待超时秒数。SELECT GET_LOCK('my lock', 100);
  • 如果另一个线程尝试锁相同字符串，它将被挂起直到超时。

InnoDB 的锁等待

• InnoDB 在SHOW INNODB STATUS的输出中显示了一些锁信息。也可以通过查询 INFORMATION_SCHEMA 表的方式来显露 InnoDB 的事务和锁。

标签：SHOW,MySql,查询,索引,高性能,InnoDB,MySQL,附录,SELECT
来源： https://www.cnblogs.com/lianggx6/p/15612009.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。