13518219792
本期我们用 MySQL 提供的 DBUG 工具来研究 MySQL 的 SQL 处理流程。
成都创新互联专注于沅江网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供沅江营销型网站建设，沅江网站制作、沅江网页设计、沅江网站官网定制、成都微信小程序服务，打造沅江网络公司原创品牌,更为您提供沅江网站排名全网营销落地服务。
起手先造个实例
这里得稍微改一下实例的启动文件 start，将 CUSTOM_MYSQLD 改为 mysqld-debug：
重启一下实例，加上 debug 参数：
我们来做一两个实验，说明 DBUG 包的作用：
先设置一个简单的调试规则，我们设置了两个调试选项：
d：开启各个调试点的输出
O,/tmp/mysqld.trace：将调试结果输出到指定文件
请点击输入图片描述
然后我们创建了一张表，来看一下调试的输出结果：
请点击输入图片描述
可以看到 create table 的过程中，MySQL 的一些细节操作，比如分配内存 alloc_root 等
这样看还不够直观，我们增加一些信息：
请点击输入图片描述
来看看效果：
请点击输入图片描述
可以看到输出变成了调用树的形式，现在就可以分辨出 alloc_root 分配的内存，是为了解析 SQL 时用的（mysql_parse）
我们再增加一些有用的信息：
请点击输入图片描述
可以看到结果中增加了文件名和行号：
请点击输入图片描述
现在我们可以在输出中找一下统计表相关的信息：
请点击输入图片描述
可以看到 MySQL 在这里非常机智，直接执行了一个内置的存储过程来更新统计表。
沿着 que_eval_sql，可以找到其他类似的统计表，比如下面这些：
请点击输入图片描述
请点击输入图片描述
本次实验中，我们借助了 MySQL 的 DBUG 包，来让 MySQL 将处理过程暴露出来。MySQL 中类似的技术还有不少，比如 performance_schema，OPTIMIZER_TRACE 等等。
这些技术将 MySQL 的不同方向的信息暴露出来，方便大家理解其中机制。
命令： show processlist;
如果是root帐号，你能看到所有用户的当前连接。如果是其它普通帐号，只能看到自己占用的连接。
show processlist;只列出前100条，如果想全列出请使用show full processlist;
mysql show processlist;
命令： show status;
命令：show status like '%下面变量%';
Aborted_clients 由于客户没有正确关闭连接已经死掉，已经放弃的连接数量。
一，获取mysql用户下的进程总数
ps -ef | awk '{print $1}' | grep "mysql" | grep -v "grep" | wc-1
二，主机性能状态
# uptime
[root@ ~]# uptime
13:05:52 up 53 days, 52 min, 1 user, load average: 0.00, 0.00, 0.00
三，CPU使用率
# top
或
# vmstat
四，磁盘IO量
# vmstat 或 # iostat
五，swap进出量[内存]
# free
六，数据库性能状态
(1)QPS(每秒Query量)
QPS = Questions(or Queries) / seconds
mysql show /*50000 global */ status like 'Question';
(2)TPS(每秒事务量)
TPS = (Com_commit + Com_rollback) / seconds
mysql show status like 'Com_commit';
mysql show status like 'Com_rollback';
(3)key Buffer 命中率
key_buffer_read_hits = (1-key_reads / key_read_requests) * 100%
key_buffer_write_hits = (1-key_writes / key_write_requests) * 100%
mysql show status like 'Key%';
(4)InnoDB Buffer命中率
innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) * 100%
mysql show status like 'innodb_buffer_pool_read%';
(5)Query Cache命中率
Query_cache_hits = (Qcahce_hits / (Qcache_hits + Qcache_inserts )) * 100%;
mysql show status like 'Qcache%';
(6)Table Cache状态量
mysql show status like 'open%';
(7)Thread Cache 命中率
Thread_cache_hits = (1 - Threads_created / connections ) * 100%
mysql show status like 'Thread%';
mysql show status like 'Connections';
(8)锁定状态
mysql show status like '%lock%';
(9)复制延时量
mysql show slave status
(10) Tmp Table 状况(临时表状况)
mysql show status like 'Create_tmp%';
(11) Binlog Cache 使用状况
mysql show status like 'Binlog_cache%';
(12) Innodb_log_waits 量
mysql show status like 'innodb_log_waits';
当然你也可以使用一下开源监控软件进行监控
一，RRDTool
二，Nagios
三，MRTG
四，Cacti
用 pt-table-checksum 时，会不会影响业务性能？
实验
实验开始前，给大家分享一个小经验：任何性能评估，不要相信别人的评测结果，要在自己的环境上测试，并（大概）知晓原理。
我们先建一对主从：
然后用 mysqlslap跑一个持续的压力：
开另外一个会话，将 master 上的 general log 打开：
然后通过 pt-table-checksum 进行一次比较：
查看 master 的 general log，由于 mysqlslap 的影响，general log 中有很多内容，我们找到与 pt-table-checksum 相关的线程：
将该线程的操作单独列出来：
操作比较多，我们一点一点来说明：
这里工具调小了 innodb 锁等待时间。使得之后的操作，只要在 innodb 上稍微有锁等待，就会马上放弃操作，对业务影响很小。
另外工具调小了 wait_timeout 时间，倒是没有特别的作用。
工具将隔离级别调整为了 RR 级别，事务的维护代价会比 RC 要高，不过后面我们会看到工具使用的每个事务都很小，加上之前提到 innodb 锁等待时间调到很小，对线上业务产生的成本比较小。
RR 级别是数据对比的基本要求。
工具通过一系列操作，了解表的概况。工具是一个数据块一个数据块进行校验，这里获取了第一个数据块的下边界。
接下来工具获取了下一个数据块的下边界，每个 SQL前都会 EXPLAIN 一下，看一下执行成本，非常小心翼翼。
之后工具获取了一个数据块的 checksum，这个数据块不大，如果跟业务流量有冲突，会马上出发 innodb 的锁超时，立刻退让。
以上是 pt-table-checksum 的一些设计，可以看到这几处都是精心维护了业务流量不受影响。
工具还设计了其他的一些机制保障业务流量，比如参数 --max-load 和 --pause-file 等，还有精心设计的数据块划分方法，索引选择方法等。大家根据自己的情况配合使用即可达到很好的效果。
总结
本期我们介绍了简单分析 pt-table-checksum 是否会影响业务流量，坊间会流传工具的各种参数建议或者不建议使用，算命的情况比较多，大家都可以用简单的实验来分析其中机制。
还是那个观点，性能测试不能相信道听途说，得通过实验去分析。
