巡检工作是保障系统平稳有效运行必不可少的一个环节，目的是能及时发现系统中存在的隐患。我们生活中也随处可见各种巡检，比如电力巡检、消防检查等，正是这些巡检工作，我们才能在稳定的环境下进行工作、生活。巡检对于数据库或者其他IT系统来说也同样至关重要，特别是在降低风险、提高服务稳定性方面起到了非常关键作用。

本文介绍了美团MySQL数据库巡检系统的框架和巡检内容，希望能够帮助大家了解什么是数据库巡检，美团的巡检系统架构是如何设计的，以及巡检系统是如何保障MySQL服务稳定运行的。

一、背景

为了保障数据库的稳定运行，以下核心功能组件必不可少：

图1 数据库运维保障核心功能组件

…

客户端通过以SQL语句的形式发送请求给服务器端从而从表中获取数据或对表数据进行修改。而服务端程序使用以下两层处理模型以执行每个语句请求：dbdao.com

• 上层包括SQL解析器(parser)和优化器(optimizer)。

• 下层包括了一组存储引擎。

需要注意的是，SQL层并不依赖于存储引擎管理的表。这意味着客户端通常不需要考虑哪个引擎被涉及处理其SQL语句，也不用考虑访问和更新的表是受到哪个引擎的管理。当然也有例外：

• CREATE TABLE语句有ENGINE项可用于在建立表时启用你所定义的存储引擎。ALTER TABLE语句也含有一个ENGINE项可以使你能将原表转换使用一个不同的存储引擎。

• …

MySQL Server内存使用中包括了用于管理与客户端之间进行沟通和处理数据库内容Server所建立的数据结构。它会在运行时为许多类型的信息分配内存，如：

• 线程(Thread Handler):

线程在MySQL（或其它程序）中被用于将应用的执行分成多个同步运行的任务。对每个连接到MySQL Server的客户端，Server都会建立一个独立的线程来进行连接处理。MySQL Server为了避免一些可能产生的性能问题，会分配一块小的缓存给这些线程，在客户端断开后，被分配的缓存仍然会被保持。任何新的连接会首先通过此缓存来实例化线程，而不是重新建立一个新线程。这样就能确保内存消耗始终处于最低状态。

• 缓存(Buffers / Cache)

MySQL …

问题 当前，绝大多数业务场景用InnoDB已经完全能搞定了，越来越多的业务从MyISAM转向InnoDB引擎，那么有哪些注意事项呢？ 分析 当了解完两种引擎的不同之处，很轻松的就能知道有哪些关键点了。

   总的来说，从MyISAM转向InnoDB的注意事项有：

1、MyISAM的主键索引中，可以在非第一列(非第一个字段)使用自增列，而InnoDB的主键索引中包含自增列时，必须在最前面；这个特性在discuz论坛中，被设计用于“抢楼”功能，因此，若有类似的业务，则无法将该表从MyISAM转成InnoDB，需要自行变通实现(我们则是将其改到Redis中实现)；
2、不带条件频繁统计全表总记录数时(SELECT COUNT(*) FROM TAB)，InnoDB相对较慢，而MyISAM则飞快；不过，如果是基于索引条件的统计，则二者相差不大； …

前言

   对于一个web网站的性能来说，瓶颈多半是来自于数据库。一般数据库查询会在某个请求的整体耗时中占很大比例。如果能提高数据库查询的效率，网站的整体响应时间会有很大的下降。如果能实现mysql查询的异步化，就可以实现多条sql语句同时执行。这样就可以大大缩短mysql查询的耗时。

异步为啥比同步快？

   与异步查询相反的时同步查询。通常情况下mysql的query查询都是同步方式。下面我们对两种方式做下对比。对比的例子是，请求两次select sleep(1)。这条语句在mysql服务器端大概耗时1000ms。

   同步方式的执行流程：

  …

   关于MySQL线程池资料整理-Percona Server

   MySQL执行statement使用一个连接一个thread的方式,当连接数增加到某一个点,那么性能将会开始下降.

   这个特性的作用就是无论有多少连接,thread pool都讲保证性能处于最好水平.

   thread pool的原理主要是减少线程,减少上下文交换和锁资源争抢,针对OLTP环境特别有效.

   为可以开启thread pool功能,请将thread_handling=pool-of-threads.

   percona server实现的thread pool是在server级别,和oracle mysql的不一样(插件形式),另外一个不同点在于,percona的thread pool不尝试最小化并发事物数量.

   优先连接调度:

   在percona server 5.5.30,thread …

1. 背景

MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。

注：MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。

1. MVCC：Snapshot Read vs Current Read

MySQL …

大约在两年前，我写了一篇关于MySQL索引的文章。最近有同学在文章的评论中对文章的内容提出质疑，质疑主要集中在联合索引的使用方式上。在那篇文章中，我说明联合索引是将各个索引字段做字符串连接后作为key，使用时将整体做前缀匹配。

而这名同学在这个页面找到了如下一句话：index condition pushdown is usually useful with multi-column indexes: the first component(s) is what index access is done for, the subsequent have columns that we read and check conditions on。从而认为联合索引的使用方式与文中不符。

实际上，这个页面所讲述的是在MariaDB 5.3.3（MySQL是在5.6）开始引入的一种叫做Index Condition …

   如果需要恢复的二进制日志较多，较复杂，强烈建议使用MySQL自身复制来恢复binlog，而不要使用mysqlbinlog。

   在MySQL手册中一直是推荐使用mysqlbinlog工具来实现指定时间点的数据恢复，事实上，这是一个经常"让人郁闷"的办法。更好的办法是，使用MySQL内部复制线程中的SQL Thread来做恢复。

   这个idea来自Lazydba同学；在Google稍作搜索，在Xaprb上Baron Schwartz也很早提到了使用类似的方法来恢复binlog，在 …