关于关联查询sql的一次优化过程及其他
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了关于关联查询sql的一次优化过程及其他,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含4003字,纯文字阅读大概需要6分钟。
内容图文
![关于关联查询sql的一次优化过程及其他](/upload/InfoBanner/zyjiaocheng/560/a75781457cfb4d97910eb5a2b92e5bb3.jpg)
如前几次博文中所述,流程结束后的实例信息可以通过统一的入口即高级查询(可以导出excel,也预留了生成各种报表的接口)查询。但对于一些特殊的工作流,比如转
如前几次博文中所述,流程结束后的实例信息可以通过统一的入口即高级查询(可以导出excel,也预留了生成各种报表的接口)查询。但对于一些特殊的工作流,比如转正、离职、考勤等我们也提供了专门的查询模块。比如本文中所述的离职模块:离职模块共分三个部分,分别为离职信息新增、审批中离职、已结束离职三个子模块。离职信息新增功能主要是针对被动离职,也即单位劝退、辞退或单方面解除合同的离职信息新增,此类离职一旦保存即可认为是已结束离职,所以不像审批中离职查询逻辑中十分清晰,已结束离职需要关联多表进行查询。在测试系统中进行测试时,我们发现直接执行已结束离职查询sql,,在数据量为17条时,约1s,实际较慢,但尚可接受。该功能在正式系统上线后,离职数据约400条,用户简单在前端计时,约需十余秒等待,用户体验已经极差。拿出该查询sql,如下:
SELECT * FROM (SELECT DISTINCT leaveinfo.id, f_sqrgh, f_sqrbm, f_sqr, f_sqbmbm , f_sqbm, f_lxdhfj, f_sjhm, f_sqrq, f_rzrq , f_ndlzrq, f_qrlzrq, f_zw, f_gw, f_gwlx , f_gwcj, f_szdq, f_gzdd, f_lzyy, f_lzyyzs , f_yggxbmtjl, f_lzlx, f_inputtype, belongCompany, postDirection , techLevel, idCard, staffinfo.sex, staffinfo.birthday, exec.id AS 'processExecutionId' , exec.status AS 'processExecutionStatus', exec.formDefineId, exec.processDefineId, exec.processInstanceId, exec.tableName , process.`name` AS 'processDefineName' FROM T_DYMC_20140625100255 leaveinfo LEFT JOIN t_per_staffinfo staffinfo ON staffinfo.staffId = leaveinfo.f_sqrgh LEFT JOIN t_bpm_process_execution exec ON exec.pkValue = leaveinfo.id LEFT JOIN t_bpm_process_define process ON process.id = exec.processDefineId WHERE leaveinfo.f_sqrgh = staffinfo.staffId AND (exec.`status` = 2 AND leaveinfo.f_inputtype = 'FLOW' OR leaveinfo.f_inputtype = 'MANUAL') ) allData LEFT JOIN t_sys_user sysUser ON allData.f_sqrgh = sysUser.staffId这是一个分页查询,查询出所有结果的数量,如下:
SELECT COUNT(DISTINCT allData.id) FROM (SELECT DISTINCT leaveinfo.id, leaveinfo.f_sqrgh FROM T_DYMC_20140625100255 leaveinfo LEFT JOIN t_per_staffinfo staffinfo ON staffinfo.staffId = leaveinfo.f_sqrgh LEFT JOIN t_bpm_process_execution exec ON exec.pkValue = leaveinfo.id LEFT JOIN t_bpm_process_define process ON process.id = exec.processDefineId WHERE leaveinfo.f_sqrgh = staffinfo.staffId AND (exec.`status` = 2 AND leaveinfo.f_inputtype = 'FLOW' OR leaveinfo.f_inputtype = 'MANUAL') ) allData LEFT JOIN t_sys_user sysUser ON allData.f_sqrgh = sysUser.staffId
去掉这一关联,sql的效率有所改善,但改善并不明显。从逻辑角度我们已经没有优化的空间。所以希望从数据库技术角度去进行优化。在着手进行优化之前,我们先看一看当前语句已经使用的优化技术(对于非专业DBA首先可以想到的优化一般是index),而在mysql里提供了explain来查询mysql如何使用索引来处理select语句以及连接表。下面,我们看看在未优化之前,在该查询语句是不是有用优化技术,又使用了哪些优化技术。在未进行优化之前,我们已经有了针对档案和用户两张表的staffid的索引,查询索引的sql语句如下:
show index from t_per_staffinfo如下图:
查询语句中还有两张表分别为t_bpm_process_define和t_bpm_process_execution,我们为其创建索引,希望加入索引后查询效率有所改善:
ALTER TABLE t_bpm_process_execution ADD INDEX pkValue_index (pkValue);类似的我们为状态status,以及t_bpm_process_define也加入了索引。
现在我们用explain看看我们目前的查询语句,如下图:
内容总结
以上是互联网集市为您收集整理的关于关联查询sql的一次优化过程及其他全部内容,希望文章能够帮你解决关于关联查询sql的一次优化过程及其他所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。