【问题标题】:Mysql fetch() returns FALSEMysql fetch() 返回 FALSE
【发布时间】:2018-06-13 13:27:40
【问题描述】:

我目前在从 mysql 表流式传输结果时遇到问题。该表有超过 10,000,000 行。和结构

ID、IndexField1、Data1

在 ID 上使用 Primaryindex,在 IndexField1 上使用 Index。

在 PHP 中,我绑定到流部分数据(大约 7 Mio)来计算和验证某些部分。出于这个原因,我有一个回调,每个响应都会调用它。

public function streamForIndexedColumn(int $columnId, callable $callback){
$stmt = NULL;
$sql = "SELECT id, indexedField, data1 FROm myTable WHERE indexedField1 = ?;";
if (! ($stmt = $this->mysqlConn->prepare ( $sql ))) {
   throw new Exception("ERROR");
}
try {
    if (! $stmt->bind_param ( "i", $columnId)) {
       throw new Exception( "Binding parameters failed: (" . $stmt->errno . ") " . $stmt->error );
    }
    $item = new Item ();
    if (!$stmt->bind_result($item->id,$item->indexfield1,$item->data1)) {
            throw new Exception( "Binding output parameters failed: (" . $stmt->errno . ") " . $stmt->error );
    }

    if (! $stmt->execute ()) {
        throw new Exception("Execute failed: (" . $stmt->errno . ") " . $stmt->error );
    }
    $cnt = 0;
    while ( $row = $stmt->fetch() ) {
        $cnt++;
        $callback($cnt, $item);
    }
    if ($row ===FALSE){
        throw new Exception("MySQL Error: (" . $stmt->errno . ") " . $stmt->error );
    } finally{
        $stmt->close ();
    }
}

这有时会运行几个小时。有时它正在运行,有时它失败并显示消息“MySQL Error: (0)”

我是否以错误的方式获取错误原因?服务器或客户端是否有任何可配置的限制可能会产生此错误?

我正在使用 Mysql 5.17.19 和 PHP 7.0.29。

【问题讨论】:

  • 作为一个侧节点:当它失败时,它会在几个小时后失败(所以在处理项目之后)
  • 您的 while 循环会获取所有行,直到 $row 返回 false,然后它将退出并点击 if 检查。 if 检查不是必需的,所以删除它。
  • mysqli有fetch()吗?
  • 否:根据文档link,如果出现错误,它会返回 FALSE。这就是为什么我也检查了类型。如果没有更多数据,则返回 NULL。在某些情况下,它并没有失败。所以我不认为实现是错误的,但是我找不到任何该方法的错误处理示例
  • 当我在 CLI 中运行我的脚本时,我收到了另一个警告:PHP 警告:“空行数据包正文”

标签: php mysql database mysqli


【解决方案1】:

$row === FALSE 中的异常总是会被抛出,因为在它获取所有行之后,$row 将是 false。

$stmt->errno 将返回 0,因为(引自文档:http://php.net/manual/en/mysqli.errno.php) 返回最后一个 MySQL 函数的错误号,如果没有发生错误,则返回 0(零)。

【讨论】:

  • 我不熟悉 mysqli 但我会说mysqli_stmt::fetch() 完成后返回null
  • 感谢 Daan,您的评论,但 Alvaro 是对的:从文档中它返回 FALSE 以防出现错误。有时(!)很好,它给我返回了正确的结果,所以我不认为这是一个实现错误。也许对查询有一些限制。但即使是这个时间也不时地不同。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-06-18
  • 2023-03-28
  • 2018-10-29
  • 2017-03-03
  • 2013-02-02
  • 1970-01-01
相关资源
最近更新 更多