山维空间
·
一次 TiDB 向量查询优化实战：
💡
原文中文，约7000字，阅读约需17分钟。
📝
内容提要
本文讨论了TiDB向量查询的优化实践，通过将查询分为两阶段（先获取TopN ID和距离，再回表获取详情），显著降低了RU和耗时。虽然将locale统一为小写和使用locale = ?是必要的，但未能使查询走索引路径。最终优化方案强调了数据规范化和两阶段查询的重要性。
🎯
关键要点
-
将 documents.locale 全部统一成小写，并将查询条件改为 locale = ? 是必要的，但不是主要优化来源。
-
真正显著降低 RU 和耗时的优化方案是将查询改为两阶段：先获取 TopN ID 和距离，再回表获取详情。
-
在测试中，LOWER(locale) 确实导致查询计划变差，影响了过滤条件的下推。
-
idx_locale 并未使查询走到索引路径，仍然执行全表扫描。
-
two-phase 查询显著降低了 RU 和耗时，证明了其有效性。
-
数据规范化和两阶段查询是优化的关键，二者解决的问题层次不同。
❓
延伸问答
TiDB向量查询的主要优化方案是什么？
主要优化方案是将查询改为两阶段：先获取TopN ID和距离，再回表获取详情。
为什么将locale统一为小写并使用locale = ?不是主要优化来源？
虽然将locale统一为小写和使用locale = ?是必要的，但在测试中并未使查询走索引路径，仍然执行全表扫描。
如何验证TiDB向量查询的优化效果？
通过对比三种SQL形态的执行计划和实际RU，使用EXPLAIN ANALYZE进行验证。
LOWER(locale)对查询计划有什么影响？
LOWER(locale)会导致查询计划变差，影响过滤条件的下推，增加全表扫描的可能性。
TiDB向量查询的两阶段查询具体是怎样的？
两阶段查询首先计算TopN ID和距离，然后再回表获取详细信息。
在TiDB中，idx_locale的作用是什么？
idx_locale是为了优化locale列的查询，但在测试中并未使查询走到索引路径，仍然执行全表扫描。
➡️
