Strongly recommend GA for global secondary indexes. I conducted a sysbench test with 256 concurrent connections on a single table (the same set of data replicated 3 times), and the efficiency difference between regular tables and partitioned tables is significant.
TiDB supports complete secondary indexes, and they are global indexes, which can optimize many queries through indexes. Proper use of secondary indexes is very important for business, and many experiences from MySQL are still applicable in TiDB. However, TiDB also has some unique characteristics that need attention. This section mainly discusses some considerations for using secondary indexes in TiDB. TiDB Best Practices | PingCAP Documentation Center
The original poster is referring to the global secondary index of partitioned tables, which can significantly speed up queries that “cannot use the partition key but can hit the regular secondary index.” Otherwise, such queries would have to scan the secondary index of all partitions each time, resulting in a significant performance loss.
Secondary indexes refer to the performance-exploding ClickHouse from the battle-hardened nation MergeTree | ClickHouse Docs. Bloom filters can filter out data that definitely does not exist, but when the distinct value count of the prefix column is very large, the “skipping” acceleration effect on subsequent columns’ filter conditions becomes very weak. Other acceleration optimization query methods are needed. I hope TiDB can be polished better, more refined, and more excellent .
Some features in the roadmap can be put on hold, and performance improvement development should be prioritized. Even if version 7.5 is released together with partitioned KV, it is still an option.