点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！ 近期遇到一个由于ETL数据抽取SQL不规范致使CPU使用率居高不下，数据交互作业执行时间过长，进而引发学员在前台大量排队的投诉问题，现将整个排查过程做个记录。
客户反馈学员登记完信息之后，制卡系统需要1分钟以上才能同步到学员信息（正常不超过15秒），接到投诉后立马查看数据同步作业，发现执行时间确实出现异常情况：
登录后台管理系统也出现卡顿现象，由于系统采用的是模块化部署，不同的模块部署在不同的服务器上，其他模块页面打开都很快，只有数据同步模块的页面打开缓慢，初步怀疑是这台服务器出现了问题：
step1 登录对应的微服务服务器通过top命令查看资源使用情况，发现CUP负载过高step2 通过截图我们发现PID 11044的java进程占用的CPU过高，这个应用就不正常了，进一步查看该进程对应的线程信息（top -H -p 11044）step3 通过截图我们发现线程ID为 6924、6925占用cpu过高，把线程ID转为16进制（printf "0x%x\n" 6925）step4 使用jvm工具jstack查看具体的堆栈信息，将结果输出到log文件中，用于分析（ jstack 11044|grep 0x1b0d >thread_stack.log），查看日志信息step5 分析日志信息，提示java异常，异常信息提示抽取人员登记单的转换出现了问题，打开ETL工具kettle找到对应的表输入SQLstep6 SQL看着没有问题，在kettle中也能正确执行，复制SQL到客户端DataGrip中执行也没有问题；继续分析数据发现kettle中获取的数据量和DataGrip中获取的不一样1）以下是在kettle中执行的结果，一共是44757条结果2）以下是在客户端DataGrip中执行的结果，一共是256条结果同样的SQL在不同的客户端中执行得到了不同的结果，进一步分析发现kettle中获取的是全量数据，SQL中where后面的限制条件没有生效，经过一番搜索才找到问题的症结：在kettle中SQL中包含的注释在某些数据库中可能会导致注释之后的语句不会被执行，经过测试不同的数据库发现这个问题只会出现在BD2中。总 结：
经过此次问题追踪排查，虽然迅速的解决了问题，但是也引起了客户的投诉，问题本身比较简单，如果运维人员能够在写SQL的时候经过充分测试（虽然这个SQL很简单），或许就可以避免此类问题的发生。
