range分区表order by 索引列limit 1 长时间未返回

🌞 建议反馈 产品缺陷
18

这个表一直有数据在写入，目前有180亿行左右。

  1. 相关列的表结构和索引如下：
    CREATE TABLE logoutrole (
    doc_id varchar(255) NOT NULL DEFAULT ‘’,
    dt timestamp NOT NULL ,
    updatetime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘更新时间’,
    PRIMARY KEY (dt,doc_id) /*T![clustered_index] NONCLUSTERED */,
    KEY updatetime (updatetime)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin /*T![placement] PLACEMENT POLICY=storeonssd */
    PARTITION BY RANGE (UNIX_TIMESTAMP(dt))
    (PARTITION p20210601 VALUES LESS THAN (1622563200) /*T![placement] PLACEMENT POLICY=storeonhdd */,
    PARTITION p20210602 VALUES LESS THAN (1622649600) /*T![placement] PLACEMENT POLICY=storeonhdd */,
    …
    PARTITION p20210805 VALUES LESS THAN (1628179200) /*T![placement] PLACEMENT POLICY=storeonhdd */,
    PARTITION p20210806 VALUES LESS THAN (1628265600),
    …
    PARTITION p20220810 VALUES LESS THAN (1660147200),
    PARTITION p20220811 VALUES LESS THAN (1660233600),
    PARTITION p20220812 VALUES LESS THAN (1660320000))
    1 row in set (0.00 sec)

  2. 是的，不desc 执行耗时也是很久，原因还是因为执行计划里有 TableFullScan_12

    image
    image1122×222 9.05 KB

  3. dt是 date time的含义，是时间。
    我们不能确定当前最新的数据是不是已经在p20220701分区里了，用我们的案例来说，我们一次性建立了20210601至20220801的全部分区（以后有个定期任务每天新增一个分区），然后有个补数据的任务在往表写数据，从20210601开始追直到追到当前时间，此时我们想看它已经追到哪个时间点了，就执行了 order by updatetime或dt desc limit 1 这个语句来查看。

所以，就是在执行这个 order by updatetime或dt limit 1时发现执行很慢的问题