PHP mysqli预处理：查询所得ID拼接后用于IN子句的SUM统计值偏小无报错

最隐蔽的逻辑错误 #

你把implode(',', $counttheid)生成的逗号分隔字符串，作为单个s类型参数传入了IN (?)的占位符中。
这种写法完全不符合MySQL的参数绑定规则：当你传入"1,3,5,7"这样的字符串作为IN的匹配值时，MySQL不会把它拆成4个独立的ID做匹配，而是会把整个字符串当做一个单值处理。
根据MySQL的类型转换规则，这个字符串会被自动转成整数1（从字符串开头取连续数字部分，遇到逗号就停止），最终的匹配逻辑退化为id = 1，剩下的3、5、7对应的记录完全不会被统计到，这就是最终结果远低于实际值的核心原因——而且因为整个SQL语法是合法的，全程不会抛出任何报错，错误日志也不会有记录。

代码书写瑕疵 #

你把implode的逻辑写在了读取结果的while循环内部，每遍历一行数据就重复执行一次全量的字符串拼接，既浪费性能，后续修改代码时也很容易引入边界问题。

最优写法（同表查询无需拆两步） #

你前后两次查询操作的都是同一张account表，完全不需要先单独取出ID集合再二次查询，直接用嵌套条件一次完成统计即可，既避免踩坑，也减少一次数据库交互：

$stmt = $mysqli->prepare("
    SELECT SUM(mobcash) AS totalcash 
    FROM account 
    WHERE 
        level <= 5 
        AND door = ? 
        AND `group_name` = ? 
        AND betaald = 'Yes'
");
$stmt->bind_param("ss", $usernamesession, $groupname);
$stmt->execute();
$stmt->bind_result($totalcash);
$stmt->fetch();
echo $totalcash;

保留两步查询结构的正确写法 #

如果后续业务逻辑确实需要单独取出ID集合做其他操作，二次查询时不能直接把逗号拼接的字符串塞给单个占位符，需要动态生成和ID数量完全匹配的占位符，每个ID对应一个独立的?，从根源上避免参数类型不匹配的问题：

// 第一步：查询并收集ID集合
$counttheid = [];
$stmt3 = $mysqli->prepare("
    SELECT id 
    FROM account
    WHERE level <= 5 AND door = ? AND `group_name` = ? AND betaald = 'Yes'
");
$stmt3->bind_param("ss", $usernamesession, $groupname);
$stmt3->execute();
$result3 = $stmt3->get_result();

// 循环收集ID，强制转成整数类型规避注入风险
while ($rowid = $result3->fetch_assoc()) {
    $counttheid[] = (int)$rowid['id'];
}

// 空数组边界处理，避免SQL语法错误
if (empty($counttheid)) {
    echo 0;
    exit;
}

// 第二步：生成和ID数量匹配的占位符序列
$placeholderCount = count($counttheid);
$placeholders = implode(',', array_fill(0, $placeholderCount, '?'));
// 拼接成合法的IN查询语句
$sql = "SELECT SUM(mobcash) AS totalcash FROM account WHERE id IN ($placeholders)";

$stmt = $mysqli->prepare($sql);
// 所有ID都是整数类型，生成对应数量的i类型绑定标记
$bindTypeStr = str_repeat('i', $placeholderCount);
// 按顺序绑定所有ID参数
$stmt->bind_param($bindTypeStr, ...$counttheid);
$stmt->execute();
$stmt->bind_result($sumcash);
$stmt->fetch();
echo $sumcash;

注意：这种动态生成占位符的写法，是mysqli预处理正确支持IN多值匹配的标准方式，相比把字符串直接塞给单个占位符的写法，既不会出现类型转换导致的匹配遗漏，也能规避SQL注入风险。

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