PHP - 将大会话数组存储在 $_SESSION 或数据库中？
我需要在会话期间存储一个大数组（目前最多几 kB，我将其限制为最大 0.25MB）。
根据您的观点和实践，将其存储在 $_SESSION 中还是数据库中更好？
速度很重要，但处理器/内存的使用也很重要，因为它位于共享主机上，我不希望他们因资源过度使用而关闭站点。
您是否认为 $_SESSION 在一个大小范围内可以放心使用，它会很好地工作？ （例如 0kb-100kB 或您的实践/测试显示的任何内容）。
谢谢。
I need to store a big array during the session (currently up to few kB, and I'd limit it to 0.25MB max).
In your opinion and practice, is it better to store it in $_SESSION or in database?
Speed matters, but so does processor/memory usage, as it's on shared host, and I wouldn't want them to shut the site down for resource overuse.
Would you say there's a size range in which $_SESSION can be used with confidence it will work well? (For example 0kb-100kB or whatever your practice/tests showed).
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果存储在会话中，那么具有相同数量会话的 0.25MB 将使用比存储在数据库中更少的资源。因此，会话中资源过度使用的可能性较低。
0.25MB with a sane number of sessions will use less resources if stored in the Session, than in the DB. So the likelyhood of resource overusage is lower with the session.
这在很大程度上取决于您的站点和服务器的并发用户数量。因为它是一个共享服务器，如果（且仅当）你有大量用户，我会使用数据库，但使用 $_SESSION 更容易、更快，而且 200kbs 并不多。此外，不使用数据库可以节省大量检索数据的时间，因为它不必在每个请求上来回数据库服务器和 Web 服务器。
It depends a lot in the number of concurrent users of your site and your server. Since it is a shared server i would use a database if (and only if) you have a very big number of users, but its easier and faster with $_SESSION, and 200kbs its not a lot. Also, not using a DB saves you a lot of time retrieving data since it doesnt have to go back and forth DB server and web server on each request.
会话的真正性能损失是 PHP 为每个请求重写会话数据。写入磁盘（在大多数情况下都会这样做）非常慢。它应该仅用于简单的事情，例如身份验证和小型数据结构，例如购物车等。
根据数据类型以及服务器上可用的软件，您应该将其存储在数据库中，或者可以使用 NoSQL 解决方案，例如 MongoDB、Redis 或 CouchDB。
由于您首先考虑使用会话，因此我认为数据的一致性并不是第一要务。如果数据很重要，您应该使用 MySQL 数据库，因为它遵循 ACID 原则，并且即使在客户端与当前会话解除关联后也会保留您的数据。
如果一致性不重要，请考虑使用 Memcached（如果可用）。
总结：使用数据库，但不一定是MySQL（要看是什么数据）。
The real performance penalty with sessions is that PHP rewrites the session data for every request. Writing to disk (which it will do in moste cases) is very slow. It should be used only for simple things like authentication and small data structures e.g. shopping carts and the like.
Depending on what kind of data it is and what software you have available on the server you should store it in the database or you could use a NoSQL solution like MongoDB, Redis or CouchDB.
Since you are considering using sessions in the first place, I take it as consistency of the data is not the number one priority. If the data is important you should use the MySQL database since it follows the ACID principles and will keep your data even after a client disassociates itself with the current session.
If the consistency is not important, consider using Memcached if it is available.
Summary: Use a database, but not necessarily MySQL (depending on what data it is).
当您使用默认会话处理程序时，会话通常会在存储在文件系统上的会话文件中之后加载到内存中。除非您明确使用内存来存储会话，否则您不会遇到持续存在的会话内存问题。在我看来，无论如何，举办大型会议都是不好的。设计中一定存在一些根本性的缺陷。如果您想要将数据与用户相关联，这通常可以通过设计数据库来实现，以便仅通过外键将数据与正确的用户相关联。您可以查询该数据的一小部分，而不是将大量数据加载到内存中并对其进行过滤。会话仅对用户身份验证真正有用。 RESTful API 根本不会使用会话。我可能应该指出，我偏向于无状态网络。会话在请求之间保留状态。我只接受身份验证作为有效用例，因为浏览器不提供通用且安全的替代方案
Sessions are loaded into memory usually after being stored in a session file on the file system when you use the default session handler. You don't have persisted memory issues with sessions unless you are are explicitly using memory to store your sessions. In my opinion it is bad to have large sessions anyway. There has to be some fundamental flaw in the design. If you want to relate data to a user this is usually achieved by designing your database such that data is associated to the correct users simply through foreign keys. You have the ability to query a small subset of this data rather than loading a large chunk of data into memory and filtering it. Sessions are only really useful for user authentication. A RESTful API will not use sessions at all. I should probably note that I am biased in favour of stateless web. Sessions persist state between requests. I've only accepted authentication as a valid use case because browsers do not provide a versatile and secure alternative