多行业SQL审计落地总结近几年，几十个行业（包括银行、制造、保险等）的SQL审计项目已经落地实施的。在项目对接需求的过程中，直至后期验收，完成优化目标，有一些感悟和总结，本文将分享给大家。首先需要明确的是，SQL审计的范围是针对数据库层面的，涉及性能和安全风险SQL，而不是业务逻辑风险SQL（常见的如敏感信息查询、删除、变更等）.在应用场景上，主要有四个核心场景：生产环境优化特定业务，生产环境在业务高峰期降低CPU/IO，预生产（或测试）环境拦截低效SQL，开发环境减少非兼容SQL。生产场景优化在具体的业务实施案例中，以制造业为主。具体要求是对应的业务系统（OA、SAP、MES等）运行缓慢，优化验收目标比较简单。可加快实际业务运行，达到验收目标。这类优化大多比较简单，系统问题基本都是常见的优化问题，访问生产库时对主机基本没有限制。通过系统本身的优化建议报告，在建立索引和统计信息后，也方便验证，项目进度快。.项目难点在于完成业务操作与数据库中SQL的对应。通过业务的具体参数和结合ASH历史的模糊查询，完成定位。拿到SQL语句后，带入绑定变量，统计运行时间，与业务运行时间进行比较，确认优化后的SQL是否能达到预期的效果，然后进行优化。降低业务高峰期的CPU/IO该场景多对应于银行保险行业，具体需求是降低整个系统的CPU/IO负载。这种场景难度比较大（尤其是CPU），通常有以下难点：系统没有明显的TOPSQL，TOPONESQL占比（以DBTIME的百分比计算）小于4%；TOPSQL逻辑复杂，PLSQL有大量复杂逻辑；目标数据库对应多个业务系统，数据库JOB，操作系统CRONTAB设置了多个作业；业务情况复杂，一周中每天***0SQL变化很大。生产环境SQL审计基本流程以下流程适用于生产环境的两个主要场景：确认优化目标（优化降低CPU/IO）确认优化时间段；通过工具生成优化报告；在测试环境运行相关SQL语句，收集逻辑读取、运行时间等信息，执行优化报告中的建议，再次运行SQL，记录优化前后对比效果；提交有效的优化方案给开发确认，在开发层面评估变更是否合理（交付格式参考excel）；开发评估通过如果有UAT环境，可以在UAT环境下测试；如果没有UAT环境，可以直接上production；优化上线后，记录主机和数据库的相关指标，确认是否达到优化目标。非生产场景预生产环境拦截低效SQL该场景的用例有两个具体需求：分析SQL语句的合规性；找到有性能瓶颈需要语义重写的SQL。语句合规性比较简单（通过select*等静态规则；在没有实际过滤的情况下，连接条件；包括笛卡尔集等可以直接识别），而有性能瓶颈需要语义重写的SQL则被考虑非生产环境SQL审计的核心。由于无法自动确认SQL语句的执行频率和表的数据量，数据分布可能与实际情况有较大差异，所以这个阶段主要是找出那些需要重写的SQL来完成优化.很难解决这个问题。测试环境SQL审计流程图：功能测试完成后进行SQL审计测试，审计数据库为功能测试连接的数据库；审计报告在系统中生成，提交开发评估和修改；开发批量修改完成后，再次生成审计报告。重复上述过程，直到没有严重级别规则***。开发环境减少了不合规的SQL。这种场景主要在大型企业中遇到。实施主要基于培训，同时制定规范文件和静态审计（合规性）。强制执行后，更好地控制了开发源头的不良SQL，大大降低了测试后大规模返工的风险。开发环境SQL审计过程：开发者提取开发函数中的SQL语句；提交SQL文本生成静态审计报告；如果静态审计报告有问题，开发修改SQL文本后，重新生成静态审计报告，重复上述过程，直到Noseveritylevelrules***。SQL审计痛点海量审计结果在最早版本的SQL审计中，SQL审计的报告往往会列出大量的问题SQL。即使提高了规则的优先级，发现的问题SQL仍然太多，难以执行。经过一次次的功能调整和流程精简，我终于明白SQL审计的目的是为了发现问题和解决问题，而不是带来更多的问题。如果通过审计发现大量的SQL语句、表、索引等问题，以至于开发和DBA无法完全修复所有发现的问题，很可能在实施者眼中，有工具总比没有工具好。到头来还是工具跟流程脱节，走不下去。所以，在发现问题的层面上，其实还有一个看不见的条件，那就是还剩下多少开发时间？运维确认修复，转化为需求，需要动态圈定问题对象的范围。SQL审计的大部分场景，无论是上线前的性能验收，还是日常的优化计划，单次SQL审计的目标基本可以概括为：找到一定数量的可修复（甚至有修复建议）的问题，修复问题，得到直观的对比效果。在划分范围时，我们需要确定风险级别最高的规则对象（SQL、表、索引等）。这时候生产场景和非生产场景就有很大的区别了。在生产场景中，希望尽可能少的改动来达到预定的目标。非生产场景尽可能全面地识别潜在的高风险对象。UnobviousTopSQL在生产环境中审计SQL的一个常见场景是OLTP应用程序不使用绑定变量。在这种场景下，根据执行计划聚合SQL，或者根据`FORCE_MATCHING_SIGNATURE`聚合SQL，可能会达到一定的效果。但是，还有更复杂的场景。即使相关聚合完成后，也找不到比例高的TOPSQL。换个角度看问题，在SQL审计中，大部分时候我们审计的对象都是SQL语句。在处理SQL语句变体较多、相关性有一定相似性的场景时，这种视角比较弱。其实这个场景是切换到对象视角，即提取数据库中表的访问条件路径和访问条件，按照dbtime的比例排序，访问路径层面的优化需求可以是极大聚合，实现自动优化建议。SQL审计实施人员对初期生产环境的SQL审计能力要求很高。实施人员需要对SQL审计规则有深刻的理解，并能灵活运用优化后的技巧来完成SQL审计的全过程。这样一来，甲方父亲培养人员独立掌握这个过程的执行难度就比较大了。在我们的实践中，这个痛点也是有规定的。在讨论处理思路之前，我们先把问题按照是否涉及SQL重写分为两类：不需要重写（数据库级优化DBA-led）；需要重写（SQL语义层面优化需要开发配合）。需要重写的东西比较复杂。其实一般偏向AP的系统更多的是这种需求。不需要重写的SQL，其实统计优化方式后发现，占比最高的优化方式是访问路径层面的优化。说白了就是建立一个合适的索引。并且这种优化方式对SAP、ERP、DRM、HIS等偏TP的系统都有很好的优化效果。大多数类似的系统可能只能通过索引优化才能满足客户的优化期望。在这一部分，我们也通过自动化的优化建议降低了对实现者能力的要求，而改写部分仍然依赖于人工参与。这种细分场景还在自动化研究中。开发确认周期长。在目前实施的审计项目中，涉及开发确认的步骤普遍较慢。有时由于经常需要开发确认，项目周期大大延长。比如有些实现者习惯通过awr报告来重新确认SQL优化级别；或者你想按部就班，小批量、多次稳步投产，最终导致项目延期。这个需求也改变了我们对SQL审计的预期，即单次SQL审计需要有明确的预期效果才能实施。综上所述，各行各业的IT部门对SQL审计的需求越来越强烈，导致SQL审计细分场景众多，不同场景的侧重点也大不相同。自动优化建议结合人工测试/优化是我们目前主要的实现方式。通过审计规则准确识别风险是项目的技术关键。我们的知识库也在项目实施过程中不断得到验证和更新。我们将在以后有关规则的文章中讨论这些规则。
