1.场景一
腾讯调用我方接口进行url封禁和查询，并发要求50qps，测试同学使用jmeter压测时发现，查询封禁信息接口，构造20个并发后，发现查询响应变慢（>2000ms）,导致再高的并发压不上去不满足客户需求。
2. 问题分析
通过查询日志，定位到该条sql语句耗时较长,通过explain分析该sql语句的执行计划:
explain select * from forbidden_info where guid ='5af50517-f11a-4370-9ca6-03aa61d39b37'
未优化前执行计划.png
下面来分析执行计划：
| 执行项 | 具体值 | 描述 |
|---|---|---|
| select_type | SIMPLE | 是一个简单查询没有关联或者子查询 |
| table | forbidden_info | 表名 |
| type | ALL | 全表扫描 |
| extra | using where | 未找到索引使用where条件过滤 |
通过以上执行计划分析发现该查询没有使用到索引，导致查询效率低。给guid添加索引后：alter table forbidden_info add index index_guid(guid); 查看执行计划
添加索引后的执行计划.png
| 执行项 | 具体值 | 描述 |
|---|---|---|
| select_type | SIMPLE | 是一个简单查询没有关联或者子查询 |
| table | forbidden_info | 表名 |
| type | ref | 命中了非主键索引 |
| possible_keys | index_guid | 可能使用到的索引 |
| key | index_guid | 实际使用到的索引 |
| key_length | 603 | 表示索引使用的字节数 |
| ref | const | 表示索引使用的字节数 |
| rows | 10 | 数据库认为需要检查的行数，估算值，非结果行数 |
| extra | using index condition | 使用了ICP索引下推技术 |
添加索引后，查询耗时基本在毫秒级，整个接口的响应从2000ms下降到200ms左右
