PHP - 记录用户活动并将其显示在不同页面上的最佳方式？
我已将网站登录用户活动保存到 .txt 文件中。我希望能够在我的管理区域的单独页面中显示这些结果。因此第一页显示 1-50 个结果，依此类推。
但我遇到的问题是它在 .txt 文件中是这样设置的
User: Admin IP 地址：xx.xxx.xxx.xx 主机地址：xxxxxxxxxxxxxxx 日期和时间：2010 年 9 月 20 日星期一上午 11:44:18 网址：http://colemansystems.psm2.co.uk/ 浏览器：Mozilla/5.0（Macintosh；U；Intel Mac OS X 10_6_3；en-US）AppleWebKit/534.3（KHTML，如 Gecko）Chrome/6.0.472.62 Safari/534.3 参考网址：
每组信息之间间隔七行。我正在考虑将其放入 MySQL 表中，但随着时间的推移，它不会变得很大吗？
任何帮助表示赞赏！
I have got my website loggin user activity into a .txt file. I want to be able to show these results on my Admin area in separate pages. So page one shows 1-50 results and so on.
But the problem I have is it's set out like this in the .txt file
User: Admin
IP Address: xx.xxx.xxx.xx
Host Address: xxxxxxxxxxxxxxxx
Date And Time: Monday 20th of September 2010 11:44:18 AM
URL: http://colemansystems.psm2.co.uk/
Browser: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.62 Safari/534.3
Refering URL:
With a gap of seven lines, between each set of information. I was thinking about putting it into a MySQL table but wouldn't that get very big over time?
Any help is appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
那么如果变大了怎么办？这就是数据库的用途。
让我向您保证，从长远来看，设置数据库和表的[一次性]成本将比维护自制（如自定义格式）数据文件要少得多。
如果您想通过 IP 地址 1.2.3.4 了解 2010 年 9 月 25 日至 -26 年间发生的情况该怎么办？你要写一个函数吗？ （这是 SQL 中的单个语句。）您要扫描整个文件吗？ （正确的 DBMS 将只使用索引。MySQL 将至少使用一个索引。）
我倾向于说“两种方法都尝试一下，看看从长远来看 DB 方法如何获胜”，因为优点太多，无法一一列举。
So what if it gets big? That's what databases are for.
Let me assure you that the [one-time] cost of setting up a database and a table will be much less than maintaining a homebrew (as in custom-format) data file in the long run.
What if you want to know what happened between 2010-09-25 and -26 via the IP address 1.2.3.4? Are you going to write a function? (It's a single statement in SQL.) Are you going to scan the whole file? (Proper DBMS's will just use the indices. MySQL will use at least one index.)
I'm half inclined to say "try them both and see how the DB approach wins in the long run" because the advantages are too numerous to list.
如果您要查询数据库表，而不是仅仅查看某些监视器（例如unix tail）中的日志，那么数据库表似乎更适合于此。
随着时间的推移，它会变得非常大，这就是为什么如果您发现性能下降，您可以通过不时删除旧条目来修剪它。您可以设置一个脚本，对表中所有早于 1 个月的条目运行 DELETE 查询。然后您可以安排该脚本每天运行。
如果您确实需要所有日志（甚至较旧的日志），另一种选择是使用日期分区，但这有点更高级。
坦率地说，假设您设置了正确的索引，那么在您注意到性能下降之前，行数应该达到数千万。
A database table seems more suited for this if you will be querying it, rather than just looking at the logs in some monitor (eg unix tail).
It will get very big over time, which is why you can prune it by deleting older entries every now and then if you notice performance drops. You can setup a script that runs a DELETE query on the table on all entries older than, say, 1 month. Then you can schedule that script to run daily.
Another option will be to use partitioning on date if you truly need all the logs even older ones, but that's a bit more advanced.
Frankly, assuming you setup proper indexes, the row count should enter the tens of millions before you notice any degradation of performance.
任何现代数据库，包括 MySQL，都会在合理的时间内处理对正确索引的表的查询，其中包含数千万行。这就是他们的目的。。
我通常的经验法则是，对于任何最多 10,000 行的表和简单的查询，您甚至不需要过多考虑数据访问路径或其他任何内容。在 10,000 到 100 万行范围内，我会特别注意确保表正确索引，超过 100 万行，则可能需要更先进的管理技术来保持性能可接受（尽管对于简单的日志表来说，这将是问题较少）。
Any modern database, including MySQL, will handle queries on a properly indexed table in reasonable time with several tens of millions of rows in it. That's what they're for.
My usual rule of thumb is that for any table up to 10,000 rows and straightforward queries you don't even need to think too hard about data access paths or anything else. In the 10,000 to 1 million row range I would be giving it significant attention to ensure the table was properly indexed, and beyond a million row then more advance management techniques may be required to keep performance acceptable (although for a simple log table this would be less of an issue).