背景：
开发的对外提供的下单接口，性能指标要求是 35tps 每秒，刚开始部署做性能测试的时候，由于数据没有数量量，100的并发请求下单，基本上能够达到 35 tps每秒；
平均请求处理在1秒左右；没有集群，当台服务器，但是当数据达到上万条的时候，tps直线下降到6 到 10 tps； 找测试人员问了下相关情况，说cpu都是OK的，使用率都才5%,个人也就没去看勒，直观的分析了下，问题可能在哪里；
1. 数据库的链接是否达标；
2. 怀疑有比较烂的sql导致查询过慢
3. 程序日志是否关闭
4. 数据库的IO读写问题
列出可疑点之后逐步排查；
查看是否开启慢查询 以及设置对应的日志目录
mysql> show variables like 'slow%';
+---------------------+---------------------------------+
| Variable_name | Value |
+---------------------+---------------------------------+
| slow_launch_time | 2 |
| slow_query_log | ON |
| slow_query_log_file | /var/lib/mysql/SUSE11b-slow.log |
+---------------------+---------------------------------+
3 rows in set (0.00 sec)
查看设置监控的日志sql执行时间
mysql> show variables like 'long%';
+-----------------+----------+
| Variable_name | Value |
+-----------------+----------+
| long_query_time | 1.000000 |
+-----------------+----------+
1 row in set (0.00 sec)
通过vi /etc/my.cnf 设置对应的值
long_query_time =1
slow_query_log =1
slow_query_log_file=/var/lib/mysql/SUSE11b-slow.log
max_connections=1000
设置完之后，找测试要来了对应的脚本启动并发测试；
[root@ZF_V2 ~]# tail -f /var/lib/mysql/SUSE11b-slow.log
# User@Host: root[root] @ [172.16.35.21]
# Query_time: 1.329723 Lock_time: 0.000063 Rows_sent: 1 Rows_examined: 56181
SET timestamp=1447670458;
SELECT COALESCE(SUM(MAX_USE_NUMBER-USED_NUMBER-INVALID_NUMBER), 0)
FROM S0113_S_COMMON_VOUCHER WHERE GOODS_ID = 10036;
# User@Host: root[root] @ [172.16.35.21]
# Query_time: 1.078350 Lock_time: 0.000036 Rows_sent: 1 Rows_examined: 56191
SET timestamp=1447670458;
SELECT COALESCE(SUM(MAX_USE_NUMBER-USED_NUMBER-INVALID_NUMBER), 0)
FROM S0113_S_COMMON_VOUCHER WHERE GOODS_ID = 10036;
发现原来是sql语句执行时间过长导致；停止性能测试，通过分析工具再次执行，同样的sql语句在并发的过长当中需要1s甚至2s,当时单独执行只需要100ms 甚至更少，然后在想是什么原因； 是不是工具有缓存导致？？只有可能，然后通过后台sql 命令直接连接执行对应的sql语句，还是非常快；思考为什么？？ 然后再次启动并发测试，执行同样的sql，速度突然慢了；？？？？百思不得其解， 突然一下子打了一个 top 命令，，我擦 。。。被坑了，，，cpu98%了。。。。。。。。。
定位来定位去，原来是mysq 服务器cpu过高导致，那么就在想，什么原因导致cpu过高了，问题还得解决； 今天先转测试吧，明天再继续来解决性能环境的性能问题；