我最近被要求为网站的营销模块制作一个简单的模块，我被要求使用可通过 MySQL 数据库访问的原始数据生成一组非常具体的结果。现在一开始我认为这是非常直接的，但是当面对这些桌子时，我意识到我需要改变我的方法。
我面临的问题是，我需要的数据是用户在浏览网站的特定部分时的操作日志。用户的每一个动作从登录到退出都是登录的，每天访问网站的人数只允许这个系统运行大约2天，然后将数据归档到另一个表中，我们总共有100个表加上现场直播，让我可以随时使用大约 202 天的数据。
所以这是我的问题。
随着这些表存储的数据量和存档表的绝对数量可能限制或可能不限于 100，并且客户希望根据特定页面的操作将所有数字显示在屏幕上，您将如何推荐打算这样做吗？
根据数据库设置，直接使用 SQL 查询可能会也可能不会，所以我考虑了从 XML 到使用基于页面和数据的 chron 将数据序列化为文件结构的一些选项，但最终我不是 100%我应该走的路线，所以我想问一下，有人有更好的主意吗？如果是这样，请分享。
在此先感谢所有回复的人。
如果您想查询自己的数据，听起来您正在进入需要进入数据仓库的领域。这意味着您希望对数据执行 ETL 作业，以将其转换为更有利于报告查询的数据库模式（星型模式、雪花模式等）。
就个人而言，我会考虑利用其他一些系统（如 Google Analytics）并开始将自定义数据记录到其中的方法。这样一来，Google 就可以维护基础架构，并且您可以获得所需的所有报告数据。您可以使用 Google Analytics 创建转换漏斗和大多数您需要的东西，但是请注意，您必须花大量时间来实际配置代码以将自定义事件、标签等发送到 Google 系统。
You don't want to query this data directly. You want to create intermediate tables that have the information that you need now, and then some.
The exact format depends on the nature of the questions. For instance, it might be appropriate to have one record for each "session", with columns describing what happens in the session. Or, if you are only interested in customers, you might make a customer signature, with a bunch of values.
One of the challenges is that the data goes over boundaries between dates. So, you will have open "logins" in one table versus another. How much of a problem this poses once again depends on how the data will be used. However, you should think about strategies for ealing with it.
If you have lots of users with lots of steps on a web site, going against all the data directly would be, shall I say, fun. Well, if you take a long vacation while the system processes the data, then it might actually be fun.
您可以尝试使用缓存的概念。这样，您可能不需要每次都从表中获取数据。