PHP循环内执行SQL查询VS数组存储用户数据：哪种实现方案更优？

毫无疑问，第二种方案（预加载用户数据到数组中）是远优于第一种的选择，我从性能、维护性和资源利用三个维度给你拆解原因：

第一种方案的核心问题 #

第一种写法是典型的N+1查询反模式，存在以下硬伤：

• 性能瓶颈明显：每循环一条prayer_stats记录，就发起一次新的数据库查询。假设prayer_stats有100条数据，就会产生101次数据库请求（1次查统计+100次查用户）。哪怕是按ID的精准查询，数据库也要重复处理连接、SQL解析、执行、结果返回的全流程，网络开销和数据库负载会随着数据量线性增长，数据量稍大或高并发场景下，页面响应速度会急剧下降。
• 代码健壮性不足：原代码没有处理pray_user_id对应用户不存在的情况，如果数据库里有无效用户ID，sql_fetch返回空值后，后续调用$pray_person['url']等字段会直接抛出PHP错误，导致页面崩溃。
• 维护成本高：数据查询逻辑和页面渲染逻辑深度耦合，后续要修改用户字段或查询条件时，需要在循环嵌套的代码中查找修改点，可读性和扩展性极差。

第二种方案的优势 #

第二种写法完美规避了N+1问题，是后端处理关联数据的标准优化思路：

• 性能高效且稳定：仅需2次数据库查询（1次获取所有有效用户+1次获取统计数据），无论prayer_stats有多少条记录，数据库请求次数都是固定的。将用户数据存入以id为键的数组后，循环内的用户数据读取是O(1)时间复杂度，几乎无额外开销。
• 代码结构更清晰：数据获取与业务渲染逻辑完全分离，先预加载好所有需要的用户数据，循环内只专注于HTML渲染，可读性和可维护性大幅提升，也能提前处理用户不存在的边界情况（比如代码中的if($pray_person)判断）。
• 资源利用更合理：减少了数据库连接和查询次数，能有效降低数据库服务器的负载，在高并发场景下，这种优化能直接提升系统的承载能力。

额外优化建议 #

如果你的用户表数据量极大（比如百万级以上），预加载所有用户可能占用过多内存，这时可以进一步优化：先从prayer_stats中提取所有需要的用户ID，再精准查询这些用户，避免加载无关数据：

// 1. 先查询统计数据，收集需要的用户ID
$pray_res = sql_query($conn, "SELECT * FROM prayer_stats WHERE user_id != 0 ORDER BY year DESC, month DESC");
$pray_records = [];
$needed_user_ids = [];
while($prev_pray = sql_fetch($pray_res)) {
    $pray_records[] = $prev_pray;
    $needed_user_ids[] = $prev_pray['pray_user_id'];
}

// 2. 去重后精准查询需要的用户（注意防SQL注入）
$all_users = [];
if(!empty($needed_user_ids)) {
    // 对ID做转义处理，或使用预处理语句
    $safe_ids = array_map(function($id) use ($conn_user) {
        return sql_escape($conn_user, $id);
    }, $needed_user_ids);
    $user_res = sql_query($conn_user, "SELECT id, name, url, rank_name FROM register WHERE deleted=0 AND id IN ('" . implode("','", $safe_ids) . "')");
    while ($u = sql_fetch($user_res)) {
        $all_users[$u['id']] = $u;
    }
}

// 3. 渲染数据
foreach($pray_records as $prev_pray) {
    $pray_person = $all_users[$prev_pray['pray_user_id']] ?? null;
    if($pray_person) {
        // 渲染HTML逻辑...
    }
}

另外要注意：原代码中的SQL字符串拼接存在SQL注入风险，建议使用参数化查询（预处理语句）替代直接拼接，提升代码安全性。

备注：内容来源于stack exchange，提问作者Phoenixy