PostgreSQL 中 min() 和 order by limit 1 的对比

最新推荐文章于 2024-07-15 06:52:45 发布
最新推荐文章于 2024-07-15 06:52:45 发布
阅读量3.3k 收藏 2
点赞数
分类专栏： postgresql 文章标签： 数据库 postgresql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/international24/article/details/107042720
版权

 

在实际应用中，我们经常需要计算数据库中某张表的某个字段的的最小值/最大值，并用它来作为查询条件。

使用SQL求数据库中表字段的最小值/最大值，通常由两种方法：

一种是 使用聚集函数 min()/max(), 另一种是使用order BY + “字段” 子句，对该表排序之后，取第一条记录中该字段的值。

本文在PostgreSQL 11.4上，对min() 和 order by … limit 1 以及它们的变体做一个全方位的对比。

 

现在有一张表tb_person，它的定义如下：

 

create table tb_person (

    person_id integer not null,

    person_name varchar(64),

    sex int,

    birthday date,

    phone varchar(64),

    job_no varchar(48),

    department_id int,

    create_time timestamp with time zone,

    update_time timestamp with time zone,

    constraint pk_tb_person primary key (person_id)

);

comment on table  tb_person is '人员表';

comment on column tb_person.person_id is '主键id';

comment on column tb_person.person_name is '人员姓名';

comment on column tb_person.sex is '性别。0:男性；1：女性';

comment on column tb_person.birthday is '出生日期';

comment on column tb_person.phone is '联系电话';

comment on column tb_person.job_no is '员工工号';

comment on column tb_person.department_id is '所属部门id';

comment on column tb_person.create_time is '创建时间';

comment on column tb_person.update_time is '更新时间';

 

create index idx_tb_person_job_no on tb_person (job_no);

create index idx_tb_person_department_id on tb_person (department_id);

create index idx_tb_person_birthday on tb_person (birthday);

 

我们通过下面的sql 向表中插入300000 行数据：

insert into tb_person (person_id, person_name, sex, birthday, phone, job_no, department_id, create_time, update_time)

select num, substr('abcdefghijklmnopqrstuvwxyz', mod(num,26), 10), ceil(random()*2), '1970-01-01'::date + (interval '1 hour') * num, null,

to_char(num, 'FM000000'), ceil(random()*3000), now(), now() from

(select generate_series(1,300000) as num) a;

 

接下来我们通过一些查询案例来对比。

 

1. 查找人员表中最小的工号

获得人员表中最小的工号，有两种方法：

select min(job_no) from tb_person;

和

select job_no from tb_person order by job_no limit 1;

 

 

现在我们用 explain analyze，查看两种方法的查询计划，比较它们的性能。我们主要关注cost 和 execution time 两个指标。

 

查看第一种方法的查询计划：

explain analyze

select min(job_no) from tb_person;

 

结果如下：

Result  (cost=0.45..0.46 rows=1 width=32) (actual time=0.029..0.030 rows=1 loops=1)

  InitPlan 1 (returns $0)

    ->  Limit  (cost=0.42..0.45 rows=1 width=32) (actual time=0.023..0.024 rows=1 loops=1)

          ->  Index Only Scan using idx_tb_person_job_no on tb_person  (cost=0.42..8550.42 rows=300000 width=32) (actual time=0.020..0.020 rows=1 loops=1)

                Index Cond: (job_no IS NOT NULL)

                Heap Fetches: 0

Planning time: 0.161 ms

Execution time: 0.060 ms

 

查看第二种方法的查询计划：

explain analyze

select job_no from tb_person order by job_no limit 1;

 

结果如下：

Limit  (cost=0.42..0.46 rows=1 width=61) (actual time=0.032..0.033 rows=1 loops=1)

  ->  Index Scan using idx_tb_person_job_no on tb_person  (cost=0.42..11213.42 rows=300000 width=61) (actual time=0.028..0.028 rows=1 loops=1)

Planning time: 0.182 ms

Execution time: 0.069 ms

 

从上面的执行时间和代价估计可以看出，两种方法没有明显性能差别。

 

2. 查找工号最小的人

查找工号最小的人也有两种方法。

第一种方法是：

select * from tb_person where job_no = ( select min(job_no) from tb_person);

 

第二种方法是：

select * from tb_person order by job_no limit 1;

 

下面我们比较两种方法的查询计划：

查看第一种方法的查询计划：

explain analyze select * from tb_person where job_no = ( select min(job_no) from tb_person );

 

结果如下：

Index Scan using idx_tb_person_job_no on tb_person  (cost=0.88..8.90 rows=1 width=61) (actual time=0.129..0.131 rows=1 loops=1)

  Index Cond: ((job_no)::text = $1)

  InitPlan 2 (returns $1)

    ->  Result  (cost=0.45..0.46 rows=1 width=32) (actual time=0.084..0.085 rows=1 loops=1)

          InitPlan 1 (returns $0)

            ->  Limit  (cost=0.42..0.45 rows=1 width=32) (actual time=0.077..0.078 rows=1 loops=1)

                  ->  Index Only Scan using idx_tb_person_job_no on tb_person tb_person_1  (cost=0.42..8550.42 rows=300000 width=32) (actual time=0.072..0.072 rows=1 loops=1)

                        Index Cond: (job_no IS NOT NULL)

                        Heap Fetches: 0

Planning time: 0.255 ms

Execution time: 0.179 ms

 

查看第二种方法的查询计划：

explain analyze

select * from tb_person order by job_no limit 1;

 

结果如下：

Limit  (cost=0.42..0.46 rows=1 width=61) (actual time=0.021..0.022 rows=1 loops=1)

  ->  Index Scan using idx_tb_person_job_no on tb_person  (cost=0.42..11213.42 rows=300000 width=61) (actual time=0.018..0.018 rows=1 loops=1)

Planning time: 0.164 ms

Execution time: 0.054 ms

 

可以看出，第二种方法的性能优于第一种。第一种方法做了两次扫描，而第二种方法只做了一次。

 

3. 求每个部门工号最小的人的id

这里需要根据department_id分组。实现它也有两种方法。

第一种方法：

select person_id from tb_person where job_no in (

select min(job_no) from tb_person group by department_id

);

这种方法是根据 department_id 将人员数据分组，获取每个部门最小的job_no，再根据job_no 获取对应的person_id

 

第二种方法：

select (array_agg(person_id order by job_no))[1] from tb_person group by department_id

 

这种方法是根据department_id分组，将每个组的person_id 聚合成数组，聚合是按照job_no递增的顺序的，并取每个数组中第一个元素，即每个部门最小job_no对应的person_id

 

下面我们比较两种方法的性能。

查看第一种方法的查询计划：

explain analyze

select person_id from tb_person where job_no in (

select min(job_no) from tb_person group by department_id

);

 

结果如下：

Nested Loop  (cost=6291.75..6468.99 rows=9 width=4) (actual time=394.590..394.990 rows=21 loops=1)

  ->  HashAggregate  (cost=6291.33..6291.54 rows=21 width=32) (actual time=394.544..394.564 rows=21 loops=1)

        Group Key: min((tb_person_1.job_no)::text)

        ->  Finalize GroupAggregate  (cost=6290.54..6291.07 rows=21 width=36) (actual time=394.320..394.512 rows=21 loops=1)

              Group Key: tb_person_1.department_id

              ->  Sort  (cost=6290.54..6290.65 rows=42 width=36) (actual time=394.303..394.361 rows=63 loops=1)

                    Sort Key: tb_person_1.department_id

                    Sort Method: quicksort  Memory: 27kB

                    ->  Gather  (cost=6285.00..6289.41 rows=42 width=36) (actual time=393.681..394.231 rows=63 loops=1)

                          Workers Planned: 2

                          Workers Launched: 2

                          ->  Partial HashAggregate  (cost=5285.00..5285.21 rows=21 width=36) (actual time=305.755..305.774 rows=21 loops=3)

                                Group Key: tb_person_1.department_id

                                ->  Parallel Seq Scan on tb_person tb_person_1  (cost=0.00..4660.00 rows=125000 width=11) (actual time=0.015..117.754 rows=100000 loops=3)

  ->  Index Scan using idx_tb_person_job_no on tb_person  (cost=0.42..8.44 rows=1 width=11) (actual time=0.013..0.015 rows=1 loops=21)

        Index Cond: ((job_no)::text = (min((tb_person_1.job_no)::text)))

Planning time: 0.351 ms

Execution time: 403.014 ms

 

查看第二种方法的查询计划：

explain analyze

select (array_agg(person_id order by job_no))[1] from tb_person group by department_id

 

结果如下：

GroupAggregate  (cost=0.42..23822.21 rows=21 width=8) (actual time=67.788..2884.911 rows=21 loops=1)

  Group Key: department_id

  ->  Index Scan using idx_tb_person_department_id on tb_person  (cost=0.42..22321.95 rows=300000 width=15) (actual time=0.017..382.140 rows=300000 loops=1)

Planning time: 0.119 ms

Execution time: 2885.164 ms

 

可以看出，当分组字段的每个值对应的行数较多时（这里每个department_id对应100条数据），第二种方法的性能远远不如第一种。

 

4. 每个部门中抽选一人

这个问题也有两种实现。

第一种方法：

select min(person_id) , department_id from tb_person group by department_id

每个部门中抽选person_id最小的人。

 

第二种方法：

select distinct on (department_id) person_id,person_name,department_id  from tb_person order by department_id

每个部门抽选一人，不关注person_id的字典序。

 

 

比较下列两种方法的性能

查看第一种方法的查询计划：

explain analyze

 select min(person_id) , department_id from tb_person group by department_id

 

结果如下：

Finalize GroupAggregate  (cost=6290.54..6291.07 rows=21 width=8) (actual time=289.036..289.159 rows=21 loops=1)

  Group Key: department_id

  ->  Sort  (cost=6290.54..6290.65 rows=42 width=8) (actual time=289.025..289.079 rows=63 loops=1)

        Sort Key: department_id

        Sort Method: quicksort  Memory: 27kB

        ->  Gather  (cost=6285.00..6289.41 rows=42 width=8) (actual time=288.456..288.945 rows=63 loops=1)

              Workers Planned: 2

              Workers Launched: 2

              ->  Partial HashAggregate  (cost=5285.00..5285.21 rows=21 width=8) (actual time=210.916..210.938 rows=21 loops=3)

                    Group Key: department_id

                    ->  Parallel Seq Scan on tb_person  (cost=0.00..4660.00 rows=125000 width=8) (actual time=0.013..107.747 rows=100000 loops=3)

Planning time: 0.149 ms

Execution time: 296.498 ms

 

查看第二种方法的查询计划：

explain analyze

select distinct on (department_id)  person_id, department_id  from tb_person order by department_id

 

     结果如下：

Unique  (cost=0.42..23071.95 rows=21 width=8) (actual time=0.021..676.080 rows=21 loops=1)

  ->  Index Scan using idx_tb_person_department_id on tb_person  (cost=0.42..22321.95 rows=300000 width=8) (actual time=0.017..426.196 rows=300000 loops=1)

Planning time: 0.105 ms

Execution time: 676.146 ms

 

从上面的结果可以，看出第一种方法的性能好一些。

 

5. 查找每个部门中最年长的人

接下来查找每个部门中最年长的人。若两人出生日期，部门均相同，则任取一个，这个需求也有三种sql 实现。

 

第一种方法：

select min(person_id) from tb_person inner join (

 select min(birthday) as birthday, department_id from tb_person group by department_id

) a using (birthday, department_id) GROUP BY department_id;

 

第二种方法：

select (array_agg(person_id order by birthday))[1] from tb_person group by department_id

 

第三种方法：

SELECT distinct on (a.department_id) person_id from tb_person inner join

(

    select min(birthday) as birthday, department_id from tb_person group by department_id

) a using(birthday,department_id) order by a.department_id;

 

 

比较他们的性能：

查看第一种方法的查询计划：

explain analyze

select min(person_id) from tb_person inner join (

 select min(birthday) as birthday, department_id from tb_person group by department_id

) a using (birthday, department_id) GROUP BY department_id;

 

结果如下：

GroupAggregate  (cost=6295.27..9269.40 rows=17 width=8) (actual time=295.161..296.710 rows=21 loops=1)

  Group Key: tb_person.department_id

  ->  Nested Loop  (cost=6295.27..9269.14 rows=17 width=8) (actual time=295.067..296.616 rows=53 loops=1)

        ->  Finalize GroupAggregate  (cost=6290.54..6291.07 rows=21 width=8) (actual time=294.975..295.122 rows=21 loops=1)

              Group Key: tb_person_1.department_id

              ->  Sort  (cost=6290.54..6290.65 rows=42 width=8) (actual time=294.964..295.022 rows=63 loops=1)

                    Sort Key: tb_person_1.department_id

                    Sort Method: quicksort  Memory: 27kB

                    ->  Gather  (cost=6285.00..6289.41 rows=42 width=8) (actual time=294.303..294.874 rows=63 loops=1)

                          Workers Planned: 2

                          Workers Launched: 2

                          ->  Partial HashAggregate  (cost=5285.00..5285.21 rows=21 width=8) (actual time=209.180..209.203 rows=21 loops=3)

                                Group Key: tb_person_1.department_id

                                ->  Parallel Seq Scan on tb_person tb_person_1  (cost=0.00..4660.00 rows=125000 width=8) (actual time=0.015..106.866 rows=100000 loops=3)

        ->  Bitmap Heap Scan on tb_person  (cost=4.73..141.78 rows=2 width=12) (actual time=0.031..0.056 rows=3 loops=21)

              Recheck Cond: (birthday = (min(tb_person_1.birthday)))

              Filter: (tb_person_1.department_id = department_id)

              Rows Removed by Filter: 39

              Heap Blocks: exact=859

              ->  Bitmap Index Scan on idx_tb_person_birthday  (cost=0.00..4.73 rows=41 width=0) (actual time=0.011..0.011 rows=42 loops=21)

                    Index Cond: (birthday = (min(tb_person_1.birthday)))

Planning time: 0.303 ms

Execution time: 303.298 ms

 

查看第二种方法的查询计划：

explain analyze

select (array_agg(person_id order by birthday))[1] from tb_person group by department_id

 

结果如下：

GroupAggregate  (cost=0.42..23822.21 rows=21 width=8) (actual time=27.898..1042.577 rows=21 loops=1)

  Group Key: department_id

  ->  Index Scan using idx_tb_person_department_id on tb_person  (cost=0.42..22321.95 rows=300000 width=12) (actual time=0.022..465.663 rows=300000 loops=1)

Planning time: 0.175 ms

Execution time: 1050.754 ms

 

查看第三种方法的查询计划：

explain analyze

SELECT distinct on (a.department_id) person_id from tb_person inner join

(

select min(birthday) as birthday, department_id from tb_person group by department_id

) a using(birthday,department_id) order by a.department_id;

 

结果如下：

Unique  (cost=6295.27..9269.19 rows=17 width=8) (actual time=294.638..296.429 rows=21 loops=1)

  ->  Nested Loop  (cost=6295.27..9269.14 rows=17 width=8) (actual time=294.634..296.344 rows=53 loops=1)

        ->  Finalize GroupAggregate  (cost=6290.54..6291.07 rows=21 width=8) (actual time=294.538..294.702 rows=21 loops=1)

              Group Key: tb_person_1.department_id

              ->  Sort  (cost=6290.54..6290.65 rows=42 width=8) (actual time=294.506..294.586 rows=63 loops=1)

                    Sort Key: tb_person_1.department_id

                    Sort Method: quicksort  Memory: 27kB

                    ->  Gather  (cost=6285.00..6289.41 rows=42 width=8) (actual time=293.917..294.438 rows=63 loops=1)

                          Workers Planned: 2

                          Workers Launched: 2

                          ->  Partial HashAggregate  (cost=5285.00..5285.21 rows=21 width=8) (actual time=211.328..211.351 rows=21 loops=3)

                                Group Key: tb_person_1.department_id

                                ->  Parallel Seq Scan on tb_person tb_person_1  (cost=0.00..4660.00 rows=125000 width=8) (actual time=0.015..106.619 rows=100000 loops=3)

        ->  Bitmap Heap Scan on tb_person  (cost=4.73..141.78 rows=2 width=12) (actual time=0.036..0.062 rows=3 loops=21)

              Recheck Cond: (birthday = (min(tb_person_1.birthday)))

              Filter: (tb_person_1.department_id = department_id)

              Rows Removed by Filter: 39

              Heap Blocks: exact=859

              ->  Bitmap Index Scan on idx_tb_person_birthday  (cost=0.00..4.73 rows=41 width=0) (actual time=0.013..0.013 rows=42 loops=21)

                    Index Cond: (birthday = (min(tb_person_1.birthday)))

Planning time: 0.298 ms

Execution time: 304.337 ms

 

不出所料的是第二种方法的性能还是最差的，因为生日在同一天的人很多。但令人惊讶的但第一种，第三种方法性能相差无几，他们的执行计划也几乎相同。尽管第三种方法虽然使用了 distinct on … order by。因此distinct on … order by语句的性能并不总是低于 group by语句。

Postgresql limit sql性能分析
MyySophia的博客
04-20 2381
问题描述 分析 表的信息 估算cost start-up cost run cost 执行计划 实际执行时间 从内核视角来分析 解决方案 写在最后 Coding过程中经常会写SQL语句，有时写的SQL出现慢查询而被DBA鄙视。 今天我们一起从使用者，DBA，内核开发三个不同角度来分析和解决一个SQL性能问题，来重新认识逻辑优化与物理优化。 ..
【0019】 深入分析PostgreSQL中VACUUM 与 VACUUM FULL机制
Postgres 数据库内核开发工程师
09-27 1699
文章目录1. VACUUM概述2. VACUUM分类2.1 2.2 1. VACUUM概述 VACUUM是PostgreSQL中的一个辅助进程，它主要负责完成两个主要任务：删除死元组(Dead Tuples)和冻结事务ID(Freezing Tansaction Ids)。本文主要分享VACUUM删除死元组的具体过程以及底层实现；而对于另一个“冻结事务ID”任务则将单独用一篇文章来介绍，因为它需要结合PostgreSQL的 多版本并发控制 (Multi-Version Concurrency Contro
PostgreSQL limit
weixin_30376509的博客
07-06 1535
1. select * from my_table limit 10 offset 5　　 数据是从第0条开始的，所以这句代码表示从 第六条数据开始的10行数据。 2.select * from my_table limit 10 　不带 offset 时，表示查询10条数据。 转载于:https://www.cnblogs.com/junG-Fjw/p/11141846.htm...
postgresql中的order by、limit、offset偏移
10-18 4518
首先创建users表 create table users( id serial primary key, player varchar(255) not null, score real, team varchar(255) ) 插入记录并select insert into users(player,score,team) values ('库里',28.3,'勇士'), ('哈登',30.2,'火箭'), ('阿杜',25.6,'勇士'), ('阿詹',27.8,'骑士.
PostgreSQL 优化器案例之 - order by limit 索引选择问题
weixin_33910137的博客
10-05 4192
标签 PostgreSQL , limit , order by , 优化器 , 选择性 , 相关性 , 数据存储顺序 , 目标数据存储顺序 背景 当我们在执行一个这样的SQL时，假如有这样几个索引(c1,c2) (id)，数据库到底该用哪个索引呢？ explain select * from tbl where c1=200 and c2=200 ...
PostgreSQL 神奇的limit
Focus on PostgreSQL
12-23 3755
最近碰到这样一个SQL引发的性能问题，SQL内容大致如下： SELECT * FROM t1 WHERE id = 999 AND (case $1 WHEN 'true' THEN info = $2 ELSE info = $3 end) limit 1; 开发反应这条SQL加上limit 1之后过了一段时间从原先的索引扫描变成了全表扫描，一个简单的limit 1为何会产生这样的影响，我只取一条数据不是应该更快了吗？ 下面我们就从这条SQL开始说起。 首先我们先看下这个表结构，
PostgreSQL安装以及和mysql的对比
奋斗的博客
08-29 509
PostgreSQL 研究安装整理 前言 本期文章中主要说明的内容有： PostgreSql的使用有点 PostgreSql基本查询语法介绍（含测试截图） PostgreSql和mysql对比 PostgreSQL 是一个免费的对象-关系数据库服务器(ORDBMS)，在灵活的BSD许可证下发行。 PostgreSQL 开发者把它念作 post-gress-Q-L。 PostgreSQL 的 Slogan 是 “世界上最先进的开源关系型数据库”。 PostSQL前言简介安装PostgreSQL安装成功但连
怎样优化 PostgreSQL 中对复杂的聚合函数和窗口函数组合的查询？
2401_86074221的博客
07-15 671
在本文中，我们探讨了如何优化 PostgreSQL 中对复杂的聚合函数和窗口函数组合的查询。我们首先了解了聚合函数和窗口函数的基本概念，然后介绍了优化查询的基本原则，包括合理选择索引、避免不必要的计算和优化查询语句的结构。接着，我们详细介绍了一些具体的优化技巧，如使用合适的聚合函数和窗口函数、利用索引提高查询性能、避免全表扫描、分解复杂查询和使用临时表。最后，我们通过一个实际案例分析，展示了如何应用这些优化技巧来提高查询的性能。
PostgreSQL——查询优化——生成优化计划1
weixin_47373497的博客
12-18 1020
2021SC@SDUSC 目录概述生成可优化的MIN/MAX聚集计划preprocess_minmax_aggregates函数生成普通计划扫描计划——顺序扫描create_seqscan_plan函数执行流程create_seqscan_plan函数create_seqscan_plan函数返回的结构体——Scan连接计划——嵌套循环连接create_nestloop_plan函数执行流程create_nestloop_plan函数create_nestloop_plan函数最后返回的结构体——NestL
PostgreSQL数据库从入门到精通系列之七：安装时序数据库TimescaleDB的详细步骤
zhengzaifeidelushang的博客
10-24 1665
PostgreSQL数据库从入门到精通系列之七：安装时序数据库TimescaleDB的详细步骤
postgres及min数据库的的表结构及触发器.txt
03-07
SET statement_timeout = 0; SET lock_timeout = 0; SET idle_in_transaction_session_timeout = 0; SET client_encoding = 'UTF8'; SET standard_conforming_strings = on; SET check_function_bodies = false; SET client_min_messages = warning; SET row_security = off;mintaka数据库的的表结构及触发器.txt
Postgresql中order by limit 索引选择错误导致查询很慢
魂醉的一亩二分地
10-12 4231
开发今天发来一条SQL,说执行很慢，出不来结果，如下： select id, user_id, k_money_value, channel, status, add_time, note from hist_kmoney_record where user_id=133423946 order by id desc limit 10; 表大小，记录数，索引信息如下: melotpay=# select count(id) from hist_kmoney_record ; count --
POSTGRESQL SQL 语句案例，一场由LIMIT 1 引发的“奇怪异像”
sql server的专栏
03-06 1014
开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群。最近一段工作很少优化SQL ，实际上7-8年前的确有一段疯狂优化的“美好时光”。最近一个同事提出一个问题，他的一个POSTGRESQL 的SQL...
PostgreSQL LIMIT子句
ling811的专栏
05-26 3158
PostgreSQL的LIMIT子句是用来限制由SELECT语句返回的数据量。 语法: LIMIT子句的SELECT语句的基本语法如下： SELECT column1, column2, columnN FROM table_name LIMIT [no of rows] 以下是LIMIT子句时使用OFFSET子句的语法： SELECT column1, colu
postgresql sum max min
马金波
06-11 1386
创建表 create table(empno smallint, ename varchar(20), job varchar(20), mgr smallint, hiredate date, sal bigint, comm bigint, deptno smallint); insert into jinbo.employee(empno,ename,job, mgr, hiredate,...
SQL ORDER BY排序
weixin_43731793的博客
06-06 290
1、排序 SELECT * FROM myguests ORDER BY firstname;
PostgreSQL limit 语法
qq_35987023的博客
10-11 5234
其中，SELECT 语句用于指定要查询的列和数据表，LIMIT 用于指定查询结果的行数。如果不指定 LIMIT，则会返回所有满足条件的行。需要注意的是，在使用 LIMIT 时，应避免仅按照默认排序顺序进行查询，否则可能会得到不稳定的结果。如果需要按照指定的排序顺序进行查询，应首先使用 ORDER BY 子句明确指定排序规则。除了可以指定一个整数值外，LIMIT 还可以使用一个 OFFSET 参数指定查询结果的起始位置。例如，LIMIT 10 OFFSET 5 表示从第 6 行开始，返回 10 行结果。
sql orderby limit 1 得到的结果不一样
sinat_26566137的博客
07-20 5209
sql orderby limit 1 得到的结果有时候会不一样； 原因是基于非唯一字段的排序 结果集是不确定的，需要再增加一个唯一字段一起来做排序这样就会保证结果一致了； SELECT sub_rank,shixin_prob FROM shixin_offline_predict_results WHERE shixin_prob < 0.5 AND big_hy_name ='...
mysql order by limit 1 和max的比较
hammring的博客
10-14 5725
在一个数据的需求中，去用order by+limit和 max两种方式求数据的最大值时，发现在同一过滤条件下order by limit执行速度要比max快。然后从一下两个角度对问题进行来思考。 1.查看执行计划，在mysql中发现两者之间的时间是一致的 2.order by和where的执行顺序是否是先做的order by,而后一条sql语句需要先过滤导致执行速度很慢。 tips:该问题暂时未解决。 ...
pg 运算max和min速度差别很大
最新发布
03-22
### PostgreSQL 中 MAX 和 MIN 运算性能差异的原因及优化 #### 性能差异原因分析 ... SELECT DISTINCT column_name FROM table_name ORDER BY column_name DESC LIMIT 1 ) AS subquery; ``` ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值