今日给人查找数据,时间关系,写个比较粗暴的SQL语句:

 
#2s587ms
#直接将所有表关联,比较粗暴
select go.businessId,dd.dict_namefrom fn_xte.gte_order go,fn_config.t_dictionary_type dt,fn_config.t_dictionary_dict dd

where go.appId = dt.app_id and dt.data_key = dd.dict_type and dict_code = go.xingZhenQuYu and dt.data_key_name = 'XING_ZHENG_QU_YU'

此条语句对三个表进行关联,递归层次较深,产生的计算量就会很大,平均为X^3级别。然后根据where语句对关联的结果集进行筛选。耗时操作主要是在from子句中的三个表的联合操作。

所以用子查询对其进行优化为:

#487ms
#首先fn_xte.gte_order,fn_config.t_dictionary_type进行联合,fn_config.t_dictionary_type在后,作为驱动表,根据app_Id,在fn_xte.gte_orde进行查询,利用索引
select temp.businessId,dd.dict_name
from fn_config.t_dictionary_dict dd,(select go.businessId,go.xingZhenQuYu,dt.data_key
  from fn_xte.gte_order go,fn_config.t_dictionary_type dt
where dt.app_id = go.appId and dt.data_key_name = 'XING_ZHENG_QU_YU') as temp
where dd.dict_type = temp.data_key and dd.dict_code = temp.xingZhenQuYu;

进一步优化是关于from,where子句的执行顺序的,这里尚有疑问,待论证:

#405ms
#首先是fn_config.t_dictionary_type dt,fn_xte.gte_order go的联合,fn_xte.gte_order go在后作为驱动,其字段appId有索引,此处我认为索引并未有作用
#因为是根据appId查询其他表的,然而结果却表明时间消耗少了,
#可能原因是,表fn_config.t_dictionary_type由于数据太少,冲淡了fn_xte.gte_order索引带来的好处
explain select temp.businessId,dd.dict_name
from (select go.businessId,go.xingZhenQuYu,dt.data_key
 from fn_config.t_dictionary_type dt,fn_xte.gte_order go
where dt.data_key_name = 'XING_ZHENG_QU_YU' and dt.app_id = go.appId) as temp,fn_config.t_dictionary_dict dd
where dd.dict_code = temp.xingZhenQuYu and dd.dict_type = temp.data_key;

SQL优化:的更多相关文章

  1. SQL优化案例—— RowNumber分页

    将业务语句翻译成SQL语句不仅是一门技术,还是一门艺术. 下面拿我们程序开发工程师最常用的ROW_NUMBER()分页作为一个典型案例来说明. 先来看看我们最常见的分页的样子: WITH CTE AS ...

  2. sql 优化

    1.选择最有效率的表名顺序(只在基于规则的优化器中有效): oracle的解析器按照从右到左的顺序处理 from 子句中的表名,from子句中写在最后的表(基础表driving table)将被最先处 ...

  3. SQL 优化总结

    SQL 优化总结 (一)SQL Server 关键的内置表.视图 1. sysobjects         SELECT name as '函数名称',xtype as XType  FROM  s ...

  4. (转)SQL 优化原则

    一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出SQL语句各种写法的性能优劣,但是如果将应用 系统提交实际应用后,随着数据库中数据的增加,系 ...

  5. sql优化阶段性总结以及反思

    Sql优化思路阶段性心得: 这段时间的优化做了好几个案例,其实有很多的类似点,都是好几张大表的相互连接,然后执行长达好几个小时,甚至都跑不出来. 自己差不多的思路就是Parallel full tab ...

  6. mysql sql优化实例

    mysql sql优化实例 优化前: pt-query-degist分析结果: # Query 3: 0.00 QPS, 0.00x concurrency, ID 0xDC6E62FA021C85B ...

  7. SQL优化技巧

    我们开发的大部分软件,其基本业务流程都是:采集数据→将数据存储到数据库中→根据业务需求查询相应数据→对数据进行处理→传给前台展示.对整个流程进行分析,可以发现软件大部分的操作时间消耗都花在了数据库相关 ...

  8. ORACLE常用SQL优化hint语句

    在SQL语句优化过程中,我们经常会用到hint,现总结一下在SQL优化过程中常见Oracle HINT的用法: 1. /*+ALL_ROWS*/ 表明对语句块选择基于开销的优化方法,并获得最佳吞吐量, ...

  9. SQL优化有偿服务

    本人目前经营MySQL数据库的SQL优化服务,100块钱一条.具体操作模式 其中第一条,可以通过在微信朋友圈转发链接中的信息(http://www.yougemysqldba.com/discuz/v ...

  10. 【MySQL】SQL优化系列之 in与range 查询

    首先我们来说下in()这种方式的查询 在<高性能MySQL>里面提及用in这种方式可以有效的替代一定的range查询,提升查询效率,因为在一条索引里面,range字段后面的部分是不生效的. ...

随机推荐

  1. 网络助手之NABCD

    Sunny--Code团队:刘中睿,杜晓松,郑成       我们小组这次做的软件名字叫为校园网络助手.它主要有着两项功能:网络助手与校内网盘.          N--need:在学校里有时候我们就 ...

  2. beat冲刺(7/7)

    目录 摘要 团队部分 个人部分 摘要 队名:小白吃 组长博客:hjj 作业博客:beta冲刺(7/7) 后敬甲(组长) 过去两天完成了哪些任务 ppt制作 视频拍摄 接下来的计划 准备答辩 还剩下哪些 ...

  3. 搭建zabbix详细步骤

    关闭selinux和防火墙 selinux关闭: 1 命令查看出selinux的状态sestatus -v2 临时关闭 selinuxsetenforce 03 永久关闭selinuxvi /etc/ ...

  4. PAT 1024 科学计数法

    https://pintia.cn/problem-sets/994805260223102976/problems/994805297229447168 科学计数法是科学家用来表示很大或很小的数字的 ...

  5. HTTP压力测试工具wrk的安装及测试

    本次在VMware虚拟机的CentOS6.3系统中进行安装wrk压测工具,具体如下: 一.预先安装需求项 为了安装顺利,不受权限的限制,首先可以把用户切换为root用户# su + 输入root用户对 ...

  6. [转贴]systemd 编写服务管理脚本

    [转贴]sparkdev大神的博客, 关于 systemd的配置文件的 介绍, 自己之前二进制安装 k8s 时 超过一个 service文件 但是当时不明不白的. 现在再学习一下大神的文章 的确牛B ...

  7. sublimeText3的一些操作记录

    # 给绿色版的sublimeText3添加右键菜单,其中@=“Sublime Text 3” 是右键展示的文字, 后面的icon是图标将下面代码保存为.reg文件执行 Windows Registry ...

  8. div内元素的居中

    1.如果是一行文字(不超过一行) parent{ text-align:center; line-height:div高度; } 2.如果是div内其他类型元素 parent{ height:xxxp ...

  9. python mysql开发日志

    开始做python 的数据库访问了,暂时选定了mysql数据库.原本想使用ORM,后来考虑到项目的情况是:表结构不复杂,但是数据库非常大.还是自己来操作sql,不过PYTHON的那些数据库ORM的代码 ...

  10. vi写完文件保存时才发现是readonly😂

    在MAC上编辑apache配置文件,老是忘记sudo…… readonly的文件保存时提示 add ! to override, 但这仅是对root来说的啊! 百毒了一下竟然还有解决方案!! :w ! ...