189 8069 5689
偶是队长软件工程师|5691个满意答案2009-08-24两种简单的方法，一个是使用海量数据进行测试性能。一个是使用测试工具，比如mysqlslap等等等等。 追问： mysqlslap工具在网上看了，但不知道怎么用啊，能否告知一二？？？要下载这个工具吗？？ 回答： 你要是有MYSQL5系列的数据库，这个工具是自带的啊。如果没有，建议下载。 追问： 我是MySql５．１的啊，但还是没找到在哪儿啊？？？能否指点一下啊，谢谢！！！ 回答： 晕，你当成可视化的了？无语。你打开控制台，然后就可以执行测试的命令了。。。你可以参考下MYSQL的官方说明：dev.mysql.com/doc/refman/5.1/en/mysqlslap.html这个网上有很多的测试教程，你可以看看，不过不是特别实用。。。 追问： 我是应用程序的怎么用啊？？ 回答： 我看，你可能有点误解了压力测试了。第一，你的应用程序，是否是以数据为中心的，如果不是，那之前我和你说的那些全部就是废话。第二，就算是以数据为中心的，你也没说明白你要测试什么，如果你要测试MYSQL,那没什么必要。因为已经是很成熟的产品了。第三，如果是你要测试你的程序，而且你的程序拥有后台数据库，那你可以针对不同平台的解决方案，使用不同的测试方法，比如如果是.NET + MYSQL数据库 ，就可以使用VS自带的测试工具，连同代码，和数据访问都可以进行测试。如果你是专业的软件测试人员，可以使用黑盒，白盒两种方式分别测试，不做赘述。
成都创新互联服务项目包括延吉网站建设、延吉网站制作、延吉网页制作以及延吉网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，延吉网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到延吉省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
我们先来看第一个阶段，MySQL慢的诊断思路，一般我们会从三个方向来做：
第一个方向是MySQL内部的观测
第二个方向是外部资源的观测
第三个方向是外部需求的改造
1.1 MySQL 内部观测
我们来看MySQL内部的观测，常用的观测手段是这样的，从上往下看，第一部分是Processlist，看一下哪个SQL压力不太正常，第二步是explain，解释一下它的执行计划，第三步我们要做Profilling，如果这个SQL能再执行一次的话, 就做一个Profilling，然后高级的DBA会直接动用performance_schema ，MySQL 5.7 以后直接动用sys_schema，sys_schema是一个视图，里面有便捷的各类信息，帮助大家来诊断性能。再高级一点，我们会动用innodb_metrics进行一个对引擎的诊断。
除了这些手段以外，大家还提出了一些乱七八糟的手段，我就不列在这了，这些是常规的一个MySQL的内部的状态观测的思路。除了这些以外，MySQL还陆陆续续提供了一些暴露自己状态的方案，但是这些方案并没有在实践中形成套路，原因是学习成本比较高。
1.2 外部资源观测
外部资源观测这部分，我引用了一篇文章，这篇文章的二维码我贴在上面了。这篇文章是国外的一个神写的，标题是：60秒的快速巡检，我们来看一下它在60秒之内对服务器到底做了一个什么样的巡检。一共十条命令，这是前五条，我们一条一条来看。
1.uptime，uptime告诉我们这个机器活了多久，以及它的平均的负载是多少。
2.dmesg -T | tail，告诉我们系统日志里边有没有什么报错。
3.vmstat 1，告诉我们虚拟内存的状态，页的换进换出有没有问题，swap有没有使用。
4. mpstat -P ALL，告诉我们CPU压力在各个核上是不是均匀的。
5.pidstat 1，告诉我们各个进程的对资源的占用大概是什么样子。
我们来看一下后五条：
首先是iostat-xz 1，查看IO的问题，然后是free-m内存使用率，之后两个sar，按设备网卡设备的维度，看一下网络的消耗状态，以及总体看TCP的使用率和错误率是多少。最后一条命令top，看一下大概的进程和线程的问题。
这个就是对于外部资源的诊断，这十条命令揭示了应该去诊断哪些外部资源。
1.3 外部需求改造
第三个诊断思路是外部的需求改造，我在这里引用了一篇文档，这篇文档是MySQL的官方文档中的一章，这一章叫Examples of Common Queries，文档中介绍了常规的SQL怎么写, 给出了一些例子。文章的链接二维码在slide上。
我们来看一下它其中提到的一个例子。
它做的事情是从一个表里边去选取，这张表有三列，article、dealer、price，选取每个作者的最贵的商品列在结果集中，这是它的最原始的SQL，非常符合业务的写法，但是它是个关联子查询。
关联子查询成本是很贵的，所以上面的文档会教你快速地把它转成一个非关联子查询，大家可以看到中间的子查询和外边的查询之间是没有关联性的。
第三步，会教大家直接把子查询拿掉，然后转成这样一个SQL，这个就叫业务改造，前后三个SQL的成本都不一样，把关联子查询拆掉的成本，拆掉以后SQL会跑得非常好，但这个SQL已经不能良好表义了，只有在诊断到SQL成本比较高的情况下才建议大家使用这种方式。
为什么它能够把一个关联子查询拆掉呢？
这背后的原理是关系代数，所有的SQL都可以被表达成等价的关系代数式，关系代数式之间有等价关系，这个等价关系通过变换可以把关联子查询拆掉。
上面的这篇文档是一个大学的教材，它从头教了关于代数和SQL之间的关系。然后一步步推导怎么去简化这句SQL。
第一，MySQL本身提供了很多命令来观察MySQL自身的各类状态，大家从上往下检一般能检到SQL的问题或者服务器的问题。
第二，从服务器的角度，我们从巡检的脚本角度入手，服务器的资源就这几种，观测手法也就那么几种，我们把服务器的资源全部都观察一圈就可以了。
第三，如果实在搞不定，需求方一定要按照数据库容易接受的方式去写SQL，这个成本会下降的非常快，这个是常规的MySQL慢的诊断思路。
通过sysbench的oltp_read_write测试来模拟业务压力、以此来给指定的硬件环境配置一份比较合理的MySQL配置文件。
环境介绍
硬件配置
请点击输入图片描述
软件环境
请点击输入图片描述
优化层级与指导思想
优化层级
MySQL数据库优化可以在多个不同的层级进行，常见的有：
SQL优化
参数优化
架构优化
本文重点关注：参数优化
指导思想
日志先行 -- 一个事务能否成功提交的关键是日志是否成功落盘，与数据没有太大的关系；也就是说对写的优化可以表述为各方面的资源向写操作倾斜。
瓶颈分析 -- 通过show global status 的各个计数器的值基本上就能分析出当前瓶颈所在，再结合一些简单的系统层面的监控工具如top iostat 就能明确瓶颈。
整体性能是“读”“写”之间的再平衡。
1. MySQL处在高负载环境下，磁盘IO读写过多，肯定会占用很多资源，必然会CPU占用过高，所以可以用top命令查看MySQL所在服务器的cpu使用情况，从而分析是否有瓶颈；
2. show processlist查看MySQL当前的执行状态，查看是否有大量的Sleep或Locked状态；