与单列排序相比，两列排序非常慢

时间差异的原因是由于几个事实：

1. 您的查询没有WHERE过滤掉要检索的结果的子句。
2. 查询的速度取决于您确实有一个LIMIT子句这一事实。
3. 如果计划程序可以找到一个索引，通过它可以按照您指定的顺序ORDER BY检索查询的行，它将开始一个接一个地选择它们，直到它读取 100（您的LIMIT子句指定的数字。索引，如果它是多列，则需要具有相同的列，以相同的顺序，并具有相同的 ASC、DESC 排序方向（或全部颠倒）。
4. 如果规划器不能有一个索引来完成这个角色，它必须执行一个排序步骤，将所有行按顺序放在一个（临时的、虚拟的）表中，然后检索前 100 行。

需要检索所有数据（不仅仅是已经排序的 100 行），必须将所有数据连接起来，然后进行排序步骤，这才是导致性能出现如此大差异的原因。使用explain.depesz.com可以清楚地看到这一点。

在此处的dbfiddle查找您的场景模拟，涵盖并解释了不同的案例，并考虑了来自 @ypercube 的建议以用于另一个索引。另请注意，您的某些索引是多余的。

适用于您的场景的 DDL，以及一些模拟数据：

CREATE TABLE api_meter
(
    id INTEGER PRIMARY KEY
) ;
INSERT INTO 
    api_meter
    (id)
SELECT
    generate_series(1, 83) ;

...对于保存你的meter_data的表

CREATE TABLE api_meterdata
(
    id serial /* integer */ PRIMARY KEY,
    meter_id integer REFERENCES api_meter(id),
    datetime timestamp NOT NULL default now()
) ;

-- The PK will have made an implicit index ON (id)

-- Index on (meter_id, datetime); which is probably the *NATURAL KEY*
CREATE UNIQUE INDEX api_meterdata_meter_id_datetime_unique 
    ON api_meterdata (meter_id, datetime) ;

-- The following index is redundant, the column meter_id is already the first in
-- the previous one.
-- CREATE INDEX api_meterdata_meter_id_idx 
--    ON api_meterdata (meter_id) ;

CREATE INDEX api_meterdata_datetime_idx 
    ON api_meterdata (datetime) ;

...一些模拟数据（648001 行，使其真实）。数据少于您拥有的数据，但是如果我尝试添加更多数据，DBFiddle 会达到其极限

INSERT INTO 
    api_meterdata
    (meter_id, datetime)
SELECT
    random()*82+1, d
FROM
    generate_series(timestamp '2017-01-01', timestamp '2017-01-31', 
                    interval '4 second') AS s(d);

-- Make sure statistics are good
ANALYZE api_meterdata;
ANALYZE api_meter;

分析您的第一个查询

-- This query doesn't have a WHERE clause, so, indexes will be used based on 
-- ORDER BY + LIMIT (and, eventually, column coverage)
--
-- * The index helping this case is the one corresponding to the PK of 
--   api_meter_data, used in DESC order
-- * A second index will help: the one used for the JOIN condition
-- * How does postgresql choose to JOIN will depend on specific data values 
--   distribution, sizes, etc.
EXPLAIN ANALYZE
SELECT 
    api_meterdata.id, api_meterdata.meter_id, api_meterdata.datetime, 
    api_meter.id 
FROM 
    api_meterdata 
    INNER JOIN api_meter ON ( api_meterdata.meter_id = api_meter.id ) 
ORDER BY 
    api_meterdata.id DESC 
LIMIT 100;

| 查询计划 |
| :------------------------------------------------ -------------------------------------------------- -------------------------------------------------- ------------ |
| 限制（成本=0.57..20.71 行=100 宽度=20）（实际时间=0.033..0.188 行=100 循环=1）|
| -> 嵌套循环（成本=0.57..130514.61 行=648001 宽度=20）（实际时间=0.031..0.175 行=100 循环=1）|
| -> Index Scan Backward using api_meterdata_pkey on api_meterdata (cost=0.42..20342.44 rows=648001 width=16) (实际时间=0.023..0.038 rows=100 loops=1) |
| -> Index Only Scan using api_meter_pkey on api_meter (cost=0.14..0.16 rows=1 width=4) (实际时间=0.001..0.001 rows=1 loops=100) |
| 指数条件：（id = api_meterdata.meter_id）|
| 堆取数：100 |
| 规划时间：0.331 ms |
| 执行时间：0.216 ms |

第二次查询分析

-- This query doesn't have either a WHERE clause, so, indexes will be used 
-- based on ORDER BY + LIMIT (and, eventually, column coverage).
-- * The index helping this case is the one corresponding to 
--   ON api_meterdata (datetime), because that's the only column used in the
--   ORDER BY.
-- * A second index will help: the one used for the JOIN condition
-- * How does postgresql choose to JOIN will depend on specific data values 
--   distribution
EXPLAIN ANALYZE 
SELECT 
    api_meterdata.id, api_meterdata.meter_id, api_meterdata.datetime, 
    api_meter.id 
FROM 
    api_meterdata 
    INNER JOIN api_meter ON ( api_meterdata.meter_id = api_meter.id ) 
ORDER BY 
    api_meterdata.datetime ASC 
LIMIT 100;

| 查询计划 |
| :------------------------------------------------ -------------------------------------------------- -------------------------------------------------- ---------- |
| 限制（成本=0.57..20.71 行=100 宽度=20）（实际时间=0.041..0.201 行=100 循环=1）|
| -> 嵌套循环（成本=0.57..130514.61 行=648001 宽度=20）（实际时间=0.040..0.182 行=100 循环=1）|
| -> 在 api_meterdata 上使用 api_meterdata_datetime_idx 进行索引扫描（成本=0.42..20342.44 行=648001 宽度=16）（实际时间=0.036..0.048 行=100 循环=1） |
| -> Index Only Scan using api_meter_pkey on api_meter (cost=0.14..0.16 rows=1 width=4) (实际时间=0.001..0.001 rows=1 loops=100) |
| 指数条件：（id = api_meterdata.meter_id）|
| 堆取数：100 |
| 规划时间：0.113 ms |
| 执行时间：0.224 ms |

分析您的第 3 个查询，没有和使用建议的索引

-- This query doesn't have either a WHERE clause.
-- Again indexes will be used based on ORDER BY + LIMIT 
-- * The index that would mostly he,p this case would be one with 
--   (datetime ASC, id DESC). 
--   But there's not in place. An index with (datetime) will not be good enough,
--   because the second condition in ORDER BY will need to be evaluated before
--   the LIMIT can be computed. That is a SORT will be needed 
-- * A second index will help: the one used for the JOIN condition
-- * How does postgresql choose to JOIN will depend on specific data values 
--   distribution, as always.
--
-- This query performs MUCH WORSE than the previous one.

EXPLAIN ANALYZE 
SELECT api_meterdata.id, api_meterdata.meter_id, api_meterdata.datetime, api_meter.id 
FROM api_meterdata 
    INNER JOIN api_meter ON ( api_meterdata.meter_id = api_meter.id ) 
ORDER BY api_meterdata.datetime ASC, api_meterdata.id DESC 
LIMIT 100;

| 查询计划 |
| :------------------------------------------------ -------------------------------------------------- ---------------------------------- |
| 限制（成本=43662.02..43662.27 行=100 宽度=20）（实际时间=377.202..377.222 行=100 循环=1） |
| -> 排序（成本=43662.02..45282.03 行=648001 宽度=20）（实际时间=377.202..377.210 行=100 循环=1）|
| 排序键：api_meterdata.datetime、api_meterdata.id DESC |
| 排序方法：top-N heapsort 内存：32kB |
| -> Hash Join (cost=2.87..18895.89 rows=648001 width=20) (实际时间=0.034..270.809 rows=648001 loops=1) |
| 哈希条件：（api_meterdata.meter_id = api_meter.id）|
| -> Seq Scan on api_meterdata (cost=0.00..9983.01 rows=648001 width=16) (实际时间=0.007..75.104 rows=648001 loops=1) |
| -> 哈希（成本=1.83..1.83 行=83 宽度=4）（实际时间=0.023..0.023 行=83 循环=1）|
| 存储桶：1024 批次：1 内存使用量：11kB |
| -> Seq Scan on api_meter (cost=0.00..1.83 rows=83 width=4) (实际时间=0.002..0.009 rows=83 loops=1) |
| 规划时间：0.123 ms |
| 执行时间：377.251 毫秒 |

索引创建（和删除多余的）

-- We DROP one of the indexes... which will become redundant
-- CREATE INDEX api_meterdata_datetime_idx ON api_meterdata (datetime) ;
DROP INDEX api_meterdata_datetime_idx ;

-- And create one with two columns, and ordered in the same fashion need by the query
CREATE INDEX api_meterdata_datetime_idx 
    ON api_meterdata (datetime ASC, id DESC) ;

新场景下查询分析

--
-- We put in place the required index
--
-- This query is again fast, and has an execution plan equivalent in 
-- structure to the two first ones. No SORT phase is needed, because rows are
-- already retrieved in the correct order, and once the LIMIT is reached, no
-- more rows are read from (disk/cache)
--

EXPLAIN ANALYZE 
SELECT 
    api_meterdata.id, api_meterdata.meter_id, api_meterdata.datetime, 
    api_meter.id 
FROM 
    api_meterdata 
    INNER JOIN api_meter ON ( api_meterdata.meter_id = api_meter.id ) 
ORDER BY 
    api_meterdata.datetime ASC, api_meterdata.id DESC 
LIMIT 100;

| 查询计划 |
| :------------------------------------------------ -------------------------------------------------- -------------------------------------------------- ---------- |
| 限制（成本=0.57..21.86 行=100 宽度=20）（实际时间=0.019..0.229 行=100 循环=1）|
| -> 嵌套循环（成本=0.57..137986.99 行=648001 宽度=20）（实际时间=0.018..0.214 行=100 循环=1）|
| -> 在 api_meterdata 上使用 api_meterdata_datetime_idx 进行索引扫描（成本=0.42..27814.81 行=648001 宽度=16）（实际时间=0.013..0.040 行=100 循环=1）|
| -> Index Only Scan using api_meter_pkey on api_meter (cost=0.14..0.16 rows=1 width=4) (实际时间=0.001..0.001 rows=1 loops=100) |
| 指数条件：（id = api_meterdata.meter_id）|
| 堆取数：100 |
| 规划时间：0.218 ms |
| 执行时间：0.262 ms |