工作流引擎SQL优化？

工作流SQL如何优化？

     在工作流引擎系统开发中，往往会遇到各式各样的的系统瓶颈问题，下面罗列出几个常见的系性能瓶颈问题。 流程模型：因为工作流系统往往是基于BPM2.0标准，而BPM2.0标准，通常情况下有自身的一套标准XML格式及图形化展示图标。市面上开源的Java工作流引擎框架，比如Activiti5/Activiti6/Flowable采用的是Modeler设计器，该设计器使用JSON方式进行建模数据的保存，然后通过Java相关类将Json转换为标准的BPM2.0 XML。这个过程涉及到了数据的转换过程，因此也会造成一定的性能瓶颈问题。

      比如上述的几个开源Java工作流框架思路是Json转换为Java类，然后在根据对象的类转换为XML。一个模型的操作最终涉及到了两套解析逻辑，即JSON和XML的读写逻辑。为此盘古BPM工作流平台采用的是一步到位的做法，直接生成BPM2.0标准的XML。没有上述框架中来回转换的问题，相对而言性能会有所提升，且兼容市面上所有基于BPM2.0标准的工作流产品。

      工作流引擎API调用问题。因为不同的业务场景或者不同的系统，对于各种各样的API操作方式可能不太一样。因此对于不同的业务场景或者系统，虽然说都是在使用，但是优化点却不尽相同。这些不同场景的API,对应有不同的SQL语句，因此数据层面的优化在于如何提升SQL的执行时间和效率，能批量查询的场景尽量不要循环读库进行查询，能缓存的数据就尽量缓存。

      因此对于每一个操作SQL的监控也是非常有必要的。如果每一个环节所涉及到的SQL操作和语句都没法监控，数据层面的优化也无从谈起。最终的结果就是看起来好像不快，但具体没什么不快不太清楚。

      为此盘古BPM工作流平台特意设计了每一个操作细节的SQL监控，这些监控的SQL涉及到工作流引擎中每一个环节的操作，比如数据的查询、删除和更新。每一个操作环节的SQL语句、对应MyBatis映射文件的位置、唯一标识、耗时时间都可以监控到。这样用户在使用盘古BPM工作流平台的时候，就可以全访问的跟踪这些数据，对于比较耗时的SQL一目了然，尽最大可能去优化。

      上述只能解决每一个SQL该如何优化的点，但是不能精确到每一个API操作所涉及到的SQL语句优化问题，因为一个操作可能会进行多次查询和更新操作。虽然每一个SQL语句都可以尽可能的优化，但是没法避免如何在调用层进行优化，比如有一个操作涉及到5条SQL,每一个SQL都可以优化，但是如果可以将5条SQL变成3条甚至更少，则效果会更加的明显。

       因此盘古BPM工作流平台发明了批次号的概念，每一个操作都对应一个唯一的标识，该标识下面的SQL语句都会聚合到一起，这样优化起来会更加的细致和精准，我们可以通过每一条SQL语句进行精准化的数据优化，也可以优化调用方的逻辑操作。

      对于引擎所产生的SQL语句，盘古BPM工作流平台支持将这些数据转发到数据库存储、日志方式存储、JMS方式通知、elasticsearch等多种方式，默认是数据库方式存储，关于其他的几种方式，用户直接配置即可，或者直接书写自己的一个实现类进行二次开发即可。 接下来，看一下怎么在系统中使用该功能，首先打开“工作”，点击“流程管理”，再次点击“ 引擎Sql监控”菜单，在这一个功能面板中，我们就可以查询到所有工作流引擎所对数据库的一些操作明细，如下图所示。

• SQL：每一个操作明细都会对应到这里。直接使用Mysql客户端执行即可
• SqlId:对应MyBtais中的唯一操作号
• 资源文件：该sql语句在MyBatis映射文件的位置，直接定位然后找到该文件即可。
• 唯一标识：与SqlId一致。
• 耗时：毫秒级别的。