背景：一个接口比较慢，逻辑相对简单。
SQL截图如下，涉及一个insert，两个select和一个update，因为索引是有的，初步怀疑是update引起的性能问题，可能存在锁。
项目是PHP项目，代码改起来很方便，所以可以直接打印时间戳。在这里说下打印时间戳的方法，我都是先打印函数的主体，打印出来一个总时间，这个时间若是和jmeter的时间差不多的话再细化时间戳，打印具体的方法。如下：
方法体开始时打印：
方法体结束时打印：
这两个时间打印出来的total time就是整个方法的总时间，这里说一下，因为负责这个项目的开发经验不足，都不知道怎么把时间戳打印在日志里面，我也不太懂PHP，所以我就直接用echo打印在了返回结果里面，这块不影响测试结果，只是打印在日志里面方便统计。
现在用jmeter压测下看看结果：
总时间有一秒多，证明方法体内是有问题的，继续打印更细节的时间戳。
虽然代码有一百多行，但主体主要是这四行，其他主要是一些数据处理，判断等。
加完后继续压测看结果：
可以明显的看出来时间全在select time里面。看到这里，在结合刚刚的SQL就直接知道原因了，我在详细解释下。
这是日志打印的两个SQL，仔细看区别，差了个引号，不加引号默认int类型，但其实这个字段是varchar类型。Int类型的条件是走不到索引的，这也是常识。找到原因了就改下代码，加上引号，变成字符串类型，如下：
再压测下看看。
刚刚的问题没有了，总时间很快了，但是jmeter的时间依然有几百毫秒，不过这个结果至少可以证明代码层已经没问题了，如果继续优化要从框架层、nginx、日志打印、网络等接口调用前后的时间了，不够经验表明，ThinkPHP框架性能很差，昨天吃饭一个开发负责人和我说，之前的优化怎么都不行，换了ThinkPHP7，性能提升很多，框架的问题我们就管不了了，至于开发选用什么框架也不是我们测试能决定的，我们只负责优化到最优就足够了。
找到这个问题后，就直接和开发说改下代码，并说明原因，开发欣然接受并表示感谢。像这种问题，其实是很小的问题，但是带着问题上线后，后果也是很严重的，可以对比下上面的压测结果，这种问题交给我们性能测试组解决，可能半小时内就能定位到问题所在，但是如果我们只告诉开发这个接口慢，让他去优化，这个时间可就不好估计了，有经验的可能一眼找到问题所在，经验不足的可能会耗费很长时间，或者这也就是性能测试的价值所在。
作者：幻天行 出处：https://www.cnblogs.com/huantianxing/ 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。