對於是否在生產中記錄SQL查詢,我還有一個兩難的問題。在生產中記錄SQL查詢?
我不知道在PHP中寫文件有多慢。可能有些基準可以給出一些答案,但我想看看你們以前的想法。
什麼使或不使過程變慢?或者它可能依賴於什麼?
對於是否在生產中記錄SQL查詢,我還有一個兩難的問題。在生產中記錄SQL查詢?
我不知道在PHP中寫文件有多慢。可能有些基準可以給出一些答案,但我想看看你們以前的想法。
什麼使或不使過程變慢?或者它可能依賴於什麼?
大多數數據庫都有用於記錄查詢和緩慢查詢的內置選項,因此您不需要通過PHP進行日誌記錄。除非遇到問題,否則不應將所有查詢記錄在生產環境中,這是故障排除過程的一部分。您可以也應該記錄緩慢的查詢,以便查看可能會減慢生產站點的速度。
如果你的框架支持它,只有當頁面花了一定的時間才能生成(這是我所做的)時,你纔可以記錄查詢。然後您有條件地進行日誌記錄,並可能發現運行的查詢數量過多。
你有幾個選擇:
好了,1號的事情,這將是緩慢的將磁盤IO通過打黑D b。最好的答案是讓你在一些不平凡的情況下嘗試它(記住,小n的一切都很快),並詢問一些利益相關者是否可以接受。這可能不是你之後的答案,但它確實是最好的答案。
爲了記錄(您沒有指定您的數據庫),Postgresql有一個與日誌相關的bunch of options。其中,我使用log_min_duration_statement來記錄運行時間超過N秒的查詢。用於性能分析,無需填寫日誌文件並干擾性能。我敢打賭大多數數據庫都有類似的東西。
注意內置數據庫日誌記錄,如果不慎重應用,可能會降低整體性能 – pcent 2010-06-04 18:07:40
這是我們在應用程序上執行的操作。如果速度慢,我們會記錄查詢並在日誌消息中放入一個易於理解的字符串。如果我們想要所有的查詢,我們去dbas。如果您依賴於數據庫查詢日誌,建議在每個查詢中添加一個唯一的註釋字符串,以便您可以知道它來自哪個應用程序。這很好,因爲我們關心的是什麼出錯,而不是發生的一切。 – 2010-06-04 18:08:32
這就是我們所做的。 MySQL記錄它自己的查詢,而慢日誌是分開的。日誌是文本文件(與用於複製和恢復的二進制事務日誌文件不同),並且可以非常快速地追加到日誌中。此外,日誌記錄是在與系統和數據庫不同的物理磁盤上完成的,這樣可以避免磁盤爭用。 – 2010-06-04 18:09:34