因为Scikit-learn默认将整个数据集加载进RAM，如千万行×百维float64矩阵可超20GB，直接触发MemoryError而非变慢；需用numpy.memmap配合SGDClassifier.partial_fit分批训练，并显式传classes、设mode='r'、监控内存验证。
为什么joblib.load或fit会触发MemoryError而不是慢？
因为Scikit-learn默认把整个数据集加载进RAM——哪怕你只调用LogisticRegression().fit(X, y)，只要X是普通numpy.ndarray，就会全量驻留内存。尤其当X是上千万行×百维的float64矩阵时，实际占用可能超20GB，远超物理内存。这不是算法慢，是根本没机会跑完。
用numpy.memmap替代ndarray的关键三步
memmap本身不解决scikit-learn兼容性问题，必须配合数据格式与加载方式调整：
- 先用
numpy.memmap创建磁盘映射文件（如'X.dat'），并确保dtype和shape在创建时就固定，后续不能resize - scikit-learn绝大多数estimator不接受memmap对象直接传入
fit，但sklearn.utils.validation.check_array会把它转成普通数组——这反而又爆内存。正确做法是：**只对训练数据做memmap，且用支持分块的estimator（如SGDClassifier）或手动分批partial_fit - 务必设置
mode='r'（只读）而非'c'（copy-on-write），否则仍可能触发全量加载；验证是否生效：用psutil.Process().memory_info().rss监控进程内存，应稳定在几百MB而非飙升
SGDClassifier.partial_fit如何安全接住memmap数据
这是最实用的组合：memmap提供按需读取能力，partial_fit避免单次载入全部样本。注意几个硬约束：
-
partial_fit要求所有批次的特征维度（n_features_in_）严格一致，所以memmap的shape[1]必须预先确认，不能靠第一次partial_fit自动推断（否则报ValueError: classes must be passed on the first call to partial_fit.） - 必须显式传入
classes参数（如classes=[0, 1]），哪怕二分类也绕不开 - 分块大小建议设为
min(10000, len(X))，太小导致IO频繁，太大仍可能OOM；读取时用X[start:end]切片（memmap支持），别用np.take或pd.read_csv二次加载
import numpy as np
from sklearn.linear_model import SGDClassifier
X = np.memmap('X.dat', dtype='float32', mode='r', shape=(10_000_000, 128))
y = np.memmap('y.dat', dtype='int32', mode='r', shape=(10_000_000,))
clf = SGDClassifier()
batch_size = 10000
for i in range(0, len(X), batch_size):
X_batch = X[i:i+batch_size]
y_batch = y[i:i+batch_size]
clf.partial_fit(X_batch, y_batch, classes=[0, 1])
哪些情况memmap根本救不了？
不是所有场景都能靠memmap缓解——关键看瓶颈是否真在“数据加载”：
立即学习“Python免费学习笔记（深入）”；
- 如果报错是
MemoryError出现在cross_val_score里，大概率是cv过程复制了多份数据副本（比如5折就占5倍内存），此时需改用pre_dispatch=1或换StratifiedKFold手动控制fold生成 -
RandomForestClassifier类树模型无法用partial_fit，且构建过程中每个树节点都要随机采样+排序，memmap的延迟读取反而拖慢速度，还可能因频繁seek导致IO瓶颈 - 如果你用
pandas.read_csv读大文件再转memmap，中间步骤已OOM——必须跳过pandas，用numpy.fromfile或逐块写入memmap文件
memmap只是把内存压力转嫁给磁盘IO和寻址效率，它不减少计算量，也不改变算法复杂度。真正卡住的时候，得先分清是“数据放不下”，还是“算法算不完”。
