天天看點

資料庫優化

 資料庫優化

1.在查詢字段上建立索引

類似目錄,是對資料表中一列或多列的值進行排序的一種結構,友善快速查找到資料

索引:普通索引、唯一索引、全文索引、Btree索引、hash索引……

建立索引是資料庫優化各種方案之中成本最低,見效最快的解決方案,一般來講,資料庫規模在幾十萬和幾百萬級别的時候見效最快,即便是有不太複雜的表關聯,也能大幅度提高sql的運作效率,這個在我們以前的項目應用中,有非常深刻的體會,本來耗時50s的sql,在增加索引後可以提升到1-2s,而且不需要有代碼改動,成本低廉,見效明顯

索引缺點:

第一,建立索引和維護索引要耗費時間,這種時間随着資料量的增加而增加。

第二,索引需要占實體空間,除了資料表占資料空間之外,每一個索引還要占一定的實體空間,如果要建立聚簇索引,那麼需要的空間就會更大。

第三,當對表中的資料進行增加、删除和修改的時候,索引也要動态的維護,這樣就降低了資料的維護速度。

2.分庫分表

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

        分表,剛才說了,索引适合應對百萬級别的資料量,千萬級别資料量使用的好,勉強也能湊合,但如果是上億級别的資料量,索引就無能為力了,因為單索引檔案可能就已經上百兆或者更多了,那麼,輪到我們的分表分區登場了

        分表的方法有很多種

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

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

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

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

資料庫引擎

 mysql比較常用的資料庫引擎有兩種,一種是innodb、一種是myisam 

            我當時做過一個千萬級資料量複雜sql測試,myisam的效率大概能夠比innodb快1-2倍,雖然效率提升不是很明顯,但是也有提升,後來查過一些資料,說之是以mysiam快,是因為他的資料存儲結構、索引存儲結構和innodb不一樣的,mysiam的索引結構是在記憶體中存的

            當然,mysiam也有弱點,那就是他是表級鎖,而innodb是行級鎖,是以,mysiam适用于一次插入,多次查詢的表,或者是讀寫分離中的讀庫中的表,而對于修改插入删除操作比較頻繁的表,就很不合适了