MySQL 大表查询内存溢出Python 生成器 yield 内存泄漏ThreadPoolExecutor 任务队列积压SSCursor 流式游标使用数据库结果集客户端缓存Python 信号量限流控制并发线程池无界队列内存爆炸生产者消费者背压实现MySQL 百万级数据批量处理优化Python 多线程数据迁移内存优化ThreadPoolExecutor shutdown 死锁问题数据库连接池与游标类型选择

Python脚本使用yield与线程池处理MySQL300万行数据查询内存飙升优化

2026-09-21

前段时间处理一个数据批量更新任务，需要从 MySQL 表中读取大约 300 万条记录，经过一系列逻辑处理（调用外部 API 更新标签）后写回。为了控制资源，我使用了 ThreadPoolExecutor 配合生成器逐条产出数据，期望做到“边读边处理”，避免一次性加载全部结果集。 然而上线后观察监控，发现 Python 进程的内存占用随着迭代不断攀升，最终几乎吃满机器内存，导致 OOM 风险。最初直觉是 yield 没有真正实现流式，或者数据库驱动缓存了全部结果，但深入排查后发现事情没那么简单。 初始代码结构 简化后的核心代码如下： from mysql.connector.pooling import MySQLConnectionPool dbpool = MySQLConnectionPool() def..

更多

Elasticsearch 评分机制Elasticsearch 排序term terms 评分差异bool 查询filter shouldsort _scorefunction_score 时间衰减BM25 评分Elasticsearch 性能优化相关性排序混合排序搜索结果排序Elasticsearch 踩坑二级排序minimum_should_matchtrack_scoresrewrite scoring_boolean精确匹配 评分全文检索 排序ES 查询 DSL 实战

Elasticsearch排序与评分机制记录：关于term和terms权重与filter和should

2026-09-19

最近在优化一个全文检索业务时，遇到了一个典型的排序场景：用户要求搜索结果首先按相关性排序，相关性相同时按创建时间倒序。听起来很简单对吧？但当我真正上手写 DSL 时，才发现 must、filter、should 以及 sort 之间的微妙关系远比想象中复杂。 研究发现了 term 查询在 must 与 filter 中的评分差异、terms 为何默认得分恒定、以及如何利用 bool + should + sort 实现“硬过滤 + 软评分”的混合排序。 问题背景 业务场景是文章搜索，核心需求如下： 硬性筛选：只返回状态为 published、且创建时间在某个时间点之后的文章。 相关性排序：根据用户输入的关键词（如标签、作者）计算匹配度，分数越高越靠前。 时间兜底：当两篇文章的相关性分数完全一致时，最新的文章排..

更多

sentence-transformers Docker 镜像优化Docker 镜像体积过大 解决方案Python Docker 瘦身 实战sentence-transformers 部署 容器化PyTorch CPU 版 Docker 安装Docker 多阶段构建 PythonEmbedding 模型 容器 部署 优化Dockerfile 最佳实践 2026sentence-transformers 镜像 8GB 缩减RAG 项目 Docker 部署 优化

Sentence-Transformers Docker 镜像从 8GB 到 2GB 的优化实录

2026-09-05

问题背景 最近在做一个 RAG 相关的项目，需要把基于 sentence-transformers 的 embedding 服务打包成 Docker 镜像部署。项目本身不算复杂，依赖也就那么几个，结果 docker build 跑完之后一看——8GB。 镜像推送到私有仓库要等半天，开发机拉取一次占掉小半个硬盘。更麻烦的是，每次改一行代码重新构建，整个流程又来一遍。 问题定位 先看 Dockerfile，写得很“标准”： FROM python:3.11 COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD ["python", "app.py"] requirements.txt..

更多