这里也许没有真正的错误， 但是如果你跟随着代码的逻辑走下去， 你也许会发现这个看似无害的调用$valueRepository->findByValue() 最终执行了这样一种查询，例如：
$result = $connection->query("SELECT `x`,`y` FROM `values` WHERE `value`=" . $inputValue);结果每轮循环都会产生一次对数据库的查询。 因此，假如你为这个循环提供了一个包含 1000 个值的数组，它会对资源产生 1000 单独的请求！如果这样的脚本在多个线程中被调用，他会有导致系统崩溃的潜在危险。
因此，至关重要的是，当你的代码要进行查询时，应该尽可能的收集需要用到的值，然后在一个查询中获取所有结果。
一个我们平时常常能见到查询效率低下的地方 （例如：在循环中）是使用一个数组中的值 (比如说很多的 ID )向表发起请求。检索每一个 ID 的所有的数据，代码将会迭代这个数组，每个 ID 进行一次SQL查询请求，它看起来常常是这样：
$data = []; foreach ($ids as $id) { $result = $connection->query("SELECT `x`, `y` FROM `values` WHERE `id` = " . $id); $data[] = $result->fetch_row(); }但是 只用一条 SQL 查询语句就可以更高效的完成相同的工作，比如像下面这样：
$data = []; if (count($ids)) { $result = $connection->query("SELECT `x`, `y` FROM `values` WHERE `id` IN (" . implode(',', $ids)); while ($row = $result->fetch_row()) { $data[] = $row; } }因此在你的代码直接或间接进行查询请求时，一定要认出这种查询。尽可能的通过一次查询得到想要的结果。然而，依然要小心谨慎，不然就可能会出现下面我们要讲的另一个易犯的错误...
常见问题 #5: 内存使用欺骗与低效一次取多条记录肯定是比一条条的取高效，但是当我们使用 PHP 的 mysql 扩展的时候，这也可能成为一个导致 libmysqlclient 出现『内存不足』（out of memory）的条件。
我们在一个测试盒里演示一下，该测试盒的环境是：有限的内存（512MB RAM），MySQL，和 php-cli。
我们将像下面这样引导一个数据表：
// 连接 mysql $connection = new mysqli('localhost', 'username', 'password', 'database'); // 创建 400 个字段 $query = 'CREATE TABLE `test`(`id` INT NOT NULL PRIMARY KEY AUTO_INCREMENT'; for ($col = 0; $col < 400; $col++) { $query .= ", `col$col` CHAR(10) NOT NULL"; } $query .= ');'; $connection->query($query); // 写入 2 百万行数据 for ($row = 0; $row < 2000000; $row++) { $query = "INSERT INTO `test` VALUES ($row"; for ($col = 0; $col < 400; $col++) { $query .= ', ' . mt_rand(1000000000, 9999999999); } $query .= ')'; $connection->query($query); }OK，现在让我们一起来看一下内存使用情况：
// 连接 mysql $connection = new mysqli('localhost', 'username', 'password', 'database'); echo "Before: " . memory_get_peak_usage() . "\n"; $res = $connection->query('SELECT `x`,`y` FROM `test` LIMIT 1'); echo "Limit 1: " . memory_get_peak_usage() . "\n"; $res = $connection->query('SELECT `x`,`y` FROM `test` LIMIT 10000'); echo "Limit 10000: " . memory_get_peak_usage() . "\n";输出结果是：
Before: 224704 Limit 1: 224704 Limit 10000: 224704Cool。 看来就内存使用而言，内部安全地管理了这个查询的内存。
为了更加明确这一点，我们把限制提高一倍，使其达到 100,000。 额~如果真这么干了，我们将会得到如下结果：
PHP Warning: mysqli::query(): (HY000/2013): Lost connection to MySQL server during query in /root/test.php on line 11究竟发生了啥？
这就涉及到 PHP 的 mysql 模块的工作方式的问题了。它其实只是个 libmysqlclient 的代理，专门负责干脏活累活。每查出一部分数据后，它就立即把数据放入内存中。由于这块内存还没被 PHP 管理，所以，当我们在查询里增加限制的数量的时候， memory_get_peak_usage() 不会显示任何增加的资源使用情况 。我们被『内存管理没问题』这种自满的思想所欺骗了，所以才会导致上面的演示出现那种问题。 老实说，我们的内存管理确实是有缺陷的，并且我们也会遇到如上所示的问题。
如果使用 mysqlnd 模块的话，你至少可以避免上面那种欺骗（尽管它自身并不会提升你的内存利用率）。 mysqlnd 被编译成原生的 PHP 扩展，并且确实 会 使用 PHP 的内存管理器。
因此，如果使用 mysqlnd 而不是 mysql，我们将会得到更真实的内存利用率的信息：
Before: 232048 Limit 1: 324952 Limit 10000: 32572912顺便一提，这比刚才更糟糕。根据 PHP 的文档所说，mysql 使用 mysqlnd 两倍的内存来存储数据， 所以，原来使用 mysql 那个脚本真正使用的内存比这里显示的更多（大约是两倍）。