系统数据库SQL优化之我见

        很多做系统开发编码的程序员会面临这些困惑，在开发系统时只是为了赶进度先实现功能，上线前期数据量少没有发现异常，但是上线运行一段时间后会发现系统某些功能查询越来越慢，甚至卡死或页面假死，更有严重者导致系统崩溃。最终导致整个项目黄掉或者客户不满意不验收的问题。

        近几年做了一些项目，发现很多系统都面临这类上线后系统随着数据规模的增大导致系统卡顿问题，也踩过不少坑。

        数据库SQL优化很多人认为是DBA的事，上线之后动不动会摔锅给DBA。

        系统数据库SQL优化原则：提前规划，业务设计规避复杂SQL，SQL语句规范合理，熟悉数据库的语言特性和语句使用局限性。

         具体可以分为几个阶段：

          一、事前做好数据库设计和规划，系统上线前对数据量有预估或者对数据提前做数据压力测试验证。对关键性业务表设计时，最好有项目管理人员、系统开发人员、数据库管理人员对表的设计和关联进行分析，表的设计是否满足数据库设计原则(主外键设计是否合理、表字段是否符合范式要求、核心表的字段冗余设计等)进行评估。能从业务简化的表设计的，尽可能提前考虑表的各种业务场景会涉及的SQL复杂度，提前做分库分表规划，根据业务做好有效数据规模规划处理；

          二、开发编码阶段：开发前团队强调SQL语句的规范和做好代码审查。另外可以灌入大规模的模拟数据进行SQL性能测试，提前规避一些问题。避免不必要的多表关联、合理使用not in、in、like、or、order by等，避免多重嵌套查询，游标的使用也应谨慎。对存储过程熟悉的或者SQL语句尽量用变量进行编写。合理利用视图、临时表、定时器预先处理数据避免集中对大规模和历史全局数据的操作。

          三、上线后运行阶段：很多人进入一个项目或者一个公司都是接手维护已经上线的系统，就会面临要解决原有的问题。可以从业务场景先着手，考虑如何取所需的数据和预先处理一部分数据，减少对服务器的开销；如果无法从业务层面规避的，要分析SQL语句是否存在不必要的嵌套查询，使用in、not in、or、group by等是否合理。有的字段是否是必须的如果没有用可以精简掉。调试的SQL要进行执行性能分析，每次优化完要思考可否进一步优化。通过预先处理一部分数据或者索引、存储过程等手段是否能进一步优化。

         以上只是SQL语句的优化一点不成熟的想法，希望对大家有一点启发。