Laravel技术问询：筛选近30天标准账户ID及最优实现方式

毫无疑问，在数据库层面完成近30天的过滤是远优于获取结果后再处理的，主要原因有这几点：

• 性能碾压：数据库会直接筛选出符合条件的记录，不需要把所有「标准账户」的数据都拉取到应用内存中再做二次过滤。当用户表数据量较大时，这能节省大量的内存占用和网络传输成本。
• 代码更简洁易维护：过滤逻辑直接嵌入查询语句，后续看代码的人一眼就能明白你要获取的是「近30天的标准账户ID」，不用额外去看结果处理的逻辑。
• 能利用索引优势：如果你的created_at字段创建了索引，数据库可以快速定位到近30天的数据，进一步提升查询效率——这是内存过滤完全做不到的。

修改后的Laravel查询代码如下：

$users = DB::table("users")
    ->select('id')
    ->where('accounttype', 'standard')
    ->where('created_at', '>=', now()->subDays(30))
    ->get()
    ->all();

这里用到的now()->subDays(30)是Laravel内置Carbon日期类的便捷方法，会自动生成当前时间往前推30天的DateTime对象，和你created_at字段的timestamp类型完美匹配，能准确筛选出近30天创建的用户。

如果非要在获取结果后处理（非常不推荐），代码大概是这样：

// 先获取所有标准账户（还得额外查created_at字段）
$allStandardUsers = DB::table("users")
    ->select('id', 'created_at')
    ->where('accounttype', 'standard')
    ->get()
    ->all();

// 再在内存中过滤近30天的用户
$filteredUsers = collect($allStandardUsers)->filter(function($user) {
    return $user->created_at >= now()->subDays(30);
})->pluck('id')->all();

但这种方式不仅多查了created_at字段，还要把所有标准账户加载到内存，数据量一大就会拖慢应用，完全没必要这么做。

内容的提问来源于stack exchange，提问作者user8012864