数十个SQL审核项目后，我总结出了这样一套经验

初期的生产环境的SQL审核对实施人员的要求较高，需要实施人员深入理解SQL审核规则，并能灵活应用优化的技能才能完成SQL审核的全流程，这样甲方爸爸想培养人员自主掌握这套流程的实施就相对困难。在我们的实践中，对这个痛点也开了处方。

在谈处理思路前，我们先通过是否涉及到SQL的改写将问题分为两个大类：

• 不需要改写(数据库层面优化DBA主导);
• 需要改写(SQL语义层面优化需开发配合)。

需要改写的相对较复杂，其实一般偏AP的系统更多是这种需求。不需要改写的SQL，其实在统计过优化手段后发现，占比最高的优化方式还是访问路径层面的优化，大白话就是建合适的索引。

而这种优化手段对于SAP、ERP、DRM、HIS等等偏TP的系统都有非常好的优化效果，大部分类似系统可能仅仅通过索引的优化就能达到客户的优化预期。

这部分，我们目前也已经通过自动化的优化建议降低了对实施人员能力的要求，而改写部分则依然依赖人工的参与，这种细分场景还在自动化攻关中。

开发确认周期长

目前实施的审核项目中，一般涉及开发确认的步骤都较慢，有时项目周期大幅拖长就是由于频繁需要开发确认，比如有的实施人员习惯通过awr报告，再次确认SQL优化级;或是希望分步走，少量多次稳步上生产，，最终导致项目的延期。这个需求也转换了我们对SQL审核的预期，也就是单次的SQL审核需要在实施前有个明确的收效预期。

总结

各行各业IT部门对SQL审核的需求日益旺盛，导致SQL审核细分场景较多，不同场景的关注重点差异也较大，自动优化建议配合人工测试/优化是我们目前落地的主要方式。通过审核的规则准确识别风险是项目的技术关键，我们的知识库也在项目落地中不断地校验更新，关于规则这块后期的文章中再做交流。

【编辑推荐】

1. 分库分表，读写分离后，数据库中间件扮演了一个怎样的角色？
2. 阿里巴巴数据库分库分表的实践
3. B+树 | MySQL索引使用原则
4. 大牛出招｜分分钟解决MySQL查询速度慢与性能差
5. 当数据库扼住系统性能咽喉，直接分库分表能解决吗？

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!