客戶最近一直反饋，客戶頁面打開比較卡又沾，100條數(shù)據(jù)列表頁基本都在15秒以上，但幾次遠(yuǎn)程測試都是正常熙卡，就沒有徹底去跟蹤分析杖刷，今天再次反饋，覺得徹底排查一下驳癌。拿了一張A4紙張,想想都有哪些可能：
1滑燃、數(shù)據(jù)庫數(shù)據(jù)量已經(jīng)達(dá)到百萬級別，查詢語句需要優(yōu)化
2颓鲜、接口調(diào)用時間比較久
3表窘、前端獲取數(shù)據(jù)比較多，渲染用時比較久
有了思路甜滨，就按照這個思路一一去排查
1乐严、數(shù)據(jù)庫使用mysql，之前就開啟了mysql的慢日志功能艳吠，使用的是默認(rèn)參數(shù)麦备，查看日志發(fā)現(xiàn)慢日志中并沒有異常，于是決定修改查詢時長記錄大于1秒的查詢并且記錄無索引查詢的SQL語句昭娩。
long_query_time =1凛篙；
log-queries-not-using-indexes = on ；
慢日志豁然開朗栏渺，數(shù)據(jù)越來越多呛梆，使用mysqldumpslow進(jìn)行分析發(fā)現(xiàn)問題，使用expain對SQL進(jìn)行詳解磕诊，針對需要增加索引的字段增加索引填物。
同時對于SQL語句進(jìn)行優(yōu)化，優(yōu)化方案參考：https://www.2cto.com/database/201801/716363.html
數(shù)據(jù)庫優(yōu)化后發(fā)現(xiàn)系統(tǒng)訪問速度有所提升霎终，但是依舊無法接受滞磺。
2、接口調(diào)試莱褒，使用谷歌瀏覽器击困，Network定位用時較長的接口，對該接口代碼進(jìn)行一行加一行屏蔽測試广凸，最終定位出問題阅茶，代碼邏輯出錯蛛枚，誤將單次查詢函數(shù)放到循環(huán)邏輯中，導(dǎo)致接口多余執(zhí)行N次函數(shù)脸哀，浪費(fèi)了大量時間蹦浦，修改后接口速度提升了。
3撞蜂、前端渲染比較慢盲镶，和前端工程師了解了一下，發(fā)現(xiàn)獲取到100條數(shù)據(jù)谅摄，就直接去渲染100條徒河，所以真?zhèn)€渲染的時間比較長，由于單屏幕只能顯示20條數(shù)據(jù)送漠，所以讓前端進(jìn)行優(yōu)化顽照，只渲染20條數(shù)據(jù)，當(dāng)拖動列表頁的滾動條時闽寡，再去加載下20條（未調(diào)整完畢）
至此1代兵、2已經(jīng)調(diào)整完畢，100條數(shù)據(jù)列表頁顯示維持在3秒爷狈，相信前端優(yōu)化完畢后植影，能控制在1秒-1.5秒。
