某个低分辨率type 数据量小于limit数据的时候性能特别差

[zhengjunbo]

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

• 【TiDB 版本】：4.0.0
• 【问题描述】： 某个低分辨率type 数据量小于limit数据的时候性能特别差，比如select * from table where type=0 limit 10。当数据量低于10的时候，会导致一条慢sql。

请教一下TiDB如何维持索引的有序性，在TiDB原理层面没有看到呢

[来了老弟]

hi，type=0 的筛选出来的 count 为 5 但是小于 limit 10，此时效率会很差？可能需要在明确下问题。

返回下 explain select * from table where type=0 limit 10;

希望上传下 table 的表结构，这边复现一下。

@coolboydan

请教一下TiDB如何维持索引的有序性，在TiDB原理层面没有看到呢

此问题，可以看下 tidb in action 中关于 kv 编码和映射的介绍
https://book.tidb.io/session1/chapter3/tidb-kv-to-relation.html

[zhengjunbo]

好的，感谢，这个问题是因为该字段没索引导致。和select * from table where create_time <‘2020-6-28’ and type=0 limit 10 这种top N问题扫表的混淆了。以为是这类慢sql。

[来了老弟]

@coolboydan

select * from table where create_time <‘2020-6-28’ and type=0 limit 10 这种top N问题扫表的混淆

所以这个问题是什么意思，当 create time 是索引列，limit 10，也不会扫表，是个indexRangeScan。

例子：

MySQL [test]> explain select * from sbtest1 where k <= 15671 limit 10;              
+--------------------------------+---------+-----------+-----------------------------+--------------------------------------+
| id                             | estRows | task      | access object               | operator info                        |
+--------------------------------+---------+-----------+-----------------------------+--------------------------------------+
| IndexLookUp_20                 | 10.00   | root      |                             | limit embedded(offset:0, count:10)   |
| ├─Limit_19(Build)              | 10.00   | cop[tikv] |                             | offset:0, count:10                   |
| │ └─IndexRangeScan_17          | 12.50   | cop[tikv] | table:sbtest1, index:k_1(k) | range:[-inf,15671], keep order:false |
| └─TableRowIDScan_18(Probe)     | 10.00   | cop[tikv] | table:sbtest1               | keep order:false, stats:pseudo       |
+--------------------------------+---------+-----------+-----------------------------+--------------------------------------+
4 rows in set (0.00 sec)

MySQL [test]> desc sbtest1;
+-------+-----------+------+------+---------+----------------+
| Field | Type      | Null | Key  | Default | Extra          |
+-------+-----------+------+------+---------+----------------+
| id    | int(11)   | NO   | PRI  | NULL    | auto_increment |
| k     | int(11)   | NO   | MUL  | 0       |                |
| c     | char(120) | NO   |      |         |                |
| pad   | char(60)  | NO   |      |         |                |
+-------+-----------+------+------+---------+----------------+
4 rows in set (0.00 sec)

[zhengjunbo]

explain 
SELECT * 
FROM uoc_audit_message   
 where CREATED_SYS_TM < DATE_SUB(NOW(),INTERVAL 30 MINUTE)    
AND STATUS = 0  
  LIMIT 0, 100;

扫了几千万数据。这种性能比较差。准确的说是扫索引。

[来了老弟]

这边看到的也是 indexrangescan ，速度就取决于数据量了。但是也是 range 扫描。不是 full scan，此在 tidb 有明确区分

[zhengjunbo]

其实跟数据量也不完全相关，比如 type=0有很多，那么这条sql就很快，但是如果type=0很少，就是慢sql了但是不会太慢。秒级的

[来了老弟]

那可以理解为，type=0 的筛选度很低，譬如布尔字段加索引的收益就不是很高，也不是很稳定，可能走得是 table full scan，但是需要当时的 explain 作为佐证，仅为猜测。