寵物集市-寵物集市華東、華南、華北排行榜一覽表
1901
2025-03-31
SQL里進行分組的時候,如何才能使用索引?
group by是否能用索引呢?有時做個group by把數據分組,接著用count、sum之類的聚合函數做聚合統計。
假設執行類似
select count(*) from table group by xx
看起來必須把你所有的數據放到一個臨時磁盤文件里還有加上部分內存,去搞一個分組,按照指定字段的值分成一組一組的,接著對每一組都執行一個聚合函數,這個性能也是極差的,因為畢竟涉及大量的磁盤交互。
因為索引樹默認按指定的一些字段都排序好的,字段值相同的數據都是在一起的,若走索引去執行分組后再聚合,那性能一定比臨時磁盤文件好多了。
所以一般對于group by后的字段,最好也是按聯合索引里的最左側字段開始,按序排列,這樣就能完美利用索引直接提取一組組數據,然后針對每組數據,執行聚合函數。
這group by和order by利用索引的原理和條件差不多,本質都是在group by和order by之后的字段順序和聯合索引中的從最左側開始字段順序一致,然后就能利用索引樹里已排序的特性,快速根據排序好的數據執行后續操作了。
這就無需針對雜亂數據利用臨時磁盤文件加上部分內存數據結構進行耗時耗力的現場排序和分組,那真是速度慢,性能差。
平時設計表里的索引的時候,必須充分考慮到后續你的SQL語句要怎么寫,大概會根據哪些字段來進行where語句里的篩選和過濾?大概會根據哪些字段來進行排序和分組?考慮好后,就能為表設計兩三個常用的索引,覆蓋常見的where篩選、order by排序和group by分組的需求,保證常見的SQL語句都可以用上索引,這樣你真正系統跑起來,起碼是不會有太大的查詢性能問題。
畢竟只要你所有的查詢語句都可以利用索引來執行,那么速度和性能通常都不會太慢。如果查詢還是有問題,那就要深度理解查詢的執行計劃和執行原理了,然后基于執行計劃來進行深度SQL調優。
然后對于更新語句而言,其實最核心的就是三大問題:
索引別太多,索引太多了,更新的時候維護很多索引樹肯定是不行
可能會涉及到一些鎖等待和死鎖的問題
可能會涉及到MySQL連接池、寫redo log文件之類問題
SQL
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。