求助-探讨:在数据量稍大(几十万条级别)的情况下,联表查询/子查询/用PHP逐步分析结果多次单表查询的优劣与选择

mysql 优化

先说说我现在这个项目的情况

主表40W条记录,大部分与之关联的查询都会比较慢(3秒以上).主键索引.

如果有用到子查询,执行甚至会超时(30秒),或者长达10多秒.


现在我用PHP将每一步查询结果分析,拼装成字符串在用in来查询.目前是快多了

举例子:查询某人关注的人发布的微博(假设主表是微博表).  我就先把某人关注的人查出来,uid拼成字符串,然后查微博表uid in (关注的人字符串) 这样子.

但是还是担心会不会因为其他问题比如严重增加PHP的负荷等等.

现在网站还没做推广用户很少所以还不清楚高并发量和访问数下的情况. 先来问问


各位的网站用联表查或者子查询的多吗? 有没有像我这样用的?

请不吝赐教

回复讨论(解决方案)

再好的数据库设计基本上也避免不了子查询和联合查询。
但是一条普通的查询都要3s的时间，子查询甚至30s还是有些太夸张了。
或许可以把你的表结构贴出来，一起探讨。

用联结查询比较好left join,right join.
联接查询时一条一条去比对，匹配了查询就终结。

select aid,b.name where tb1 a,tb2 b where a.id=b.id 这种是先将tb1和tb2的结果搞成笛卡尔积。
然后在笛卡尔积中筛选a.id=b.id的条目，效率大打折扣。

所以多用left join,right join吧

用联结查询比较好left join,right join.
联接查询时一条一条去比对，匹配了查询就终结。

select aid,b.name where tb1 a,tb2 b where a.id=b.id 这种是先将tb1和tb2的结果搞成笛卡尔积。
然后在笛卡尔积中筛选a.id=b.id的条目，效率大打折扣。

所以多用left join,right join吧

我用联结查询时 先left join 然后再用这些where条件 这个应该不冲突的吧?

合理建表，合理索引。

explain分析一下呢

联结查询有时候也不能完全取消，主要还是看索引建立的合适不合适，看sql有没有合理使用索引

最好还是把你的结构和sql拿出来分析分析

建议跟踪下cpu的使用以及进程之类的