12
回答
mysql 多表查询优化
利用AWS快速构建适用于生产的无服务器应用程序,免费试用12个月>>>   

@魔力猫 你好,想跟你请教个问题:

sql 语句如:

SELECT
    `t`.*, `u`.`mobile`,
    `r`.`realname`,
    `b`.`bind_type`
FROM
    `t_trade_order` `t`
LEFT JOIN `t_user` `u` ON `u`.`uid` = `t`.`uid`
LEFT JOIN `t_user_identity` `r` ON `r`.`uid` = `t`.`uid`
LEFT JOIN `t_user_bind_company` `b` ON `b`.`uid` = `t`.`uid`
AND `b`.`companyid` = `t`.`companyid`
WHERE
    1 = 1
AND `t`.`touzhi_time` >= '2017-03-01 00:00:00'
AND `t`.`touzhi_time` <= '2017-03-31 23:59:59'
ORDER BY
    `t`.`id` DESC

 

本来t_trade_order的touzi_time 没有索引,我给建了个普通btree的索引,没见效果,几乎还是全表扫描。 能给指点下问题出在什么地方么?现在就1W多的数据,这个sql竟然能执行在4.5S

<无标签>
举报
blue_ma
发帖于8个月前 12回/410阅
共有12个答案 最后回答: 8个月前

t_trade_order 1W多数据,你的查询结果返回的数据集是多少,如果返回的数据集太多,那么系统很可能不调用索引。

另外,你可以尝试使用use强制使用索引,看索引的情况下,效率是提高了还是降低了。

--- 共有 1 条评论 ---
blue_ma强制使用了touzi_time的普通索引,结果并没有好转,反而查询时间多出了1S 8个月前 回复

看你order by 没怎么用 就去掉····数据量大的时候别用排序

--- 共有 2 条评论 ---
skhuhu 回复 @blue_ma : 最好能保证left join on 后面的是主键或者索引,最后查询分量 用limit 8个月前 回复
blue_ma嗯,去掉有效果,查询时间少了1S。 8个月前 回复

关联id加上索引(多样性越好效率越快),touzhi_time加上索引,t_trade_order的id字段如果是自增的。SQL可以先去掉ORDER BY。程序做降序。尽量让SQL越小越好吧。

--- 共有 2 条评论 ---
Java_Coder 回复 @blue_ma : 实在不行,冗余一张表,单独存储此次SQL需要的字段。 8个月前 回复
blue_ma嗯嗯,说的这些基本上都做了,还是不太见效果 8个月前 回复
t表的数据总量,结果集大小,去掉排序后的执行时间
--- 共有 2 条评论 ---
魔力猫 回复 @blue_ma : 占总记录30%的结果集,索引已经无意义。3%还差不多。我觉得你需要说明整个业务思路了,这个SQL返回值太大,无法单优化一条SQL完成效率提高。 8个月前 回复
blue_mat表总量有10801,结果集有3069,去掉排序后明显看到查询时间少了1S,不过还是挺长时间的,在4s左右 8个月前 回复

这种多表联查很难优化,看你都是和t_trade_order联查,可以试试分成3个sql查询(如果速度快的话),然后在后台程序合并

--- 共有 2 条评论 ---
风翔飞 回复 @blue_ma : 还好吧,不是一共就几千条数据么,先看看单独查询的时候的速度,如果加起来和之前差不多的话就算了,如果很快的话,这样操作比较好 8个月前 回复
blue_ma这个操作量是不是会很大了 8个月前 回复

试试这个:

SELECT
    `t`.*,
  (select mobile from t_user where `uid` = `t`.`uid`) `mobile`,
   (select mobile from t_user_identity where `uid` = `t`.`uid`) `realname`,
     (select mobile from t_user_bind_company where `uid` = `t`.`uid` AND `companyid` = `t`.`companyid`) `bind_type`
FROM
    `t_trade_order` `t`

WHERE
    1 = 1
AND `t`.`touzhi_time` >= '2017-03-01 00:00:00'
AND `t`.`touzhi_time` <= '2017-03-31 23:59:59'
ORDER BY
    `t`.`id` DESC

--- 共有 5 条评论 ---
Ambitor 回复 @祝网 : 呵呵,这个请求多请求几次 你看会不会有灾难性后果 8个月前 回复
祝网 回复 @Ambitor : 就算是会出现这样,这也不算是灾难性的吧 8个月前 回复
Ambitor 回复 @祝网 : 慢或者出不来。 8个月前 回复
祝网 回复 @Ambitor : 什么灾难性后果? 8个月前 回复
Ambitor朋友 你这个可能暂时看起来会快点,但是数据量大了 会有灾难性后果哦。 8个月前 回复
顶部