PHP访问users与batch表时报mysqli::query: Couldn't fetch mysqli错误咨询

该报错和SQL语法、业务逻辑完全无关。PHP抛出这个警告的唯一场景，是调用query()方法时，目标mysqli连接实例已经被销毁、不存在，或根本不是有效的mysqli对象。结合你已经验证SQL在phpMyAdmin可正常执行、单独测试batch查询代码无问题的前提，完全不需要在SQL层面排查，重点围绕数据库连接的全流程生命周期定位即可。

匹配你项目结构的常见触发原因 #

• 连接被提前主动关闭
  你复用的旧项目dataconnection.php中，大概率残留了查询完成后主动调用mysqli_close()的逻辑：代码走完users表查询流程后，提前执行了连接关闭操作，等走到users.php第48行执行batch表查询时，拿着已经关闭的连接对象调用query()就会触发报错。
• 连接作用域失效
  旧代码的数据库连接往往定义在函数内部，或没有在全局作用域显式导出：dataprocessing.php里的公共查询函数没有通过global $conn引入全局连接实例，或是函数内部错误声明了一个空的局部连接变量，导致传给query()方法的连接是空对象。
• 流程异常导致连接被PHP自动回收
  查询users表的过程中（比如性别/婚姻状态编码转换环节）触发了PHP致命错误，PHP在终止脚本运行的过程中自动销毁了已经创建的数据库连接，后续代码块再尝试使用连接时就会抛出该警告。
• 连接实例被意外覆盖
  旧项目的连接初始化逻辑没有加单例判断，多次引入dataconnection.php的过程中，原有有效连接变量被重新赋值为null，或被覆盖为空的mysqli实例，导致后续调用时找不到有效连接。

分步定位操作 #

• 在users.php第48行调用query()之前，临时加一行调试代码：var_dump($conn);exit;。如果输出结果不是有效的mysqli连接实例（是null、非对象、已关闭的连接），即可100%确认是连接失效问题，和SQL逻辑无关。
• 逐行梳理从users表查询完成到第48行batch表查询之间的所有代码，重点排查三个方向：有没有执行$conn = null这类覆盖连接的赋值、有没有调用mysqli_close($conn)这类主动关闭连接的逻辑、有没有触发PHP致命错误导致脚本提前中断。
• 全局检索dataconnection.php里的所有连接相关代码，删掉流程中间所有主动关闭连接的语句。

长效解决方案 #

• 统一连接管理：将数据库连接初始化改成单例模式，整个脚本运行周期内只生成一个有效连接实例，删掉所有非脚本终止阶段的mysqli_close()调用，等脚本执行完再由PHP自动回收连接。
• 修正作用域问题：所有公共查询函数显式通过参数传入有效的连接对象，或是在函数内部通过global $conn显式引入全局连接，避免隐式作用域查找带来的连接失效问题。
• 增加前置有效性校验：每次调用query()前先校验连接状态，比如加入判断逻辑：if (!$conn instanceof mysqli || $conn->connect_error) { die("数据库连接失效"); }，提前抛出明确的错误提示，避免模糊的警告信息干扰定位。

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