采用Azure Table Storage作为Azure AI搜索数据源，能否高效处理百万级记录？

Azure Table Storage完全可以高效处理百万级的记录，但要结合它的特性以及和Azure AI搜索的配合方式来设计方案，以下是具体说明：

一、存储与基础查询能力 #

• Azure Table Storage本身支持PB级的存储容量，百万级的文章记录（单条记录按KB级计算的话，总容量仅为数GB）完全在它的承载范围内。
• 它的查询性能高度依赖**分区键（Partition Key）和行键（Row Key）**的设计：如果能通过合理的分区键（比如按文章发布年月、分类划分）将数据分散到多个分区，同时用行键（比如文章ID）快速定位单条记录，单分区内的查询可以达到毫秒级响应；但如果进行跨分区的全表扫描，性能会显著下降，这一点需要避免。

二、文本搜索的局限性与Azure AI搜索的配合 #

• Azure Table Storage本身不支持复杂的全文检索，仅能做简单的前缀匹配或精确匹配，无法替代MySQL中LIKE的模糊搜索，更无法满足AI驱动的语义搜索需求。
• 你的核心需求是优化文本搜索性能，正确的方案是将Azure Table Storage作为数据源，配合Azure AI搜索实现：
  • 配置Azure AI搜索的索引器，指向Azure Table Storage的文章表，设置同步规则（定时同步或实时触发同步）。
  • 索引器会自动提取Article Headline和BodyText字段，构建专业的倒排索引，支持全文检索、模糊搜索、同义词匹配、语义搜索等高级功能，这才是解决原MySQL LIKE性能问题的核心。
  • 百万级记录的索引构建与同步，Azure AI搜索完全可以支撑，只要合理配置索引字段和同步频率即可。

三、关键设计注意事项 #

• 切勿直接用Azure Table Storage做文本搜索，它的定位是低成本、大规模结构化数据存储，而非全文检索引擎。
• 设计Table Storage的分区键时，要兼顾数据均衡性：避免单个分区包含过多记录（比如不要将所有文章放在同一个分区），否则会导致索引同步时的压力集中，影响效率。
• 如果需要近实时的搜索体验，开启Azure Table Storage的变更日志功能，让索引器可以实时捕获数据的新增、修改、删除操作，减少搜索结果的延迟。

内容的提问来源于stack exchange，提问作者Sebastian