山维空间
·
一次 TiDB 向量查询优化实战：
内容提要
本文讨论了TiDB向量查询的优化实践，通过将查询分为两阶段（先获取TopN ID和距离，再回表获取详情），显著降低了RU和耗时。虽然将locale统一为小写和使用locale = ?是必要的，但未能使查询走索引路径。最终优化方案强调了数据规范化和两阶段查询的重要性。
关键要点
-
将 documents.locale 全部统一成小写，并将查询条件改为 locale = ? 是必要的，但不是主要优化来源。
-
真正显著降低 RU 和耗时的优化方案是将查询改为两阶段：先获取 TopN ID 和距离，再回表获取详情。
-
在测试中，LOWER(locale) 确实导致查询计划变差，影响了过滤条件的下推。
-
idx_locale 并未使查询走到索引路径，仍然执行全表扫描。
-
two-phase 查询显著降低了 RU 和耗时，证明了其有效性。
-
数据规范化和两阶段查询是优化的关键，二者解决的问题层次不同。
延伸解读
数据规范化的重要性
在TiDB向量查询优化中，数据规范化是基础。将documents.locale统一为小写，虽然不是主要的性能提升来源，但却是确保查询一致性和避免潜在错误的必要步骤。这种规范化有助于减少查询中的表达式损耗，确保后续的优化措施能够有效实施。
两阶段查询的优势
采用两阶段查询策略显著降低了RU和耗时。通过先获取TopN ID和距离，再回表获取详细信息，避免了在向量排序阶段带入过多大字段，从而减少了计算负担。这一策略在处理大数据量时尤为重要，能够有效提升查询性能。
索引使用的局限性
尽管在优化过程中引入了idx_locale索引，但测试结果显示该索引并未有效改善查询性能，仍然执行全表扫描。这提醒开发者在进行SQL优化时，不能仅依赖索引的存在，还需关注查询计划的实际执行路径。
延伸问答
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列的查询，但在测试中并未使查询走到索引路径，仍然执行全表扫描。
