-
1 # ShuangLiu07
-
2 # aixiefang
透過對資料庫慢SQL的跟蹤分析,可以解決資料庫的效能問題,但是當涉及到數量變多的時候,就需要有平臺支撐相關工作。SQL的慢查平臺,要能夠實現從前端到後端的SQL跟蹤分析能力,自動給出一定的最佳化建議,進而可以提升業務效能。平臺核心的功能在於,能夠實現慢語句的自動化採集,同時也能自動發現數據庫中產生阻塞的語句,即使推送相關資訊,目標則是準確、快速的發現慢SQL,從而快速解決生產故障。聽雲全鏈路APM監控可以實時追蹤、快速定位問題,記錄關鍵交易的每次異常,業務執行過程中,每個系統處理耗時分別是多少,使用者體驗效能問題端到端精準定位,跨應用追蹤。你也可以去聽雲諮詢看看,希望可以幫到你。
-
3 # 君聊創業
定位資料庫慢查詢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 = onlog_destination = "stderr"log_directory = "log"log_filename = "postgresql-%Y-%m-%d_%H%M%S.log"
查詢控制檯檢視當前慢查詢設定:
show log_min_duration_statement;
===>5s
回覆列表
你這個問題其實是Application performance management的範疇,APM中最主要的一個部分就是慢sql監控,可以快速定位和監控,相關有很多公司的產品,我就不做廣告了,自己搜吧
如果不需要全套APM,其實自己寫一個簡單監控api/sql效能的程式也是很容易的,實現難度並不複雜。當然,獨立跑壓力測試把所有sql都過一遍,也能確定哪些是慢sql