在项目中有一条简单的sql语句,使用子查询非常耗时。使用联合查询,非常快。查了点资料,大概总结下关键部分。
关键技术文档参照:
https://blog.csdn.net/kmblack1/article/details/80761647
https://blog.csdn.net/weixin_39540651/article/details/105433144

  1. 使用 explain ANALYZE

  2. 查看方法是从后向前;actual time记录了实际运行的起始时间和结束时间;hash cond表示将查询出来的数据做了hash放入内存中

  3. 并不是只要表里有索引,就不会进行全表查询:
    Postgresql explain查询小结
    从这里看出来,其实app_sig_cp里的product_type建立了唯一索引,但是查询的另外两个字段并没有建立索引。所以仍然进行全表扫描。后来手动写了只查询product_type字段的sql,确认会进行bitmap查询
    关于什么情况下才会进行bitmap查询,我看过资料,但是忘记了。。后面补充吧,大概就是数据量很大时不会进行bla bla

  4. 关于查询优先级,之前有疑惑的点在于如果两张表join了,并且带了where条件,是先进行join,还是先用where呢。因为这关系到sql拼写的方式。后来最后用explain发现都是先where,才join,所以不用担心性能
    Postgresql explain查询小结

  5. 用子查询之所以慢,关键在这里,最后使用nestloop进行join,而多表查询,仅是用hash join,就快很多:
    子查询:Postgresql explain查询小结
    多表查询:
    Postgresql explain查询小结
    关于这两种join对比,参考了 https://blog.csdn.net/weixin_39540651/article/details/105433144
    nested loop join,是对左表中找到的每一行都要扫描右表一次。这种策略最容易实现但是可能非常耗时
    Postgresql explain查询小结
    而hash join,右表会先被扫描并且被载入到一个哈希表,使用连接列作为哈希键。接下来左表被扫描,扫描中找到的每一行的连接属性值被用作哈希键在哈希表中查找匹配的行。
    Postgresql explain查询小结

相关文章:

  • 2021-05-24
  • 2021-05-28
  • 2022-12-23
  • 2022-12-23
  • 2021-12-08
  • 2017-12-14
猜你喜欢
  • 2022-02-19
  • 2021-09-23
  • 2022-12-23
  • 2021-08-16
  • 2021-12-23
  • 2021-10-29
  • 2021-09-05
相关资源
相似解决方案