已经索引绑定，但是不生效

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

image
image3306×524 98.9 KB

已经进行了绑定
但是还是发生了跑偏索引
image
image2826×1788 389 KB

image
image2790×1386 309 KB

当时与这个有关的是正在进行表分析。

高版本中，会不会产生绑定了索引之后，发生表分析的过程中还是会跑错索引的问题。

2

你绑定的 sql 没看到hint是怎么写的。你验证过吗？绑定完后试试是不是生效了。
我们遇到过绑定后用户的 sql 稍微变了一点，没法命中绑定，看起来是失效了，实际上就不是同一个sql。

建议你仔细检查下。

另外 dashboard 上面，sql 分析那里能看到多个执行计划的话，可以直接通过网页选择绑定哪一个。

3

表分析那个表里没有这条慢SQL的记录。

4

要么再仔细检查检查？我不确定大小写是不是有区别，知道的人可以回一下。我之前绑定过一个，检查着看是没区别，但是好像是有个字段大小写不一样。

5

嗯，只能这样了，之前也遇到过这种情况。

6

有下面的 case ，使用 hint 但是优化器没走改索引的情况，但是下面有对应 warning ，你也可以自己 check 下，下面应该是 global stats 没有正确加在的原因。MySQL [test]> explain analyze select /*+ use_index(t,pms_bill_detail_acquirer_unp_t_l_idx3) */ * from pms_bill_detail_acquirer_unp_t t where bill_date=‘20240209’ and partition_id=56 and third_party_pid=‘UZJXTHO’ and card_acceptor_key=‘2089991527100F2’;
±-------------------------------±--------±--------±----------±-------------------------------------------------------------------------------------------------------------------------------------±---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±----------------------------------------------------------------------------------------------------------------------------±----------±-----+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
±-------------------------------±--------±--------±----------±-------------------------------------------------------------------------------------------------------------------------------------±---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±----------------------------------------------------------------------------------------------------------------------------±----------±-----+
| IndexLookUp_14 | 0.00 | 0 | root | | time:857.8µs, loops:1 | | 255 Bytes | N/A |
| ├─IndexRangeScan_12(Build) | 0.00 | 0 | cop[tikv] | table:t, partition:P_LT_57, index:pms_bill_detail_acquirer_unp_t_l_idx4(bill_date, partition_id, third_party_pid, card_acceptor_key) | time:708.6µs, loops:1, cop_task: {num: 1, max: 640.8µs, proc_keys: 0, rpc_num: 1, rpc_time: 603.4µs, copr_cache_hit_ratio: 0.00, distsql_concurrency: 15}, tikv_task:{time:0s, loops:1}, scan_detail: {total_keys: 1, get_snapshot_time: 34.4µs, rocksdb: {block: {cache_hit_count: 4}}} | range:[“20240209” 56 “UZJXTHO” “2089991527100F2”,“20240209” 56 “UZJXTHO” “2089991527100F2”], keep order:false, stats:pseudo | N/A | N/A |
| └─TableRowIDScan_13(Probe) | 0.00 | 0 | cop[tikv] | table:t, partition:P_LT_57 | | keep order:false, stats:pseudo | N/A | N/A |
±-------------------------------±--------±--------±----------±-------------------------------------------------------------------------------------------------------------------------------------±---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±----------------------------------------------------------------------------------------------------------------------------±----------±-----+
3 rows in set, 1 warning (0.01 sec)

MySQL [test]> show warnings;
±--------±-----±----------------------------------------------------------------------------------+
| Level | Code | Message |
±--------±-----±----------------------------------------------------------------------------------+
| Warning | 1105 | disable dynamic pruning due to pms_bill_detail_acquirer_unp_t has no global stats |
±--------±-----±----------------------------------------------------------------------------------+
1 row in set (0.00 sec)

7

谢谢，我们这边还是老的语句没加hint

8

图片里没有看到binding应该走的索引，
1、status in的values如果是1个不会走这个binding（参考https://github.com/pingcap/tidb/issues/44298）
2、检查一下客户端的字符集与binding sql的字符集是否一致。

9

我也是绑定索引，但是还是会有少量sql不按我绑定的索引走，大概占比5%

10

你的截图里面没有看到有hint
CREATE GLOBAL BINDING for SELECT * FROM t2 as 别名HERE a > 1 AND b = 1
USING SELECT /*+ use_index(‘别名’, ‘索引名称’) */ * FROM t2 as 别名 WHERE a > 1 AND b = 1;