Php Globals v. 数据库调用大量数据答案

【问题标题】：Php Globals v. Database calls for lots of dataPhp Globals v. 数据库调用大量数据
【发布时间】：2014-05-23 20:42:05
【问题描述】：

对于大型数组，是否将数据保存到全局变量或每次需要时查询数据库更好？在我的情况下，将它们保留在本地范围并将它们传递给函数不是一种选择。

我正在使用 wordpress，在大多数页面中，我都会获取每个用户和所有附加到他们的元数据。我经常在同一页面的多个位置使用这些变量。不幸的是，wordpress 不允许我在模板之间传递变量，所以我要么使用全局变量，要么每次都调用数据库。最终，这将是数百个用户，每个用户都附加了很多元数据。我应该每次调用数据库以将变量保存在本地，还是应该将它们保存到全局变量以保存数据库查询？有哪些考虑？我应该担心性能、开销和/或其他问题吗？

非常感谢！

【问题讨论】：

将数据保存在全局变量中并没有多大帮助，因为您仍然需要在每次页面视图时重新加载它。根据您当前的架构，使用 Redis 之类的东西进行缓存应该会有很大的不同。
阅读c2.com/cgi/wiki?GlobalVariablesAreBad

标签： php database performance global-variables database-performance

【解决方案1】：

唯一真正解决您的问题的方法是使用某种缓存系统（Memcache 和 Redis 是您的最佳选择）。幸运的是，有很多 Wordpress 插件可以让集成变得简单。例如：

Redis：https://wordpress.org/plugins/redis-object-cache/
内存缓存：https://wordpress.org/plugins/memcached/

编辑

如果您只想缓存一些数据库调用，您可以忘记 Wordpress 插件并开始编写代码。假设您只想缓存从数据库中检索用户列表的调用，并假设您正在使用 Memcache 完成此任务（Memcache 存储键值对并允许对给定键的值进行超快速访问）。

查询 Memcache 请求键“users”。
Memcache 仍然没有这样的键，所以你会遇到一个缓存失败，在它之后，你将查询你的数据库来检索用户列表。现在序列化数据库响应（serialize 和json_encode 是执行此操作的两种不同方法）并将密钥“users”与此序列化值一起存储在您的内存缓存中。
下次您查询 memcache 时询问“用户”时，您将获得成功。在这一刻，您只需要反序列化值并使用您的用户列表。

仅此而已。现在您只需决定要缓存的内容并将此过程应用于这些元素。

【讨论】：

有没有一种好方法可以仅在单个页面加载时缓存数据库调用？和/或缓存 90% 的信息，同时仍然更新 10% 会定期更改的信息，几乎每次页面浏览？
@DavidHobs 我已经编辑了我的答案并添加了一个程序，该程序显示了如何只缓存您需要的内容。

【解决方案2】：

您不必执行调用，但每页一次，您可能必须为每一页执行一次调用。所以我建议你创建某种类来与你的数据库交互，你可以调用它来获取你需要的数据。我还建议在您的数据库上使用存储过程和函数，而不是直接查询，因为这将有助于安全性以及应用程序逻辑和数据功能的分离。

【讨论】：

为什么在不了解查询访问模式的情况下建议存储过程或函数？您的建议实际上与您所说的相反。使用这种方法，您可能会将应用程序数据访问逻辑移出应用程序并移入数据库。另外，我不知道使用存储过程和函数与安全性有什么关系。
好吧，我的理解可能不正确，所以我会试着解释一下自己，也许你可以纠正我的错误，了解这一切是如何运作的。使用存储过程或函数，您将执行某种选择语句并可能返回从数据库中提取的数据。然后，您将在 PHP 中对该数据执行逻辑。这不是应该如何完成的，还是我的理解偏离了方向。至于安全性，如果我没记错的话，在使用存储过程时，驱动程序应该在传入参数时自动清理参数。
从安全的角度来看，更常见的做法是使用准备好的语句，其中查询执行计划与传入的参数数据分开确定，这意味着可能有害的数据（SQL 注入）实际上不会影响查询行为。从本质上讲，使用存储过程来包装 SELECT 语句可能会过大，并且可能会向应用程序程序员隐藏查询的意图。对于本质上试图扩展基本 MySQL 功能的情况，我会更多地考虑存储过程或函数。
好吧，从它的读取方式看来，在某些时候最好使用存储的包而不是。通过我在大学的课程和工作，这是我们曾经使用过的所有东西，没有人质疑它。有没有特定的时间你不会使用其中一个？我才刚毕业一年，我还在努力学习。
老实说，不同的商店可能采取不同的方法。如果你有一个强大的 DBA 团队，也许一家公司可能倾向于将更多的逻辑放入存储过程/函数中（不一定是因为任何实际的设计考虑）。我个人喜欢把应用逻辑放在应用层，把持久化逻辑放在持久层。但是，我可以看到，如果您有许多应用程序与公共数据库交互，并且您需要公开一些公共数据库行为/功能，那么编写存储过程来执行此操作可能更有意义。