大批量数据优化处理的核心是避免全量加载，应采用分批+流式+类型精简+按需加载策略：Pandas用chunksize、SQLAlchemy用yield_per、class-transformer手动分批；PyArrow用iter_batches、mmap分块读取；Pandas降精度、Parquet设编码、查询只选必要字段；分页改用游标或Search After。
大批量数据集合的优化处理，核心是避免“全量加载、一次性处理”这种高内存、低响应的模式。关键不在工具本身，而在策略组合：分批 + 流式 + 类型精简 + 按需加载。
分批处理：最直接有效的内存控制手段
无论用 Pandas、SQLAlchemy 还是 class-transformer，都应主动切分数据：
- Pandas 读 CSV 或 Parquet 时，固定 chunksize（如 5000–50000 行），逐块处理后及时释放引用
- SQLAlchemy 查询用 yield_per(1000)，配合 for 循环逐条或逐批取数，不缓存全部结果
- class-transformer 转换对象时，手动按 batchSize = 1000 切数组，每批转完 await setImmediate() 让事件循环喘口气
流式与内存映射：绕过内存瓶颈的底层方案
当数据远超物理内存，就得跳过“加载到内存”这一步：
- PyArrow 读 Parquet 优先用 ParquetDataset.iter_batches()，不调 read_table()；大文件可搭配 memory_map 直接映射磁盘页
- 文本类数据（如 Wikipedia 多语言语料）可用 mmap 分块读取原始字节，解析逻辑在 chunk 内完成，不保留完整字符串对象
- Node.js 场景下，用 Transform Stream 管道式处理，输入流 → 转换流 → 输出流，全程无中间数组累积
数据结构与类型精简：省下的内存就是性能
同样 100 万行，内存占用可能差 3 倍：
- Pandas 中把 int64 改为 int32、float64 改为 float32、重复字符串列设为 category
- Parquet 文件写入前指定高效编码（如 Dictionary 编码用于 ID/状态列），读取时显式传 dtype_mapping
- 数据库查询只选必要字段（usecols / load_only()），避免 SELECT *
查询与分页优化：别让 OFFSET 拖垮大数据
传统 LIMIT OFFSET 在百万级后性能断崖下跌：
- 用游标分页：记录上一页最后一条的 id 或 updated_at，下一次查
WHERE id > last_id ORDER BY id LIMIT 100 - Elasticsearch 等引擎启用 Scroll API 或 Search After，避免深度分页扫描
- 数据库加复合索引，确保游标字段和排序字段都在索引中，避免回表
