Mysql中的update语句如何嵌套子查询

进行嵌套查询的时候子查询出来的的结果是作为一个派生表来进行上一级的查询的，所以子查询的结果必须要有一个别名
例如：把mysql语句改成：select
count()
from
(select

from
……)
as
total;
问题就解决了，虽然只加了一个没有任何作用的别名total，但这个别名是必须的

你这个语句会报错
Where mm in (select pname,sallpid,price(count(sallpid)) as mm ……
改成：
Where mm in (select price(count(sallpid)) as mm ……)
怎么感觉你这个语句怪怪的？
把表结构发出来看看？

不用这么麻烦的，SQL中还有个好用的关键字就是having。所以可以直接在having中写上
having（count(get_json_object(msg,'$use')) = 2）

修改之后差不多就是

select count
from yactiveall_yactive
where time>=20141217 and time<=20141223
group by uid, time
having (count(get_json_object(msg,'$use')) = 2)

至于你的语句中的count(if(get_json_object(msg,'$t')='3' or get_json_object(msg,'$t')='9',uid,null)) as use不知道是什么其他条件就没加了，看你业务需求了。

select a from user_info a,waitforpass b where apassuserid =bpassuserid and bhavepass=1
这样只会查出来 237 238 239 240

　解决办法：
内存溢出虽然很棘手，但也有相应的解决办法，可以按照从易到难，一步步的解决。
第一步，就是修改JVM启动参数，直接增加内存。这一点看上去似乎很简单，但很容易被忽略。JVM默认可以使用的内存为64M，Tomcat默认可以使用的内存为128MB，对于稍复杂一点的系统就会不够用。在某项目中，就因为启动参数使用的默认值，经常报"OutOfMemory"错误。因此，-Xms，-Xmx参数一定不要忘记加。
第二步，检查错误日志，查看"OutOfMemory"错误前是否有其它异常或错误。在一个项目中，使用两个数据库连接，其中专用于发送短信的数据库连接使用DBCP连接池管理，用户为不将短信发出，有意将数据库连接用户名改错，使得日志中有许多数据库连接异常的日志，一段时间后，就出现"OutOfMemory"错误。经分析，这是由于DBCP连接池BUG引起的，数据库连接不上后，没有将连接释放，最终使得DBCP报"OutOfMemory"错误。经过修改正确数据库连接参数后，就没有再出现内存溢出的错误。
查看日志对于分析内存溢出是非常重要的，通过仔细查看日志，分析内存溢出前做过哪些 *** 作，可以大致定位有问题的模块。
第三步，安排有经验的编程人员对代码进行走查和分析，找出可能发生内存溢出的位置。重点排查以下几点:
 检查代码中是否有死循环或递归调用。
 检查是否有大循环重复产生新对象实体。
 检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
 检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。
第四步，使用内存查看工具动态查看内存使用情况。某个项目上线后，每次系统启动两天后，就会出现内存溢出的错误。这种情况一般是代码中出现了缓慢的内存泄漏，用上面三个步骤解决不了，这就需要使用内存查看工具了。
内存查看工具有许多，比较有名的有:Optimizeit Profiler、JProbeProfiler、JinSight和Java15的Jconsole等。它们的基本工作原理大同小异，都是监测Java程序运行时所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员可以根据这些信息判断程序是否有内存泄漏问题。一般来说，一个正常的系统在其启动完成后其内存的占用量是基本稳定的，而不应该是无限制的增长的。持续地观察系统运行时使用的内存的大小，可以看到在内存使用监控窗口中是基本规则的锯齿形的图线，如果内存的大小持续地增长，则说明系统存在内存泄漏问题。通过间隔一段时间取一次内存快照，然后对内存快照中对象的使用与引用等信息进行比对与分析，可以找出是哪个类的对象在泄漏。
通过以上四个步骤的分析与处理，基本能处理内存溢出的问题。当然，在这些过程中也需要相当的经验与敏感度，需要在实际的开发与调试过程中不断积累。
内存溢出（out of memory），通俗理解就是内存不够，通常在运行大型软件或游戏时，软件或游戏所需要的内存远远超出了你主机内安装的内存所承受大小，就叫内存溢出。此时软件或游戏就运行不了，系统会提示内存溢出，有时候会自动关闭软件，重启电脑或者软件后释放掉一部分内存又可以正常运行该软件或游戏一段时间。
内存溢出已经是软件开发历史上存在了近40年的"老大难"问题，像在"红色代码"病毒事件中表现的那样，它已经成为黑客攻击企业网络的"罪魁祸首"。 如在一个域中输入的数据超过了它的要求就会引发数据溢出问题，多余的数据就可以作为指令在计算机上运行。据有关安全小组称， *** 作系统中超过50%的安全漏洞都是由内存溢出引起的，其中大多数与微软的技术有关。
定义及原因
内存溢出是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于虚拟机能提供的最大内存。为了解决Java中内存溢出问题，我们首先必须了解Java是如何管理内存的。Java的内存管理就是对象的分配和释放问题。在Java中，内存的分配是由程序完成的，而内存的释放是由垃圾收集器(GarbageCollection，GC)完成的，程序员不需要通过调用GC函数来释放内存，因为不同的JVM实现者可能使用不同的算法管理GC，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是中断式执行GC。但GC只能回收无用并且不再被其它对象引用的那些对象所占用的空间。Java的内存垃圾回收机制是从程序的主要运行对象开始检查引用链，当遍历一遍后发现没有被引用的孤立对象就作为垃圾回收。
引起内存溢出的原因有很多种，常见的有以下几种:
内存中加载的数据量过于庞大，如一次从数据库取出过多数据;
集合类中有对对象的引用，使用完后未清空，使得JVM不能回收; 代码中存在死循环或循环产生过多重复的对象实体; 使用的第三方软件中的BUG; 启动参数内存值设定的过小。

1，简单子查询；
select name,age from person
where age >
(
select age from person
where name = '孙权'
)
2，in嵌套查询；
select name from person
where countryid in
(
select countryid from country
where countryname = '魏国'
)
3，some嵌套查询
select name from person
where countryid = some --用等号和以下查询到的值比较，如果与其中一个相等，就返回
(
select countryid from country
where countryname = '魏国'
)
4，all嵌套查询
select name from person
where countryid > all --当countryid大于以下返回的所有id，此结果才为True，此结果才返回
(
select countryid from country
where countryname = '魏国'
)
5，exits嵌套查询
SELECT FROM Person
WHERE exists
(
SELECT 1 --SELECT 0 SELECT NULL 返回结果都一样，因为这三个子查询都有结果集返回，因此总是True SELECT FROM Person照常执行
)　
但是如果子查询中因为加了条件而没有结果集返回，则主语句就不执行了：
SELECT FROM Person
WHERE exists
(
SELECT FROM Person
WHERE Person_Id = 100 --如果不存在Person_Id的记录，则子查询没有结果集返回，主语句不执行
)

---