1. 项目背景
Dify 跑了三个月，一切正常。直到运营反馈"消息列表加载特别慢，翻一页要 5 秒钟"。小陈打开数据库一看——Message 表已经有 200 万条记录了，一个简单的SELECT COUNT(*) FROM messages跑了 3 秒。EXPLAIN 显示全表扫描（Seq Scan），因为查询条件里的conversation_id字段没有索引。
这不是巧合。Dify 的默认表结构是为"通用性"设计的——它不知道你的业务场景中最高频的查询是什么。你必须在理解表结构的基础上，为你的场景定制索引。而且不仅是索引——连接池大小、查询优化、表分区策略，都需要根据你的数据规模来调整。
本章带你打开 Dify 的"数据心脏"——从核心表 ER 关系图到 SQLAlchemy ORM 定义，再到针对高频查询的索引优化和慢 SQL 分析。
2. 项目设计
小胖：（看着 pg_stat_activity 的输出）“大师！Message 表 200 万行了，查消息列表慢得要死——5 秒才翻一页。我是不是该加个索引？但在哪个字段上加？”
大师：“先看你的查询是什么。大概率是SELECT * FROM messages WHERE conversation_id = 'xxx' ORDER BY created_at DESC LIMIT 20。这个查询需要在(conversation_id, created_at)上建一个
