主頁 > 知識庫 > Mysql索引性能優(yōu)化問題解決方案

Mysql索引性能優(yōu)化問題解決方案

熱門標簽:Linux服務器 呼叫中心市場需求 網(wǎng)站排名優(yōu)化 鐵路電話系統(tǒng) 地方門戶網(wǎng)站 服務外包 百度競價排名 AI電銷

mysql 創(chuàng)建的優(yōu)化就是加索引,可是有時候會遇到加索引都沒法達到想要的效果的情況,

加上了所以,卻還是搜索的全數(shù)據(jù),原因是sql

EXPLAIN  SELECT
      cs.sid,
      -- c.courseFrontTitle,
      -- c.imgBig,
      cs.studyStatus,
      coi.fee,
      -- act.PROC_INST_ID_ AS processId,
      cs.createDTM,
      cs.payStatus,
      cs.isCompleted,
      cs.saleChannel,
cs.isDelete
    FROM
      Biz_CourseStudy cs

    LEFT JOIN Biz_CourseOrderItem coi ON   cs.sid = coi.CourseStudyID 
    
    WHERE
      cs.studentID = 00001 and cs.payStatus not in(0)

通過看索引,原因是因為sid為bigint , CourseStudyID 的類型確實varchar,原因就是在這里,修改類型為bigint后,查詢速度瞬間提升.

遇到過這樣一種情況,分析extra,去掉order by 0.6s速度OK,加上order by 6s

解決方法,給order by 創(chuàng)建索引,這里我的order by是兩個字段

order by endTime desc ,isDelete desc

為a b 創(chuàng)建聯(lián)合索引, index_a_b

SELECT xxx FROM manage a FORCE INDEX(index_a_b)
LEFT JOIN f_name f ON f.user_id = a.user_id
ORDER BY a.endTime desc,a.isDelete desc 

此時看性能,Using filesort已經(jīng)消失

速度直接變成0.6s

以上就是本文的全部內(nèi)容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。

您可能感興趣的文章:
  • MySQL 如何分析查詢性能
  • MySQL創(chuàng)建高性能索引的全步驟
  • MySQL性能壓力基準測試工具sysbench的使用簡介
  • Mysql性能優(yōu)化之索引下推
  • MySQL性能突然下降的原因
  • MySQL性能優(yōu)化技巧分享
  • MySQL20個高性能架構設計原則(值得收藏)
  • Mysql高性能優(yōu)化技能總結
  • 詳解GaussDB for MySQL性能優(yōu)化

標簽:衡水 仙桃 湖南 崇左 蘭州 湘潭 銅川 黃山

巨人網(wǎng)絡通訊聲明:本文標題《Mysql索引性能優(yōu)化問題解決方案》,本文關鍵詞  ;如發(fā)現(xiàn)本文內(nèi)容存在版權問題,煩請?zhí)峁┫嚓P信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡,涉及言論、版權與本站無關。
  • 相關文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266