浅谈mysql的子查询联合与in的效率

最近的产品测试发现一个问题，当并发数量小于10时，响应时间可以维持在100毫秒以内。但是当并发数到达30个时，响应时间就超过1秒。这太不能接受了，要求是通过1秒中并发100个。

经过检测发现，时间主要是耗在其中的一个存储过程中。把存储过程的语句一条一条的过一遍也没有发现明显的不合理。因为mysql本身不能提供毫秒级别的时间，google了一个mysql的能提供毫秒的时间函数，再做测试，做了一个定位。发现是其中一条语句，语句是这个样子：

 select .... from A, B where .....and A.id in (select id from C where ...);

in 子查询语句的结果很少，就几条。explain 这条语句，也没有什么问题。单条测试也没有问题。但是当并发数大时问题就出来了。

做了个改变：

 select ... from A,B,(select ... from C where ...) S where ....;

再做测试，性能大为改观。50个并发与10个并发几乎是相同的响应速度。

在mysql中，mysql可能都建议改成使用子查询的联合，而不用in。以前没有经过实验。现在终于看见其中的效率了。当然，也不能尽相信。还是得根据自己的应用来。最好是能做一些测试和实验。

总结

以上就是本文关于浅谈mysql的子查询联合与in的效率的全部内容，希望对大家有所帮助。

感兴趣的朋友可以参考：

几个比较重要的MySQL变量

MySQL主库binlog(master-log)与从库relay-log关系代码详解

mysql数据库开发规范【推荐】

有什么问题欢迎留言，大家一起交流讨论。在此也希望朋友们对我们网站多多支持！

赞 (0)

相关推荐

  • MySQL中使用or、in与union all在查询命令下的效率对比

    MySQL中使用or、in与union all在查询命令下的效率对比

    OR.in和union all 查询效率到底哪个快? 网上很多的声音都是说union all 快于 or.in,因为or.in会导致全表扫描,他们给出了很多的实例. 但真的union all真的快于or.in? EXPLAIN SELECT * from employees where employees.first_NAME ='Georgi' UNION ALL SELECT * from employees where employees.first_NAME ='Bezalel' 这条语

  • mysql not in、left join、IS NULL、NOT EXISTS 效率问题记录

    NOT IN.JOIN.IS NULL.NOT EXISTS效率对比 语句一:select count(*) from A where A.a not in (select a from B) 语句二:select count(*) from A left join B on A.a = B.a where B.a is null 语句三:select count(*) from A where not exists (select a from B where A.a = B.a) 知道以上三

  • MySQL利用profile分析慢sql详解（group left join效率高于子查询）

    使用profile来分析慢sql mysql 的 sql 性能分析器主要用途是显示 sql 执行的整个过程中各项资源的使用情况.分析器可以更好的展示出不良 SQL 的性能问题所在. 最近遇到一个查询比较慢的sql语句,用了子查询,大概需要0.8秒左右,这个消耗时间比较长,严重影响了性能,所以需要进行优化.单独查询单表或者子查询记录都很快,下面来看看详细的介绍. 开启profile mysql> show profiles; -- 查看是否开启 Empty set, 1 warning (0.00

  • 提高MySQL中InnoDB表BLOB列的存储效率的教程

    提高MySQL中InnoDB表BLOB列的存储效率的教程

    首先,介绍下关于InnoDB引擎存储格式的几个要点: 1.InnoDB可以选择使用共享表空间或者是独立表空间方式,建议使用独立表空间,便于管理.维护.启用 innodb_file_per_table 选项,5.5以后可以在线动态修改生效,并且执行 ALTER TABLE xx ENGINE = InnoDB 将现有表转成独立表空间,早于5.5的版本,修改完这个选项后,需要重启才能生效: 2.InnoDB的data page默认16KB,5.6版本以后,新增选项 innodb_page_size

  • 浅谈mysql的子查询联合与in的效率

    最近的产品测试发现一个问题,当并发数量小于10时,响应时间可以维持在100毫秒以内.但是当并发数到达30个时,响应时间就超过1秒.这太不能接受了,要求是通过1秒中并发100个. 经过检测发现,时间主要是耗在其中的一个存储过程中.把存储过程的语句一条一条的过一遍也没有发现明显的不合理.因为mysql本身不能提供毫秒级别的时间,google了一个mysql的能提供毫秒的时间函数,再做测试,做了一个定位.发现是其中一条语句,语句是这个样子: select .... from A, B where ..

  • 浅谈mysql中多表不关联查询的实现方法

    大家在使用MySQL查询时正常是直接一个表的查询,要不然也就是多表的关联查询,使用到了左联结(left join).右联结(right join).内联结(inner join).外联结(outer join).这种都是两个表之间有一定关联,也就是我们常常说的有一个外键对应关系,可以使用到 a.id = b.aId这种语句去写的关系了.这种是大家常常使用的,可是有时候我们会需要去同时查询两个或者是多个表的时候,这些表又是没有互相关联的,比如要查user表和user_history表中的某一些数据

  • 浅谈MySQL模糊查询中通配符的转义

    sql中经常用like进行模糊查询,而模糊查询就要用到百分号"%",下划线"_"这些通配符,其中"%"匹配任意多个字符,"_"匹配单个字符.如果我们想要模糊查询带有通配符的字符串,如"60%","user_name",就需要对通配符进行转义,有两种方式.如下:   1.反斜杠是转义符,通过反斜杠来转义%,使其不再是通配符.这里第一个%是通配符,第二个%不是通配符. select perc

  • 浅谈MySQL使用笛卡尔积原理进行多表查询

    MySQL的多表查询(笛卡尔积原理) 先确定数据要用到哪些表. 将多个表先通过笛卡尔积变成一个表. 然后去除不符合逻辑的数据(根据两个表的关系去掉). 最后当做是一个虚拟表一样来加上条件即可. 注意:列名最好使用表别名来区别. 笛卡尔积 Demo: 左,右连接,内,外连接 l 内连接: 要点:返回的是所有匹配的记录. select * from a,b where a.x = b.x ////内连接 l 外连接有左连接和右连接两种. 要点:返回的是所有匹配的记录 外加 每行主表外键值为null的

  • 浅谈mysql通配符进行模糊查询的实现方法

    在mysql数据库中,当我们需要模糊查询的时候 ,我们会使用到通配符. 首先我们来了解一下2个概念,一个是操作符,一个是通配符. 操作符 like就是SQL语句中的操作符,它的作用是指示在SQL语句后面的搜索模式是利用通配符而不是直接相等匹配进行比较. 注意:如果使用like操作符时没有使用通配符,那么效果是和等号是一致的. SELECT id,title FROM table WHERE title like '张三'; 这种写法就只能匹配张三的记录,而不能匹配像张三是个好人这样的记录. 通配

  • 浅谈Mysql多表连接查询的执行细节

    浅谈Mysql多表连接查询的执行细节

    先构建本篇博客的案列演示表: create table a(a1 int primary key, a2 int ,index(a2)); --双字段都有索引 create table c(c1 int primary key, c2 int ,index(c2), c3 int); --双字段都有索引 create table b(b1 int primary key, b2 int); --有主键索引 create table d(d1 int, d2 int); --没有索引 insert

  • 浅谈MySQL数据查询太多会OOM吗

    浅谈MySQL数据查询太多会OOM吗

    目录 全表扫描对server层的影响 全表扫描对InnoDB的影响 InnoDB内存管理 小结 我的主机内存只有100G,现在要全表扫描一个200G大表,会不会把DB主机的内存用光? 逻辑备份时,可不就是做整库扫描吗?若这样就会把内存吃光,逻辑备份不是早就挂了? 所以大表全表扫描,看起来应该没问题.这是为啥呢? 全表扫描对server层的影响 假设,我们现在要对一个200G的InnoDB表db1. t,执行一个全表扫描.当然,你要把扫描结果保存在客户端,会使用类似这样的命令: mysql -h$

  • 浅谈Mysql大数据分页查询解决方案

    浅谈Mysql大数据分页查询解决方案

    目录 1.简介 2.分页插件使用 3.sql测试与分析 3.1 limit现象分析 3.2 解决之道 4 测试时走过的坑 4.1 百万数据内容都一样 4.2 写sql时,把"77"写成了77: 4.3 一个有趣的现象 总结 1.简介 之前,面阿里的时候,有个面试官问我有没有使用过分页查询,我说有,他说分页查询是有问题的,怎么解决:后来这个问题我没有回答出来:本着学习的态度,今天来解决一下这个问题: 2.分页插件使用 1.pom文件 <dependency> <grou

  • 浅谈MySQL中的子查询优化技巧

    mysql的子查询的优化一直不是很友好,一直有受业界批评比较多,也是我在sql优化中遇到过最多的问题之一,你可以点击这里 ,这里来获得一些信息,mysql在处理子查询的时候,会将子查询改写,通常情况下,我们希望由内到外,也就是先完成子查询的结果,然后在用子查询来驱动外查询的表,完成查询,但是恰恰相反,子查询不会先被执行:今天希望通过介绍一些实际的案例来加深对mysql子查询的理解: 案例:用户反馈数据库响应较慢,许多业务动更新被卡住:登录到数据库中观察,发现长时间执行的sql: | 10437

  • 浅谈MySQL和Lucene索引的对比分析

    浅谈MySQL和Lucene索引的对比分析

    MySQL和Lucene都可以对数据构建索引并通过索引查询数据,一个是关系型数据库,一个是构建搜索引擎(Solr.ElasticSearch)的核心类库.两者的索引(index)有什么区别呢?以前写过一篇<Solr与MySQL查询性能对比>,只是简单的对比了下查询性能,对于内部原理却没有解释,本文简单分析下两者的索引区别. MySQL索引实现 在MySQL中,索引属于存储引擎级别的概念,不同存储引擎对索引的实现方式是不同的,本文主要讨论MyISAM和InnoDB两个存储引擎的索引实现方式. M

随机推荐