新的开始 -- SQL调优

序言

在之前的工作中，曾经主力关注于高并发系统和网络应用的开发，还有线上问题的排查。现如今的work，则是与海量数据打交道。所以，作为一个合格的工程师，必须对SQL调优有一个深刻的认识，如何写出性能更高的SQL，如何在问题出现的时候解决问题成了当务之急。

SQL调优被忽略的原因

在原有的工作中，我们也会对慢SQL进行排查，SQL优化对我们而言不过是 刷新INDEX，如果问题得到解决，万事大吉，问题得不到解决，直接寻求DBA接手该问题。这样的处理方式使得我们在SQL调优方面并没有多少经验，甚至错误的认为，SQL问题本不属于我们，只要移交DBA，一切问题都能迎刃而解。

开场：之前曾经遇到的问题的反思

之前曾致力于DATA OPS平台的开发和 DEV OPS平台开发，也曾给某些企业提供一些报表服务，正常情况下每天的 21:00 - 次日9:00 执行大量的作业生成前一天的业务报表，某天的x点，监控人员收到运维平台告警，原因是宕机（用户眼里的宕机）。我们去对接的时候，通过top命令查到了某个进程占用了大量的资源，kill之后无用。因为杀了之后还是会再次跑没有正常结束的任务。我们通过用户提供的日志，定位到一条SQL。得出结论：这是一直慢，而非偶发。当时我处理方式非常简单。1.SQL请用户、再跑一次，发现一直卡住，其实系统没事，对于用户而言，卡主了，就是宕机了。2.把SQL和日志移交DBA。3.结束这次性能排除。我只是简单的看了一下，并没有深入，当时觉得没有什么，现在看来，这是失职。导致了SQL调优的能力不足，现在对于我们自己要手动写SQL而言，这是致命的，这是对DBA和用户的一种折磨，因为我们不懂调优就没有办法写出好的SQL，因为我们不知道优化点在哪里，谈何写出好的SQL？

结束语

从今天开始，我将转头而去解决手头上现有的问题，SQL调优，至于netty部分，我会安排时间，可能是假期对其进行完结。我也会举一些例子，不管是现在的以前的还是网上看到的，对这一块的学习进行加深。