數據庫優化一般思路(PLSQL、Navicat)


SQL執行過程:

1、執行SQL時,sql解析引擎會被啟動

2、數據類型和數據庫表定義的數據類型不一致,數據庫引擎會自動轉化

3、數據庫表定義了多個索引,sql引擎會幫你選擇最優的一個

4、數據庫引擎會拿着優化好的sql命令語義去硬盤中查找數據,然后將查找到的數據返回(如果此時返回的結果集過大,會造成數據庫IO繁忙,會大大損傷sql效率,所以一般我們都使用分頁的原因就在於此)

 

SQL優化

一、索引:一般來講,數據庫規模在幾十萬和幾百萬級別的時候見效最快,即便是有不太復雜的表關聯,也能大幅度提高sql的運行效率。不需要有代碼改動,成本低廉,見效明顯。
1、索引一般加在查詢條件的關鍵字上,如果有多個查詢條件關鍵字,還可以添加組合索引,寫sql的時候需要注意,索引字段和sql字段需要保持一致,否則索引會無效。
2、不要在查詢=前面使用函數,否則會導致索引不生效。
3、建立索引的字段要區分度比較高
4、建立組合索引,可以持續提升sql運行效率,但是也不要盲目,同樣的要注意區分度,如果區分度不夠高,就不要加了,多個字段,盡可能把區分度高的字段放在前面,另外,還要注意索引長度,這個索引要同時兼顧索引長度和區分度的平衡
5、索引會大幅提升查詢效率,但是也會損耗查詢后修改效率,要注意兼顧平衡,使用在一次插入,多次查詢的表上效果最好,同時要注意的是,組合索引會不可避免的增加索引長度,會增加索引存儲空間,注意索引長度和區分度平衡
6、mysql居然支持全文索引,沒測試過效率,正常使用全文索引都是使用 lunce,以及在其之上的solr和現在正火的elastisearch。

 

二:分庫分表分區

1、分庫

可以按照業務分庫,分流數據庫並發壓力,使數據庫表更加有條理性,最起碼更加好找吧,我們當時是把查詢庫和系統庫(增刪改比較頻繁的表)分開了,這樣如果有大查詢,不影響系統庫

2、分表

索引適合應對百萬級別的數據量,千萬級別數據量使用的好,勉強也能湊合,但如果是上億級別的數據量,索引就無能為力了,因為單索引文件可能就已經上百兆或者更多了,那么,輪到我們的分表分區登場了。

分表方法:

a、如果這個業務是有流程的,那么我們通常會設計一個歷史表或者歸檔表,用來存放歷史數據,這樣能保證實時數據效率比較高

b、針對某一張大表,可以根據查詢條件分成多張表,比如時間,我們可以將半個月或者10天的數據放到一張表里(看具體數據量,個人認為3000W是個上限,最好控制到百萬級別),每過10天,我們就自動創建一張數據庫表,然后將數據插入,如此,按照時間查詢,就要先定位去那種表中去取數,這樣,效率能夠得到大幅度提升,當然,這么解決也有問題,比如跨表,需要union多張表,而且跨表沒法支持索引

c、上面的方法是我們直接通過程序和數據庫實現的最原始的分表解決方案,現在市面上有一些成熟的軟件如mycat,也是支持分表的,我們之前從事的公司有個專門做分布式數據庫的,這些產品出現跨表,可以不使用程序union了,而且還是使索引生效,但是需要對產品有一定的掌握

d、一般來講,數據庫中的大表畢竟只是一少部分,僅需要對這少部分大表進行分表就可以了,沒必要小表也進行分表,增加維護開發難度

 

3、分區

三:數據庫引擎

個千萬級數據量復雜sql測試,myisam的效率大概能夠比innodb快1-2倍,雖然效率提升不是很明顯,但是也有提升,后來查過一些資料,說之所以mysiam快,是因為他的數據存儲結構、索引存儲結構和innodb不一樣的,mysiam的索引結構是在內存中存的,當然,mysiam也有弱點,那就是他是表級鎖,而innodb是行級鎖,所以,mysiam適用於一次插入,多次查詢的表,或者是讀寫分離中的讀庫中的表,而對於修改插入刪除操作比較頻繁的表,就很不合適了

四:預處理

1、實時數據(當天數據) 通過對對業務的抽象,可以放在緩存里面,提升系統運行效率。
2、史數據,大數據表歷史數據且有表關聯,通過常規sql難以優化,但是該數據通常有個共性,就是第二天去查詢前一天的數據做分析報表,也就是說對時效性要求不高,這種情況的解決方案是預處理。做法是將這些復雜表關聯sql寫成個定時任務在半夜執行,將執行的結果存入到一張結果表中,第二天直接查詢結果表,如此,效率能得到十分明顯提升
3、可以將表關聯結果存入solr或者elastisearch中,以此提升效率,目前我們的項目就是如此處理。

五:Like 查詢

大家都知道,like  “%str%” 不支持索引, "str%"號是支持索引的因此,如果業務允許,可以使用前匹配的方法是數據庫快速定位到數據,在結果集中再進行like匹配,如果這個結果集不是很大,是可以大幅提升運行效率的,這個需要對業務和程序有靈活的變通,如果業務實在不允許前匹配,那就可以采用solr或者elastisearch來進行模糊匹配,但是進行模糊匹配有個前提,原始數據是字符串的話,不要帶有特殊符號,如#,&,% 等,這樣會造成分詞不准,最終導致查詢結果不正確

六:讀寫分離

在數據庫並發大的情況下,最好的做法就是進行橫向擴展,增加機器,以提升抗並發能力,而且還兼有數據備份功能


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM