只说查询，和我最近用的一个sql类似，在一张近百万数据的表中，通过一个文章id(docId),找出对应的word(word是根据文章标题分词得到的),再根据这些word，查找所有的相关的文章id。一开始的做法是select docId from tab1 where word in (select word from tab1 where docId=123) group by docId limit 1000; 各个字段都建了索引，执行过后，花了35s左右时间。后来换成join查询，能达到50ms左右，经过讨论，问题是出在in上，导致查询时没用上索引，优化后的sql是：select docId from (select word from tab1 where docId=123) as t2 join tab1 t on t.word=t2.word where t2.word is not null GROUP BY docId limit 1000
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
只说查询，和我最近用的一个sql类似，在一张近百万数据的表中，通过一个文章id(docId),找出对应的word(word是根据文章标题分词得到的),再根据这些word，查找所有的相关的文章id。一开始的做法是select docId from tab1 where word in (select word from tab1 where docId=123) group by docId limit 1000;
各个字段都建了索引，执行过后，花了35s左右时间。后来换成join查询，能达到50ms左右，经过讨论，问题是出在in上，导致查询时没用上索引，优化后的sql是：select docId from (select word from tab1 where docId=123) as t2 join tab1 t on t.word=t2.word where t2.word is not null GROUP BY docId limit 1000
说了这么多，是想说 用in查询 貌似不太好~~~
加上一个测试结果
初步的测试结果
select * from dynamics where uid in ({$uidStr}) order by
created_atdesc limit 10000上面这种查询，其中dynamics表记录在3百万左右，$uidStr是2000个
mysql(5.5)
0.19s 左右（where in 情况下，created_at索引好像没有用上）
mongodb
$cursor = $dyCollection->find(array("uid" => array('$in' => $selectedUid)))->sort(array("created_at"=>-1))->limit(10000);
对created_at建立索引后，0.09s 左右
另外如果插入mongodb是按时间顺序插入的话，其实可以不用再排序了，查出来的就是当时插入的顺序，但是mysql where in的话，取出来的结果好像是按in那个字段升序排的
另外
limit减少到3000以下的时候，mysql只需要0.04s，mongodb只需要0.02s，不知道该怎么优化了