【 TiDB 使用环境】生产环境 /测试/ Poc 生产环境
【 TiDB 版本】v5.4.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】使用索引反而性能变得很糟糕
【资源配置】50core、384GB
【附件：截图/日志/监控】
TableFullScan 反而比IndexRangeScan 效率要高很多，不清楚是否大数据量都不能建索引了
执行计划：
一半左右的数据量还走啥索引。。。。tidb优化器自动指定走索引了？
是的，优化器根据数据量走的索引，但是如果我的时间范围变大，就走TableFullScan，也就是第二张图，性能更好
数据量大，回表效率太低了，不如全表来的快
那就是说大数据量就不适合建索引？我们建索引不就是为了提交查询效率么
索引是为了避免全表扫描的，访问索引再访问表是有额外开销的。如果访问的数据量占表比例太大，走全表扫描更快。一般查询的数据走索引应该不到全表的10%
1 个赞
如果只访问表少数列，可以考虑用tiflash,这样只对部分列全扫
1 个赞
不是说大数据量不适合建索引！建索引就是为了能快速的从大表里面找到满足条件的数据，但是如果查询条件过滤不了多少数据，那用索引就不一定快了。如果你每次查询都要返回这个表的大量数据，那索引意义就不大了。
对啊，我这个业务就是只有部分列呢，访问的时候可能有大量的查询也可能有少量的查询的场景，这个感觉优化器应该去做这个事，比如你提的少于10%走IndexRangeScan，否则走TableFullScan
这个感觉应该是优化器的工作，对于查询来说，只能选择不加索引了，因为既有大量的scan和少量scan的需求，折中的话就不要加index了
不了解你实际场景，为啥折中了是不加索引。一般情况是加索引，特殊的sql加hint固定执行计划。
额，加了索引，优化器走了IndexRangeScan了啊，效率慢了呢？所以折中只能不加了
我发帖子的目的是想探讨什么情况加索引，目前来看优化器需要优化。
因为我们是业务的固定sql，hint只能优化具体场景的sql，没办法通用化
看一下这表的统计信息是不是不准了
SHOW stats_healthy WHERE db_name=‘’ AND table_name=‘’;
只能做做表分析再试试了
你是不是没收集统计信息？
把表结构、sql、执行计划发出来看看
sql:
SELECT
info_id, COUNT(*) AS log_call_event_count, MAX(log_test.error_message) as error_message FROM
sy_db.log_test
where log_ds >= ‘2023-07-03’ AND log_ds <= ‘2023-07-04’ AND log_ts >= ‘2023-07-03 15:00:00’ and log_ts <= ‘2023-07-04 15:00:00’
group by info_id
执行计划是第一张图
- tidb_index_lookup_size：控制索引查找过程中的分块大小，默认为 20000。如果查询语句匹配的行数较多，则可以适当增加这个参数的值，以减少分块的次数。
- tidb_index_scan_batch_size：控制索引扫描过程中的批处理大小，默认为 256。如果批处理大小过小，则会导致频繁的网络传输，从而影响查询性能。
- tidb_max_chunk_size：控制返回结果集的最大块大小，默认为 32MB。如果查询语句返回的结果集较大，则可以适当增加这个参数的值，以减少块的数量。
sql:
SELECT
info_id, COUNT(*) AS log_call_event_count, MAX(log_test.error_message) as error_message FROM
sy_db.log_test
where log_ds >= ‘2023-07-03’ AND log_ds <= ‘2023-07-04’ AND log_ts >= ‘2023-07-03 15:00:00’ and log_ts <= ‘2023-07-04 15:00:00’
group by info_id
执行计划是第一张图
是的，有一些分区healthy不是100呢？
收集统计信息