北京
那天下午，客戶說需要導出全量用戶數據做年報。我想都沒想就寫了個 User::all()，然后循環寫入 CSV。幾分鐘后，運維在群里發了一張截圖：Apache 超時，整個站點掛了。
后來我才知道，all() 會把所有數據一次性裝進內存。十萬條用戶記錄，每條帶上關聯數據，內存瞬間爆掉。生產環境不像本機，沒有 16GB 給你揮霍。這件事逼著我把 Laravel 處理大數據集的四個方法全部啃了一遍，下面是我整理出來的實測結論。
先看最直接的 chunk()。它每次從數據庫取 500 條，處理完再取下一批，內存占用始終可控。代碼也很簡單：User::chunk(500, function ($users) { ... })。很適合發郵件、后臺批處理這類場景。但有兩點要留意，一是它內部跑的是多次 SQL 查詢，不是一次取完；二是在閉包里刪改記錄容易翻車——因為偏移量計算會被打亂，導致跳過某些行。如果只是讀數據，問題不大。
如果你需要在分批處理的同時更新或刪除記錄，chunkById() 更安全。它按 ID 排序分頁，哪怕你在閉包里刪掉了前 500 條里的某幾條，下一批查詢的 where 條件仍然能準確定位到未處理的記錄，不會漏數據。官方文檔也推薦在修改數據的場景下用它代替 chunk()。
再來說 cursor()，這是內存效率最高的一個。它只執行一條 SQL，然后逐行返回結果，每次內存里只裝一條記錄。User::cursor() 返回的是一個生成器，配合 foreach 遍歷，適合 CSV 導出、數據遷移這類只讀操作。但它有個硬傷：不能用 with() 做預加載關聯。你沒法寫 User::with('orders')->cursor()，關聯數據要么單獨查，要么提前設計好。另外，數據庫連接在遍歷期間一直保持打開狀態，如果處理過程有耗時操作，比如調第三方接口，可能會占著連接不放。
lazy() 的出現恰好解決了這個問題。它在底層按批次取數據，但使用方式和 cursor() 一樣簡潔。更關鍵的是，它支持 eager loading，你可以寫 User::with('orders')->lazy()->each(function ($user) { ... })，既省內存又能拿到關聯數據。對于既要遍歷大表、又需要關聯信息的場景，lazy() 是目前最優解。
我用一張表把四個方法的差別整理了一下。chunk() 每批取指定條數，跑多次查詢，內存占用低，適合批處理但不建議在閉包里修改數據。chunkById() 同樣分批多次查詢，內存占用低，適合需要更新或刪除記錄的場景。cursor() 單次查詢逐行返回，內存占用最低，但只支持只讀且不能用 with()。lazy() 底層分批，查詢次數取決于大小，支持 with()，適合需要關聯數據的只讀操作。
回到開頭那個崩潰的 CSV 導出。當時代碼很簡單：$users = User::all()，然后在循環里用 fputcsv 寫文件。讀到一萬多條時 Apache 直接超時中斷。改進之后換成 User::cursor()，同樣的數據量，不到兩分鐘跑完，內存基本沒動。具體寫法是 foreach (User::cursor() as $user) { fputcsv($handle, [$user->name, $user->email, $user->created_at]); }。不需要 any 額外配置，Laravel 自己處理了查詢結果的釋放。
四個方法用對了場景，能避免大多數內存和超時問題。chunk() 適合批處理、發郵件，chunkById() 適合在批次中修改數據，cursor() 適合只讀導出且內存要求最嚴格的情況，lazy() 在需要關聯數據時替代 cursor()。如果你在用 Laravel 處理上萬條記錄，不妨先把 all() 摘掉，根據需求選一個更合適的迭代方式。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
