想象一下，我们有一个庞大的数据库（MySQL和PHP），其中包含两个表：
Important id in table #1
Important id in table #2
登录网站的人可以像在网站的任何页面上遇到的这些表中的任何记录一样。那些类似的将被存储并实时添加到：
Important_SESSION_Array_#1
Important_SESSION_Array_#2
在每个类似的情况下，SESSION数组将使用新值作为数组中的第一个进行更新。所有值都是唯一的ID：AI整数。 （与dBase中的其他表格相关。）
然后，在每个页面加载时，您将访问这两个会话数组，并从实时加载的其他表中查找匹配的ID。
这种情况提出了几个问题：
这是一个例子，但实际上我们在这个级别上遇到了超过2000万条记录。因此，我们正在寻找更好的方法来处理这些大量数据 - 甚至是每个用户。
非常欢迎你对此有任何想法！
答案 0 :(得分：1)
要存储在会话数组中的最大数据与允许PHP使用的最大数据（memory_limit）相同。请注意，仅使用会话数据填充允许的内存可能不方便，不会为任何其他变量留下空间。
PHP会话存储在服务器上，客户端浏览器的功能在这方面无关紧要。
尽管可能允许PHP具有1千兆字节或更多字节的会话数据，但当您滥用会话充当缓存时，这被认为是不好的做法。会话中的所有数据在执行session_start()然后反序列化（需要大量CPU）时，从永久存储（最可能是文件）完全读入内存，并在脚本结束时（或执行时{{ 1}}）整个数据再次序列化（CPU！）并写回永久存储（I / O）。不断向文件存储移动1 GB数据将大大妨碍您的应用程序性能。
将人们喜欢的内容的ID保存到会话中并不是最好的方法。喜欢一个id是一个INSERT进入数据库。查询该人喜欢的ID是一个SELECT。两者都由正确的索引设置提供支持（用户ID会浮现在脑海中），并且只有在代码实际需要知识时才会执行。这很可能比在会话中存储该信息的性能要低一些（没有存储多少ID的上限）。