在生产中记录 SQL 查询？
我在是否也在生产中记录 SQL 查询时遇到了困境。
我不知道用PHP写文件有多慢。也许一些基准测试可以给出一些答案，但我想看看你们之前是怎么想的。
什么会或不会使该过程变慢？或者说它取决于什么？
I'm having a dilemma on whether or not to log SQL queries in production as well.
I don't know how slow writing files is in PHP. Probably some benchmarks could give some answers, but I wanted to see what you guys think before.
What does or does not make the process slow? Or what things could it depend on?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
大多数数据库都有用于记录查询和慢速查询的内置选项，因此您不需要通过 PHP 进行记录。您不应该记录生产中的所有查询，除非遇到问题并且这是故障排除过程的一部分。您可以而且应该记录缓慢的查询，以便您可以了解可能导致生产站点速度减慢的原因。
如果您的框架支持它，则仅当页面花费一定时间来生成时才可以记录查询（这就是我所做的）。然后，您有条件地记录日志，可能会发现正在运行的查询数量过多。
Most databases have built-in options for logging queries and slow queries, so you shouldn't need log through PHP. You should not log all queries in production unless you are having problems and it's part of a troubleshooting process. You can and should log slow queries so you can see what may be slowing down your production site.
If you framework supports it, you can log queries only if the page took a certain amount of time to generate (this is what I do). Then you are logging conditionally and may discover an excessive number of queries being run.
您有几个选择：
You have a couple options:
根据记录（您没有指定数据库），Postgresql 有一个 一堆与日志记录相关的选项。其中，我使用log_min_duration_statement来记录运行时间超过N秒的查询。对于分析很有用，不会填充日志文件并干扰性能。我敢打赌大多数数据库都有类似的东西。
For the record (you didn't specify your DB), Postgresql has a bunch of options related with logging. Among them, I use log_min_duration_statement to log the queries that ran for more than N seconds. Useful for profiling, without filling your log files and interfering with performance. I'd bet most databases have something similar.
嗯，速度慢的第一件事是通过访问数据库进行磁盘 IO。最好的答案是你在一些重要的情况下尝试一下（记住，对于小 n 来说一切都很快），并询问一些利益相关者性能是否可以接受。这可能不是您想要的答案，但这确实是最好的答案。
Well, the number 1 thing that would be slow would be disk IO via hitting the db. The best answer is for you to try it in some non-trivial cases (remember, everything is fast for small n) and ask some stakeholders if the performance is acceptable. It might not be the answer you are after, but it's really the best answer.