mysql 性能飙升2000%，论关联查询索引的重要性

事件单号INC000000726762，智能空调NB-IOT 业务系统（ xx.xxx.xxx.xx ），现出现告警，生成事件单。
工单号： IM102_5197739
监控级别: MINOR
告警类型: Linux
IP: xx.xxx.xxx.xx
模块名称： 监控系统-东软
标题： Linux-xx.xxx.xxx.xx -goodairdbm1-MINOR
告警信息： CPU % CPU Utilization > 80% for 15 min.,当前值:100.00
告警对象： CPU+"
上面提示公司服务器xx.xxx.xxx.xx CPU >80%,通过公司跳板机登录对应服务器：xx.xxx.xxx.xx

free -m #内存正常
top # 因为xx.xxx.xxx.xx 只部署了mysql服务器，显示CPU百分比为2396%，服务器的核数为24核

执行完top命令吓了一跳，虽然是24核，但是cpu那么高着实吓人。
那就看下是否有查询阻塞

show full PROCESSLIST

查看state以及info 找出对应执行阻塞的sql语句，拿出来到对应的库执行

EXPLAIN
SELECT d.mac imei,
               p.prod_code prodCode,
               IFNULL(u.third_party_user_id,'') uagSuperUserId,
               IFNULL(d.u_plus_device_id,'') uPlusDeviceId
        FROM device_info d
             LEFT JOIN product_info p ON d.prod_id = p.id
             LEFT JOIN device_group g ON d.group_id = g.id
             LEFT JOIN user u ON g.super_user = u.user_id
        WHERE d.id = '195877'
        LIMIT 0,1
    *********************************************************************
    SELECT count(*) from device_info # 104942条
	SELECT count(*) from device_group #71605 条   

发现用户表的数据是340多万，而且执行的全表扫描，其他的表都是正常，所以就定位到这个用户表

全表查询执行时间大约175秒，因为上表是三个表关联查询，而且用到用户表的user_id字段作为关联查询条件，果断查看用户表的user_id字段是否建立索引，结果真是没有索引导致的，然后给该用户表
user_id字段建立索引，navicat 里面增加 user_id_index ，索引方法BTREE

third_party_user_id_index	third_party_user_id	Normal	BTREE
user_id_index	user_id	Normal	BTREE

然后返回服务器使用top查看当前mysql的cpu的百分比，降到了150%左右，大功告成，成功解决问题，同时也说明了sql语句以及索引的重要性