2. 如果遇到慢 SQL，该如何解决？
第一步：使用 EXPLAIN 查询执行计划
主要关注以下字段：
| 字段 | 说明 |
|---|---|
type |
当前查询的效率级别，从好到差依次为：const > eq_ref > ref > range > index > ALL |
possible_keys |
预期索引是什么 |
key |
实际使用的索引是什么 |
rows |
预估扫描的行数，越小越好 |
Extra |
额外的执行计划信息，如 Using index（覆盖索引）、Using where（回表过滤） |
第二步：索引优化
- 能用覆盖索引的尽量使用覆盖索引
- 避免索引失效
索引失效的常见情况
| 场景 | 示例 |
|---|---|
| 使用函数 | WHERE YEAR(date) = 2024 |
| 在索引列上进行计算 | WHERE age + 10 = 30 |
| 使用类型转换 | WHERE phone = 13800138000（phone 字段是 VARCHAR 类型） |
| 联合索引违反最左前缀原则 | 复合索引 (a, b) 只查 b 条件 |
使用 LIKE 以 % 开头 |
WHERE name LIKE '%张三' |
3. RAG（检索增强生成）
作用
RAG 可以缓解 LLM 的幻答问题，配置知识库后，Prompt 会更加全面，缓解答非所问的问题。
工作流程
离线阶段（建立知识库）
- 将知识库里的文本拆分
- 使用上下文预测方法和海量数据，将知识库向量化成一串数字
- 存储到 ChromaDB（向量数据库）
在线阶段（问答）
- 每次新来的问题也向量化成一串数字
- 与向量数据库进行比对相似度
- 将相似度高的文字添加到 Prompt 中
- 发送给 LLM 生成答案
向量化的训练原理
以“我吃苹果”和“我吃香蕉”为例：
- “吃”和“我”有关
- “吃”和“苹果/香蕉”有关
- 因此“苹果”和“香蕉”也可能有关
模型通过海量数据进行上下文预测：
- 预测正确 → 继续按照这个策略
- 预测错误 → 重新调整向量
通过海量的数据不断计算，最终得出每个词的向量。
开发实践
在真正开发中可以不用自己训练，有一个已经训练好的模型 BGE，可以直接使用它来得出向量结果。
from sentence_transformers import SentenceTransformermodel = SentenceTransformer('BAAI/bge-small-zh-v1.5')
embeddings = model.encode(["文本内容"])