定位數據庫慢查詢SQL有多種方式，根據具體使用的數據庫種類和經濟實力來定：
一、使用APM產品
APM全程為Application Performance Management，軟硬件解決方案都有，如果經濟實力不錯，直接買大廠商的APM產品最為省時省力，而且還附帶報警和分析功能。
APM不僅是管理數據庫性能的，還可以對應用服務器進行檢測，對JAVA、.NET、php、Ruby、Python、NodeJS等語言開發的應用程序性能進行監測。
目前市面上很多，有像深信服等提供的集成在硬件中的一體機式的，還有一些純軟件的APM產品，例如像OneAPM那樣即可以本地部署的，還可以本地安裝彈針然后云端SaaS部署的。這里就不一一列舉了，大家可以根據自己預算找相應的廠家咨詢。
二、使用專門的數據庫監測產品
市面上還有一類小眾的專門針對數據庫的產品。大部分都是多年DBA在自己多年的數據庫運維經驗基礎上針對某種數據庫定制的監測系統，除了針對數據庫各個性能指標進行監測報警外，還提供智能分析和性能優化等服務。
例如作為微軟中國SQL Server金牌合作伙伴的北京格瑞趨勢公司所推出的SQL專家云等產品，是專門針對微軟SQL Server數據庫某一段時間的采樣數據分析、診斷，主要的應用場景包括：對數據庫進行體檢，自動形成體檢報告；分析當前系統存在的問題及隱患；分析采樣時段的性能問題及根源；分析數據庫的參數配置及索引；自動優化并生產可執行的腳本。
三、使用開源運維監控系統
例如Zabbix、NagIOS、Grafana、Open-falcon等，這些開源系統同APM產品類似，但主要是提供給服務器運維人員使用的，內置了一部分數據庫監控的功能，有的插件很多，功能和界面都還是不錯的。
但是開源產品的安裝和使用需要有較高水平的運維人員來使用，需要自己來摸索適合的方式，針對性也不夠強。而且由于缺少支持，遇到問題解決起來比較麻煩。
四、使用數據庫系統自身的日志功能
許多數據庫的日志系統都帶有慢查詢記錄功能，對于流量不大的系統，又不想投入大量金錢，可以先直接使用數據庫日志來記錄慢查詢，然后定期匯總分析，持續優化應用程序系統。一般用在開發期，或系統剛上線的試運行期。
例如MySQL的慢查詢日志，它用來記錄在MySQL中響應時間超過閥值的語句，具體指運行時間超過long_query_time值的SQL，則會被記錄到慢查詢日志中。long_query_time的默認值為10，意思是運行10S以上的語句。默認情況下，Mysql數據庫并不啟動慢查詢日志，需要我們手動來設置這個參數，當然，如果不是調優需要的話，一般不建議啟動該參數，因為開啟慢查詢日志會或多或少帶來一定的性能影響。
MySQL 慢查詢的相關參數解釋：
slow_query_log ：是否開啟慢查詢日志，1表示開啟，0表示關閉。
log-slow-queries ：舊版（5.6以下版本）MySQL數據庫慢查詢日志存儲路徑。可以不設置該參數，系統則會默認給一個缺省的文件host_name-slow.log
slow-query-log-file：新版（5.6及以上版本）MySQL數據庫慢查詢日志存儲路徑。可以不設置該參數，系統則會默認給一個缺省的文件host_name-slow.log
long_query_time ：慢查詢閾值，當查詢時間多于設定的閾值時，記錄日志。
log_queries_not_using_indexes：未使用索引的查詢也被記錄到慢查詢日志中（可選項）。
log_output：日志存儲方式。log_output='FILE'表示將日志存入文件，默認值是'FILE'。log_output='TABLE'表示將日志存入數據庫，這樣日志信息就會被寫入到mysql.slow_log表中。MySQL數據庫支持同時兩種日志存儲方式，配置的時候以逗號隔開即可，如：log_output='FILE,TABLE'。日志記錄到系統的專用日志表中，要比記錄到文件耗費更多的系統資源，因此對于需要啟用慢查詢日志，又需要能夠獲得更高的系統性能，那么建議優先記錄到文件。
Postgrsql也有類似的慢查詢日志記錄方式，PostgreSQL 日志支持的輸出格式有 stderr（默認）、csvlog 、syslog。一般的錯誤跟蹤，只需在配置文件“postgresql.conf”簡單設置幾個參數，當然還有錯誤級別等要設置。
Postgresql 慢查詢配置相關參數：
logging_collector = on
log_destination = 'stderr'
log_directory = 'log'
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'查詢控制臺查看當前慢查詢設置：
show log_min_duration_statement;
===>5s
