在线php接口调试,接口调试：在线sql语句查看与性能优化

后台接口绝大数情况下，都需要与数据库进行交互，以获取业务数据或者接收保存客户端上报的数据。为方便后台开发同学进行调试，以及实时查看全部执行的SQL语句，这里简单地对全部执行的SQL语句进行调试模式下输出。

2.13.1 开启SQL调试

开启调试模式很简单，但这里和通常的框架不一样，我们不是全部统一地开启调试模式，因为在接口正常调用情况下返回非法的JSON会导致接口结果解析失败。故我们通过添加调试参数来控制是否开启SQL调试。如下：

//$vim ./Public/init.php //数据操作 - 基于NotORM DI()->notorm = function(){ $debug = isset($_GET['debug']) ? true : false; return new PhalApi_DB_NotORM(DI()->config->get('dbs'), $debug); };

特别注意： 通常，我们的调试参数不应都简单地使用&debug=1，而是各自定义，如复杂一点：&__phalapi_debug__=1，或者再添加一个简单的验签，额外带个参数校验，如：&phalapisign__=202cb962ac59075b964b07152d234b70。减少暴露SQL的风险。

2.13.2 调试示例

回到前面获取用户基本信息接口 /demo/?service=User.GetBaseInfo 的示例。

(1)正常情况下

请求：

http://dev.phalapi.com/demo/?service=User.GetBaseInfo&user_id=1

返回：

{"ret":200,"data":{"code":0,"msg":"","info":{"id":"1","name":"dogstar","note":"oschina"}},"msg":""}

(2)带&debug=1调试下

请求：

http://dev.phalapi.com/demo/?service=User.GetBaseInfo&user_id=1&debug=1

返回：

[1 - 0.00057s]SELECT * FROM tbl_user WHERE (id = ?); -- 1 {"ret":200,"data":{"code":0,"msg":"","info":{"id":"1","name":"dogstar","note":"oschina"}},"msg":""}

2.13.3 一个错误的接口开发

有时，在进行接口开发时，会需要进行批量获取的功能，如列表。但很多开发的同学可能会因为时间赶或者没有意识去对SQL查询进行优化，或者甚至不知道自己的接口背后隐藏着多少问题。下面是一个错误的开发示例。

(1)新增的批量获取接口

假设我们在开发一个国际的项目，并且运行良好，BOSS说因业务需要，要加多一个接口以支持批量获取用户的基本信息，提供给国外某知名的社交平台调用。

于是乎，我们很快就根据原来的单个获取接口实现了新的接口：

//$vim ./Demo/Api/User.php <?php class Api_User extends PhalApi_Api{ public function getRules(){ return array( //... 'getMultiBaseInfo' => array( 'user_ids' => array('name' => 'user_ids', 'type' => 'array', 'format' => 'explode', 'require' => true), ), ); } //... public function getMultiBaseInfo(){ $rs = array('code' => 0, 'msg' => '', 'list' => array()); $domain = new Domain_User(); foreach ($this->user_ids as $userId) { $rs['list'][] = $domain->getBaseInfo($userId); } return $rs; } }

(2)运行调用一下

显然，我们可以很清楚地调用新增的接口：

http://dev.phalapi.com/demo/?service=User.GetMultiBaseInfo&user_ids=1,2,3

可返回：

{ "ret": 200, "data": { "code": 0, "msg": "", "list": [ { "id": "1", "name": "dogstar", "note": "oschina" }, { "id": "2", "name": "Tom", "note": "USA" }, { "id": "3", "name": "King", "note": "game" } ] }, "msg": "" }

假设我们已经有了这样的数据库表数据：

INSERT INTO `tbl_user` VALUES ('1', 'dogstar', 'oschina'); INSERT INTO `tbl_user` VALUES ('2', 'Tom', 'USA'); INSERT INTO `tbl_user` VALUES ('3', 'King', 'game');

(3)这样的问题？

这样的问题，在对外黑盒调用的客户端同学是发现不了的，对于测试人员来说也是无法感知的。但所犯的错误也是显然易见的，就是没有进行SQL的批量查询优化，造成了很多不必要的重复查询。

这里，根据后台接口开发人员提供的调试参数(假设为：&debug=1)，则我们可以快速发现存在的问题：

http://dev.phalapi.com/demo/?service=User.GetMultiBaseInfo&user_ids=1,2,3&debug=1

如下返回，我们看到了很多重复类似的查询语句。

[1 - 0.0005s]SELECT * FROM tbl_user WHERE (id = ?); -- 1 [2 - 0.00042s]SELECT * FROM tbl_user WHERE (id = ?); -- 2 [3 - 0.00038s]SELECT * FROM tbl_user WHERE (id = ?); -- 3 {"ret":200,"data":{"code":0,"msg":"","list":[{"id":"1","name":"dogstar","note":"oschina"},{"id":"2","name":"Tom","note":"USA"},{"id":"3","name":"King","note":"game"}]},"msg":""}

上面输出的调试信息，简单补充一个格式：

[序号 - 所耗时间]SQl语句 -- [参数1, 参数2]

(4)如何改进？

这是一个很基本的问题，当然在实际项目中不会普通存在，这里只是作为一个示例加以说明。但让人失望的是，实际项目确实存在为数不少的这样的情况。可能是新人的技术和意识问题，也有可能是老同学的态度问题。所以，优化这么一个接口的批量SQL查询不难，难的是如何才能让新、老同学都注重这块的SQL查询优化呢？而不是等到线上服务器异常崩溃后再来推托责任。

具体的代码改进，留给读者自己实践了。毕竟，看了，实践了，才会真正深刻地掌握。

2.13.4 由此引申

这里不专门讲述SQL的优化，但也顺便提供一些SQL查询优化的建议：

使用批量查询，而不是N次循环查询！

重复的数据，不要重复获取；

根据需要，按需要获取表字段，而不是SELECT *；

针对频繁的搜索字段，建立必要的索引，以加快查询速度；

使用关联查询，而不是粗暴地类似：where uid IN (… 这里是成千上W个用户ID …)；

针对单条SQL语句执行时间超过1秒的，重点优化；

2.13.5 最后最后

奉上我们坚持TDD开发下的单元测试代码：

public function testGetMultiBaseInfo(){ $str = 'service=User.GetMultiBaseInfo&user_ids=1,2,3'; parse_str($str, $params); DI()->request = new PhalApi_Request($params); $api = new Api_User(); //自己进行初始化 $api->init(); $rs = $api->getMultiBaseInfo(); $this->assertNotEmpty($rs); $this->assertArrayHasKey('code', $rs); $this->assertArrayHasKey('msg', $rs); $this->assertArrayHasKey('list', $rs); foreach ($rs['list'] as $item) { $this->assertArrayHasKey('id', $item); $this->assertArrayHasKey('name', $item); $this->assertArrayHasKey('note', $item); } }

执行单元测试的效果：

dogstar@ubuntu:Tests$ phpunit --filter testGetMultiBaseInfo ./Api/Api_User_Test.php PHPUnit 4.3.4 by Sebastian Bergmann. . Time: 23 ms, Memory: 6.25Mb OK (1 test, 13 assertions)

搞定，收工，开饭！