資訊專欄INFORMATION COLUMN
摘要：利用表分區(qū)參考這個是推薦的一個解決方案，不會帶來重寫邏輯等，可以根據(jù)時間來進行表分區(qū)，相當于在同一個磁盤上，表的數(shù)據(jù)存在不同的文件夾內(nèi)，能夠極大的提高查詢速度。有不好的地方，請指點一下，謝謝。
原發(fā)布：http://river0314.lofter.com/p...
有一個大數(shù)據(jù)表，有30個字段，int varchar text 字段都有，1000W+數(shù)據(jù)，每天都會增加，經(jīng)常搜索的字段有10個，這個怎么優(yōu)化？
請教了一個人，才得到差不多的答案，感覺這種問題有點假，現(xiàn)實中基本不會出這種問題吧？
優(yōu)化方案：
主從同步+讀寫分離：
這個表在有設備條件的情況下，讀寫分離，這樣能減少很多壓力，而且數(shù)據(jù)穩(wěn)定性也能提高
縱向分表：
根據(jù)原則，每個表最多不要超過5個索引，縱向拆分字段，將部分字段拆到一個新表
通常我們按以下原則進行垂直拆分:（先區(qū)分這個表中的冷熱數(shù)據(jù)字段）
把不常用的字段多帶帶放在一張表;
把text，blob等大字段拆分出來放在附表中;
經(jīng)常組合查詢的列放在一張表中;
缺點是：很多邏輯需要重寫，帶來很大的工作量。
利用表分區(qū)：
參考：https://my.oschina.net/ydsaky...
這個是推薦的一個解決方案，不會帶來重寫邏輯等，可以根據(jù)時間來進行表分區(qū)，相當于在同一個磁盤上，表的數(shù)據(jù)存在不同的文件夾內(nèi)，能夠極大的提高查詢速度。
橫向分表：
1000W條數(shù)據(jù)不少的，會帶來一些運維壓力，備份的時候，單表備份所需時間會很長，所以可以根據(jù)服務器硬件條件進行水平分表，每個表有多少數(shù)據(jù)為準。
有不好的地方，請指點一下，謝謝。
文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/22771.html
摘要：正是存在問題，促使我們考慮引入數(shù)據(jù)庫審核平臺。的確，與很多互聯(lián)網(wǎng)公司相比，數(shù)據(jù)庫數(shù)十套的估摸并不是太大但與互聯(lián)網(wǎng)類公司不同，類似宜信這類金融類公司對數(shù)據(jù)庫的依賴性更大，大量的應用是重數(shù)據(jù)庫類的，且其使用復雜程度也遠比互聯(lián)網(wǎng)類的復雜。 作者：韓鋒 出處：DBAplus社群分享 Themis開源地址：https://github.com/CreditEaseDBA 拓展閱讀：宜信開源|數(shù)...
閱讀 1386·2021-10-08 10:04
閱讀 2707·2021-09-22 15:23
閱讀 2733·2021-09-04 16:40
閱讀 1183·2019-08-29 17:29
閱讀 1503·2019-08-29 17:28
閱讀 3001·2019-08-29 14:02
閱讀 2230·2019-08-29 13:18
閱讀 851·2019-08-23 18:35
