mysql监控思路

生产环境的mysql一直缺乏有效的监控，接下来即将进入业务推广期，我这个半路出家的DBA，心总感觉是悬着的……

这条路没有错，继续前行吧——1988：我想和这个世界谈谈

那在黑暗里行走的，不知道往何处去——约翰福音 12:35

整理下mysql监控的思路：

1、Why

自然是希望更透彻的了解业务现状、趋势，发现瓶颈和问题；

同时，也可以通过数据评估配置/代码变更后的影响。

2、How
Agentless！从运营规定和个人习惯的角度，不希望安装额外的agent。

3、Key（basics & important）

哪些是最关键的指标？学习别人的最佳实践比较快，下面的关键指标来自“mysql-tuning-primer”

Slow Query Log （慢查询） 
Max Connections （最大连接数） 
Worker Threads （工作线程） 
Key Buffer （Key 缓冲） 
Query Cache （查询缓存） 
Sort Buffer （排序缓存） 
Joins （连接） 
Temp Tables （临时表） 
Table (Open & Definition) Cache （表缓存） 
Table Locking （表锁定） 
Table Scans (read_buffer) （表扫描，读缓冲）

几个比较不错的网站： ronaldbradford、hackmysql（新用户贴外链会被封……好吧，回头再补……）

4、Tools

工欲善其事，必先利其器，了解一下总不会错

Percona Toolkit for MySQL

mycheckpoint

mysql-tuning-primer

5、基于mysqladmin的快速实践，mysql自带的，方便省事！

最常用的3个：

mysqladmin status

mysqladmin processlist

mysqladminextended-status

#获取当前数据库的连接数
mysql -uroot -BNe "select host,count(host) from processlist group by host;" information_schema

#显示mysql的uptime
mysql -e"SHOW STATUS LIKE '%uptime%'"|awk '/ptime/{ calc = $NF / 3600;print $(NF-1), calc"Hour" }'

#查看数据库的大小，单位MByte
mysql -uroot -e 'select table_schema,round(sum(data_length+index_length)/1024/1024,1) from information_schema.tables group by table_schema;'

#QPS：

mysqladmin extended-status --relative --sleep=1 | grepQueries（或者Questions，区别在存储过程的计数）

#TPS：（Com_commit+Com_rollback）

mysqladmin extended-status --relative --sleep=1| grep Com_commit

mysqladmin extended-status --relative --sleep=1|grep Com_rollback

附extended-status相关内容的翻译，来源于网络：

Aborted_clients 由于客户没有正确关闭连接已经死掉，已经放弃的连接数量。

Aborted_connects 尝试已经失败的MySQL服务器的连接的次数。

Connections 试图连接MySQL服务器的次数。

Created_tmp_tables 当执行语句时，已经被创造了的隐含临时表的数量。

Delayed_insert_threads 正在使用的延迟插入处理器线程的数量。

Delayed_writes 用INSERT DELAYED写入的行数。

Delayed_errors 用INSERT DELAYED写入的发生某些错误(可能重复键值)的行数。

Flush_commands 执行FLUSH命令的次数。

Handler_delete 请求从一张表中删除行的次数。

Handler_read_first 请求读入表中第一行的次数。

Handler_read_key 请求数字基于键读行。

Handler_read_next 请求读入基于一个键的一行的次数。

Handler_read_rnd 请求读入基于一个固定位置的一行的次数。

Handler_update 请求更新表中一行的次数。

Handler_write 请求向表中插入一行的次数。

Key_blocks_used 用于关键字缓存的块的数量。

Key_read_requests 请求从缓存读入一个键值的次数。

Key_reads 从磁盘物理读入一个键值的次数。

Key_write_requests 请求将一个关键字块写入缓存次数。

Key_writes 将一个键值块物理写入磁盘的次数。

Max_used_connections 同时使用的连接的最大数目。

Not_flushed_key_blocks 在键缓存中已经改变但是还没被清空到磁盘上的键块。

Not_flushed_delayed_rows 在INSERT DELAY队列中等待写入的行的数量。

Open_tables 打开表的数量。

Open_files 打开文件的数量。

Open_streams 打开流的数量(主要用于日志记载）

Opened_tables 已经打开的表的数量。

Questions 发往服务器的查询的数量。

Slow_queries 要花超过long_query_time时间的查询数量。

Threads_connected 当前打开的连接的数量。

Threads_running 不在睡眠的线程数量。

Uptime 服务器工作了多少秒。

ps，下面2个作业一直欠着没做，还是找时间做下实验吧：

1、水库模型：当前系统架构的承载能力？使用率（余量）？

2、水平扩展：读写分离（多主从）、集群、分库分表、NoSQL，这些解决方案分别的优劣势？

pps，待整理的一些观点，来自《ITPUB名人堂第38期:NoSQL专家王涛访谈》：

arron刘：
NoSQL技术纷繁复杂，各家大公司纷纷推出他们的大数据解决方案，开源的MongoDB、Redis、Memcached也纷纷登场，能给我们说说这些NoSQL技术的核心是什么？他们主要的差别在哪？
wangzhonnew：
实际上NoSQL里面也有很多不同的类型。一般来说我们把它分为四类，包括key/value，文档型，宽表，与graph。SequoiaDB的核心NoSQL引擎是文档型。graph的应用范围相对比较窄，用于描述实体之间的关系，我们在这里不多说。key/value，文档型和宽表，各有各的特点，和传统关系型数据库比起来也拥有各自的典型应用场景。
key/value，redis就是一个非常典型的keyvalue内存式数据库，它的用途主要就是在高性能访问的时候。但是一般来说key/value数据库因为数据模型简单，所以更多时候被看做是一个键值存储引擎，而不是拥有强大计算能力的数据库引擎。因此key/value数据库在简单的高性能数据模型的场景下很实用，但是当业务逻辑越来越复杂的时候就会凸显其劣势了。
宽表是google bigtable引领的潮流，本质就是把数据切成多个块（也叫做column family），存放在不同的地方。应用程序的典型用法，是根据某种条件找到记录后，只在里面搜索有限数量个字段，这样的话宽表能够有效地利用切分的数据块，尽可能减少I/O。宽表一般被用于拥有大量字段的场景，比如每条记录拥有成千上万的字段，用这种方式能够有效地减少I/O。不过大部分的应用可能都到不了这种规模。
最后，文档型数据库一般来说被认为是最接近传统关系型数据库的NoSQL。这也要归功于MongoDB所引领的潮流。文档型数据库的核心是数据嵌套，将原本一些星形模式（Star Schema）的数据嵌套在同一条记录中以减少表之间关联的需求。这种设计可以从某种程度上大大简化传统数据库复杂的关联问题，同时由于摆脱了关系模型里面的强一致性限制，文档型数据库还可以做到水平扩张与高可用。
所以我个人认为，相比其他几种NoSQL，文档型数据库的应用范围要广泛许多。

arron刘：
您现在一直专注NoSQL数据库的研发，如果作为使用者，NoSQL数据库性能优化方面与关系型数据库有什么区别？
wangzhonnew：
不管是传统关系型数据库，还是NoSQL，性能优化从两个方面入手。
第一，就是增加CPU的执行效率：这在关系型数据库里面最常见，比如说一个表扫描和一个索引扫描，为什么索引扫描块？大家可能说索引扫描只要扫描几个数据页就行了，表扫描要搜索全部数据啊。没错，不过这个是表象，真正的核心思想是，用最少的CPU找到你需要的数据。索引扫描可以在有限的CPU cycle里面就找到我们需要的数据，而表扫描需要扫描无数不需要的数据，最后才定位到若干条有效数据，从CPU的有效性来看差别显而易见。
第二，就是减少IO开销：为什么数据库需要缓存？为什么需要预取？为什么需要异步写？这些无数调优理念的背后只有一个答案，就是减少IO开销。缓存的使用把热数据放入内存，就不需要在访问数据时进行I/O读取了。预取可以把数据在访问前读入内存，也是减少IO的例子。异步写入可以在后台把脏数据刷入磁盘，腾出来的空间可以预读或者缓存更有效的数据。
所以，从性能优化的角度看起来，NoSQL与关系型数据库的理念基本没有区别。