您好,登錄后才能下訂單哦!
這篇文章主要為大家展示了“mysql中SQL優化的示例分析”,內容簡而易懂,條理清晰,希望能夠幫助大家解決疑惑,下面讓小編帶領大家一起研究并學習一下“mysql中SQL優化的示例分析”這篇文章吧。
背景:告警查詢接口較慢,一般都在2.5秒左右,由于是UI查詢,這個時間較長,對于用戶有點不可接受
目的:控制查詢接口的速度在1秒左右
優化收獲:
1、order by
order by 后面的列也需要執行計劃匹配上索引才會高效。
不一定用了order by 就一定慢,有時候說不定會更快,更快的情況,一般是由于,order by 的列經過mysql分析后選擇了一個適合order by以及where后條件的索引;而去掉order by后反而使用了一個差的索引,從而導致去掉order by后反而查詢會變慢。案例如下:
沒有order by 反而慢了
看下執行計劃,并沒有使用INDEX_STATUS_LEVEL
使用order by 試試:
可見變快了,看下執行計劃:
2、mysql 的索引選擇
mysql會根據自身的邏輯選擇索引,但是實測下來不一定是最優的,經過多次測試發現,mysql將alertstatus和leveles兩個字段的索引進行合并的時候,速度最快。最終通過加了status_level聯合索引解決了。
第二點解決了項目sql優化的問題,其它點為優化過程中的收獲。
3、find_in_set函數
這個函數性能較差,需要將數據轉換為多行。
4、并不是所有索引對查詢都有效(如第二點的感悟),SQL是根據表中數據來進行查詢優化的,當索引列有大量數據重復時,SQL查詢可能不會去利用索引,如一表中有字段sex,male、female幾乎各一半,那么即使在sex上建了索引也對查詢效率起不了作用。
5、盡量使用數字型字段,若只含數值信息的字段盡量不要設計為字符型,這會降低查詢和連接的性能,并會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符,而對于數字型而言只需要比較一次就夠了。
6、盡量避免大事務操作,提高系統并發能力
7、盡量避免向客戶端返回大數據量,若數據量過大,應該考慮相應需求是否合理。
8、排查命令一:show global status;
可以列出MySQL服務器運行各種狀態值
以上是“mysql中SQL優化的示例分析”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。