1. 系统日志概览
系统日志为系统内置的日志记录，分别有四个记录表：SYS_请求日志、SYS_业务公式日志、SYS_业务公式情况日志、系统日志。
进入系统日志的路径如下图所示：【系统管理】-【系统服务】-【系统日志】
系统日志路径
2. 系统日志详解
2.1 SYS_请求日志
说明：SYS_请求日志是用于记录浏览器发送给后端的请求，包括保存表单与查询接口等等请求。
包含信息：请求日志会记录请求url、请求方法、模板名称、时间、时长、操作账号与内容。
用途：用于追踪用户操作触发了哪些后端请求，是问题排查的入口。 当用户反映某个功能无响应、保存失败或数据未刷新时，首先查看请求日志，确认请求是否到达服务器、请求时长是否异常、以及具体操作人是谁。它是整条日志链的起点，选中某条请求后，可向下钻取关联的业务公式执行情况。
扩展：选中请求日志，会关联显示业务公式日志。
2.2 SYS_业务公式日志
说明：SYS_业务公式日志是用于记录执行业务公式的日志，包括自己设计的业务公式与系统内置的业务公式（如：请求模板编辑锁）。
包含信息：业务公式日志会记录修改目标、业务公式名称、模板名称、时间（开始与结束时间、执行时长、数据库连接数量、业务公式情况执行数量、操作账号与内容。
用途：用于监控业务公式的执行性能和调用链路。 当系统响应变慢或某个自动计算/更新未生效时，通过业务公式日志可快速定位是哪个公式耗时过长、连接数过高，或是否被正常触发。它承接请求日志，将一次请求拆解为具体的公式执行记录，并关联下钻到公式内部的具体执行情况。
扩展：选中业务公式日志，会关联显示业务公式情况日志。
业务公式日志示意
2.3 SYS_业务公式情况日志
说明：SYS_业务公式情况日志是用于记录执行业务公式情况的日志，主要是执行的业务公式下的情况的执行详情。
包含信息：业务公式情况日志用于记录执行业务公式的具体情况、修改目标、业务公式名称、模板名称、时间（开始与结束时间、执行时长）、数据库连接数量、业务公式执行情况数量、操作账号、内容。
用途：用于定位业务公式内部哪个具体操作出了异常。 一个业务公式可能包含多个情况（如"更新所有部门"和"更新上级部门编号"），当公式执行结果不符合预期时，通过情况日志可以精确到是哪个情况执行失败、报错信息是什么、执行了多长时间。它是排查业务逻辑错误的最终落脚点。
以上三者查询关联关系：SYS_请求日志→SYS_业务公式日志→SYS_业务公式情况日志
以图中的更新组织机构的业务公式为例：
首先可以在请求日志中，找到发送给服务器的请求，请求方法为总表状态按钮，在下方可以查看关联到的业务公式日志，触发的修改目标为：SYS_DEPARTMENT，业务公式名称为更新部门，触发的模板名称为组织机构辅助模板。
后面到SYS_业务公式日志中找到更新部门的日志，该日志显示了这个业务公式执行的总时长、总连接数以及总执行数量，且在下方关联显示该业务公式的情况明细。
最后到SYS_业务公式情况日志中找到对应的两条情况日志，情况日志中显示，更新部门的业务公式下有两情况，分别为更新所有部门与更新上级部门编号，详细记录了两个情况分别的执行详情。
总结：可以从请求日志开始，查询到执行了什么业务公式、连接数多少、耗时多长，以及该业务公式下具体执行了什么情况、是否正常结束。
2.4 系统日志
说明：系统日志主要用于记录用户的操作情况。
包含信息：系统日志记录了用户操作的操作模块、编号、用户操作、操作类型、账号、姓名、是否操作失败、操作失败详情、日志等级、操作IP与时间。
用途：用于审计用户的操作行为和系统安全监控。 与前三者跟踪请求-公式-执行的技术链路不同，系统日志聚焦于"谁在什么时间做了什么操作"，包括登录、数据增删改等。当需要追究误操作责任、检测异常登录或审计合规时，直接查询系统日志即可。操作失败时还会记录失败详情，便于追溯原因。
3. 业务公式日志使用举例
3.1 匹配条件恒等式导致局部异常
日志表现： 在 SYS_业务公式情况日志中，某一条情况的执行时间明显异常（比其它情况高出几个数量级），连接数也异常高，而其他情况的执行时间正常。
根因分析： 检查该情况的匹配条件，发现写成了
目标模板.数据项A = 目标模板.数据项A。这种写法等于 1=1，导致该情况对目标模板的全表数据全部更新一遍。数据量越大，这一条情况的耗时和连接数就越夸张。结论： 匹配条件必须写能精确限定数据行的条件，如
目标模板.单据编号 = 源模板.单据编号，避免使用恒等式。3.2 数据量过大且缺少索引导致整体执行缓慢
日志表现： 在 SYS_业务公式情况日志中，每条情况的执行时间和连接数看起来都比较正常，没有哪一条特别突出，但整个业务公式的执行总时长却非常长，超过 800,000 毫秒（即 80 秒以上）。
根因分析： 这种情况通常由以下原因引起：
- 匹配条件字段缺少索引：业务公式执行时需要根据匹配条件去目标模板中查找数据行，如果匹配条件涉及的字段没有建立索引，数据库就会做全表扫描。数据量越大，扫描越慢。
- 匹配条件过多：匹配条件写了多个字段的组合条件（如
A=1 AND B=2 AND C=3），但数据库无法有效利用索引，每条数据的查询都在逐行匹配。 - 数据源行数过大：业务公式的数据源取出了大量数据行（如数十万行），虽然每条数据的更新时间极短（毫秒级），但累加起来总时间就到了几十万毫秒。
每条情况本身执行并不慢，但因为需要处理的数据行太多或者每一行的查找速度太慢，积少成多，导致整体执行时间爆炸。
结论： 在目标模板中，为匹配条件常用的字段建立索引；精简匹配条件，保留必要字段即可；如果数据源行数过大，考虑增加过滤条件减少处理范围。
