資料庫查詢慢問題分析
sql資料庫跟蹤結果分析
區域性分析儲存過程gsp_gr_usertakescore
分析工具: sql server profiler
1. 執行 資料庫測試資訊 分析物件 gsp_gr_usertakescore [pic 1]
2. 本地 資料庫測試資訊 分析物件 gsp_gr_usertakescore[pic 2]
對比上面兩張圖的分析結果 : 根據觀察pic 1中四個框內的資訊, 下面逐個分析原因和解決方法(按照圖中紅框從上到下的順序)
1. select 語句中使用了 linked server 在這裡也就是qpaccountsdblink, 這個技術是針對資料庫的分布式使用(link linked server), 我們現在使用的主要的三個資料庫都沒有採用分布式的部署, 所以如果針對這種情況去掉前面的linked server此類語句的執行速度回大幅度的提公升
問題語句:
select@enjoinlogon=enjoinlogonfromconfinemachine(nolock)wheremachineserial=@strmachineidand getdate()
處理方案:[執行資料庫只是部署在local之上]
[測試結果:去掉link server之後時間消耗是之前的十分之一還少]
[注] 紅框1,2 都是同樣的情況不再贅述
2. sql server 在處理的過程中自動新增的inserted 和 deleted表
問題語句:
if((@insertedscore-@deletedscore)<>0or(@insertedinsure-@deletedinsure<>0))and(@dwuseridnotin(selectuseridfromqpaccountsdb.dbo.accountsinfowhereisandroid=1))--profiler中擷取
處理方案:link: inserted and deleted
link: 資料庫效能優化之sql語句優化
解決法案: 阻止sql server內部的自動新增表的處理, 不確定可行性, 需要繼續深入。
3. 執行緒阻塞 硬體問題
問題語句:
updategamescoreinfosetscore=score+@variationscore,insurescore=insurescore+@variationinsure,revenue=revenue+@insurerevenue
問題分析:對比本地的profiler執行結果和server的執行結果(pic1, pic2), 發現同樣的資料庫在server上引起了80000+的reads(*reads: 由伺服器代表事件讀取邏輯磁碟的次數*)
以及觀察sql server中的執行計畫(下圖)。未發現異常的情況,
[本地]
所以, 推斷問題的主要原因是高併發, 也許還有硬體的問題。
處理方案:見下文對latch_ex(獨佔鎖的分析).
資料庫thread等待時間分析
分析工具:
我們資料庫的執行緒阻塞情況 [pic 3]
一般執行緒阻塞情況 [pic 4]
問題分析:
可以嘗試的解決方案(尚未完成)下一步任務
遮蔽sql server的inserted 和 deleted 操作
資料分析 時序資料庫
海量資料分析類系統的設計主要面臨2個大問題 優勢和劣勢 加入了hadoop體系的生態圈，更加容易被接受，同時省去了研發分布式儲存系統的麻煩，更多的是在分布式查詢上做優化。但無法在儲存上做更加深度的優化，比如沒有倒排索引支援，過濾查詢速度可能相對弱些，後面會重點分析下opentsdb的困局。優勢和劣勢...
資料庫資料分析思路記錄
1 問題原因 由於資料庫匯入錯誤，導致資料插入不完整，其中有json串格式的沒有插入進去，不知道哪乙個庫匯入失敗，哪一張表建立失敗，所以後台專案啟動失敗 由於表有幾百張不能去一一比對，所以產生以下解決方法。2 解決思路 將初始庫中表的結構及資料與匯入失敗的庫中表的結構與資料進行對比，將資料插入不完整...
資料庫元資料分析Demo
核心類 databasemetadata resultsetmetadata 1 system.err.println 2 connection conn datasourceutils.getdatasource getconnection 3 databasemetadata dbmd conn...