查询语句性能问题

2015-08-05 05:52:32 168 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

jontian 墨衍会员 · AI 创作全网分发关注 + 加入社区

如何分析和解决 SQL 调优中的性能问题？【代码】如何分析和解决 SQL 调优中的性能问题？阅读详情

select b.user_type from a left join b on a.id=b.id where a.unit_id=1 and a.join_year=2015

b表是a表的子表，a表有40W条，b表有50W条，
因为要查只要a表有的所有数据，所以用from a left join b，
unit_id和join_year在a表都建了索引，如果不加a.join_year=2015条件查询在0.2秒左右，加了这个条件就会到2.3秒，加其它条件也都在0.3秒内，能不能看出是什么原因，各位帮看一下。
----
实际查询语句已简化和上面一样了还是出同样问题

...全文

openGauss 分析查询语句运行状态如果state字段显示为idle，则表明此连接处于空闲，等待用户输入命令。如果仅需要查看非空闲的查询语句，则使用如下命令查看。查询结果中包含了当前被阻塞的查询语句，该查询语句所请求的锁资源可能被其他会话持有，正在等待持有会话释放锁资源。通过如下命令查看当前处于阻塞状态的查询语句。查看正在运行的查询语句。系统中部分查询语句运行时间过长，需要分析查询语句的运行状态。当此参数为on时，数据库系统才会收集当前活动查询的运行信息。postgres为需要连接的数据库名称，8000为端口号。使用如下命令连接数据库。阅读详情

疑难问题 22,298 成员 121,727 内容

+ 关注 + 加入社区

评论 9

切换为时间正序

jontian 2015-08-06

打赏
举报

回复

引用 1 楼 Cherise_huang 的回复:

如果你的select字段包含在索引里面，速度应该会更快一点并且Where后条件的先后顺序也会影响到SQL语句的执行效率

这个是主业务表，用到的地方很多，已有5个索引了，不合适再建，且我现在的问题是加了join_year这个条件才变慢的。在所有的条件中只有unit_id这个是排除量最高的，所以放在了第一个条件

jontian 2015-08-06

打赏
举报

回复

引用 3 楼 Landa_Ran 的回复:

应该是你的索引创建方式不对，可以看看这个链接http://www.2cto.com/database/201209/156626.html

可能有这个原因，我根据那文章做了些修改，提上去一点，但是还觉得没达到效果，没能达到不加join_year条件的速度。

jontian 2015-08-06

打赏
举报

回复

引用 5 楼 Tiger_Zhao 的回复:

a表要把(join_year,unit_id)建在一个索引中，该索引包含(id) 同时建议b表的(id)索引包含(user_type) 还有子表不一定就要 left join，直接 join 就可以，除非你明确需要返回 b.user_type 为 NULL 的记录（有什么意义？）。

你的第一条加上去，没有加快，另外直接用join是默认为inner join吧，这个性能应比left join要差，我这里的业务也是适合用left join

Tiger_Zhao 2015-08-06

打赏
举报

回复

a表要把(join_year,unit_id)建在一个索引中，该索引包含(id)
同时建议b表的(id)索引包含(user_type)
还有子表不一定就要 left join，直接 join 就可以，除非你明确需要返回 b.user_type 为 NULL 的记录（有什么意义？）。

xiaoxiangqing 2015-08-06

打赏
举报

回复

join_year这个有没有建索引？

Tiger_Zhao 2015-08-06

打赏
举报

回复

join_year 字段不是 int 型？

许晨旭 2015-08-05

打赏
举报

回复

应该是你的索引创建方式不对，可以看看这个链接http://www.2cto.com/database/201209/156626.html

Landa_Tiny_cui 2015-08-05

打赏
举报

回复

可以把A表的筛选后的数据放到临时表里，再用临时表与B表关联

Cherise_huang 2015-08-05

打赏
举报

回复

如果你的select字段包含在索引里面，速度应该会更快一点并且Where后条件的先后顺序也会影响到SQL语句的执行效率