mysql表過(guò)大怎么解決 mysql單表數(shù)據(jù)過(guò)大

mysql的一個(gè)表太大了，400多g,在數(shù)據(jù)庫(kù)里面刪了兩天半都刪不掉，請(qǐng)問(wèn)可

1把需要的記錄導(dǎo)出.

金水網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、響應(yīng)式網(wǎng)站等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)建站從2013年成立到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。

2 把這個(gè)表刪除

3, 建立一個(gè)跟原來(lái)一樣的表,

4 把導(dǎo)出的數(shù)據(jù)導(dǎo)入

MySQL 對(duì)于千萬(wàn)級(jí)的大表要怎么優(yōu)化

提問(wèn)：如何設(shè)計(jì)或優(yōu)化千萬(wàn)級(jí)別的大表？此外無(wú)其他信息，個(gè)人覺(jué)得這個(gè)話題有點(diǎn)范，就只好簡(jiǎn)單說(shuō)下該如何做，對(duì)于一個(gè)存儲(chǔ)設(shè)計(jì)，必須考慮業(yè)務(wù)特點(diǎn)，收集的信息如下：

1.數(shù)據(jù)的容量：1-3年內(nèi)會(huì)大概多少條數(shù)據(jù)，每條數(shù)據(jù)大概多少字節(jié)；

2.數(shù)據(jù)項(xiàng)：是否有大字段，那些字段的值是否經(jīng)常被更新；

3.數(shù)據(jù)查詢SQL條件：哪些數(shù)據(jù)項(xiàng)的列名稱經(jīng)常出現(xiàn)在WHERE、GROUP BY、ORDER BY子句中等；

4.數(shù)據(jù)更新類SQL條件：有多少列經(jīng)常出現(xiàn)UPDATE或DELETE 的WHERE子句中；

5.SQL量的統(tǒng)計(jì)比，如：SELECT：UPDATE+DELETE：INSERT=多少？

6.預(yù)計(jì)大表及相關(guān)聯(lián)的SQL，每天總的執(zhí)行量在何數(shù)量級(jí)？

7.表中的數(shù)據(jù)：更新為主的業(yè)務(wù) 還是 查詢?yōu)橹鞯臉I(yè)務(wù)

8.打算采用什么數(shù)據(jù)庫(kù)物理服務(wù)器，以及數(shù)據(jù)庫(kù)服務(wù)器架構(gòu)？

9.并發(fā)如何？

10.存儲(chǔ)引擎選擇InnoDB還是MyISAM？

大致明白以上10個(gè)問(wèn)題，至于如何設(shè)計(jì)此類的大表，應(yīng)該什么都清楚了！

至于優(yōu)化若是指創(chuàng)建好的表，不能變動(dòng)表結(jié)構(gòu)的話，那建議InnoDB引擎，多利用點(diǎn)內(nèi)存，減輕磁盤IO負(fù)載，因?yàn)镮O往往是數(shù)據(jù)庫(kù)服務(wù)器的瓶頸。

另外對(duì)優(yōu)化索引結(jié)構(gòu)去解決性能問(wèn)題的話，建議優(yōu)先考慮修改類SQL語(yǔ)句，使他們更快些，不得已只靠索引組織結(jié)構(gòu)的方式，當(dāng)然此話前提是， 索引已經(jīng)創(chuàng)建的非常好，若是讀為主，可以考慮打開(kāi)query_cache， 以及調(diào)整一些參數(shù)值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_siz。

更多信息參見(jiàn)：

MySQL數(shù)據(jù)庫(kù)服務(wù)器端核心參數(shù)詳解和推薦配置

不紙上談兵，說(shuō)一下我的思路以及我的解決，拋磚引玉了

我最近正在解決這個(gè)問(wèn)題

我現(xiàn)在的公司有三張表，是5億的數(shù)據(jù)，每天張表每天的增量是100w

每張表大概在10個(gè)columns左右

下面是我做的測(cè)試和對(duì)比

1.首先看engine,在大數(shù)據(jù)量情況下，在沒(méi)有做分區(qū)的情況下

mysiam比innodb在只讀的情況下，效率要高13％左右

2.在做了partition之后，你可以去讀一下mysql的官方文檔，其實(shí)對(duì)于partition，專門是對(duì)myisam做的優(yōu)化，對(duì)于innodb，所有的數(shù)據(jù)是存在ibdata里面的，所以即使你可以看到schema變了，其實(shí)沒(méi)有本質(zhì)的變化

在分區(qū)出于同一個(gè)physical disk下面的情況下，提升大概只有1％

在分區(qū)在不同的physical disk下，我分到了三個(gè)不同的disks下，提升大概在3％，其實(shí)所謂的吞吐量，由很多因素決定的，比如你的explain parition時(shí)候可以看到，record在那一個(gè)分區(qū)，如果每個(gè)分區(qū)都有，其實(shí)本質(zhì)上沒(méi)有解決讀的問(wèn)題，這樣只會(huì)提升寫的效率。

另外一個(gè)問(wèn)題在于，分區(qū)，你怎么分，如果一張表，有三個(gè)column都是經(jīng)常被用于做查詢條件的，其實(shí)是一件很悲慘的事情，因?yàn)槟銢](méi)有辦法對(duì)所有的sql做針對(duì)性的分區(qū)，如果你只是如mysql官方文檔上說(shuō)的，只對(duì)時(shí)間做一個(gè)分區(qū)，而且你也只用時(shí)間查詢的話，恭喜你

3.表主要用來(lái)讀還是寫，其實(shí)這個(gè)問(wèn)題是不充分的，應(yīng)該這樣問(wèn)，你在寫入的時(shí)候，同時(shí)并發(fā)的查詢多么？我的問(wèn)題還比較簡(jiǎn)單，因?yàn)閙ongodb的 shredding支持不能，在crush之后，還是回到mysql，所以在通常情況下，9am－9pm，寫入的情況很多，這個(gè)時(shí)候我會(huì)做一個(gè) view，view是基于最近被插入或者經(jīng)常被查詢的，通過(guò)做view來(lái)分離讀取，就是說(shuō)寫是在table上的，讀在進(jìn)行邏輯判斷前是在view上操作的

4做一些archive table，比如先對(duì)這些大表做很多已有的統(tǒng)計(jì)分析，然后通過(guò)已有的分析＋增量來(lái)解決

5如果你用mysiam，還有一個(gè)問(wèn)題你要注意，如果你的.configure的時(shí)候，加了一個(gè)max index length參數(shù)的時(shí)候，當(dāng)你的record數(shù)大于制定長(zhǎng)度的時(shí)候，這個(gè)index會(huì)被disable

mysql數(shù)據(jù)庫(kù)表太大查詢慢優(yōu)化的幾種方法

優(yōu)化方案：

主從同步+讀寫分離：

這個(gè)表在有設(shè)備條件的情況下，讀寫分離，這樣能減少很多壓力，而且數(shù)據(jù)穩(wěn)定性也能提高

縱向分表：

根據(jù)原則，每個(gè)表最多不要超過(guò)5個(gè)索引，縱向拆分字段，將部分字段拆到一個(gè)新表

通常我們按以下原則進(jìn)行垂直拆分:（先區(qū)分這個(gè)表中的冷熱數(shù)據(jù)字段）

把不常用的字段單獨(dú)放在一張表;

把text，blob等大字段拆分出來(lái)放在附表中;

經(jīng)常組合查詢的列放在一張表中;

缺點(diǎn)是：很多邏輯需要重寫，帶來(lái)很大的工作量。

利用表分區(qū)：

這個(gè)是推薦的一個(gè)解決方案，不會(huì)帶來(lái)重寫邏輯等，可以根據(jù)時(shí)間來(lái)進(jìn)行表分區(qū)，相當(dāng)于在同一個(gè)磁盤上，表的數(shù)據(jù)存在不同的文件夾內(nèi)，能夠極大的提高查詢速度。

橫向分表：

1000W條數(shù)據(jù)不少的，會(huì)帶來(lái)一些運(yùn)維壓力，備份的時(shí)候，單表備份所需時(shí)間會(huì)很長(zhǎng)，所以可以根據(jù)服務(wù)器硬件條件進(jìn)行水平分表，每個(gè)表有多少數(shù)據(jù)為準(zhǔn)。

MySQL 對(duì)于大表，要怎么優(yōu)化

1、做分區(qū)表，（哪個(gè)字段分區(qū)很重要，分錯(cuò)會(huì)影響性能）。

2、拆表，

可以將歷史數(shù)據(jù)放到 其他表中，例如 abc表中，2013年的數(shù)據(jù)，拆到 abc_2013表中，2014年的數(shù)據(jù)拆到abc_2014表中。

mysql 數(shù)據(jù)量超過(guò)百萬(wàn)后怎么處理

我們經(jīng)常會(huì)遇到操作一張大表，發(fā)現(xiàn)操作時(shí)間過(guò)長(zhǎng)或影響在線業(yè)務(wù)了，想要回退大表操作的場(chǎng)景。在我們停止大表操作之后，等待回滾是一個(gè)很漫長(zhǎng)的過(guò)程，盡管你可能對(duì)知道一些縮短時(shí)間的方法，處于對(duì)生產(chǎn)環(huán)境數(shù)據(jù)完整性的敬畏，也會(huì)選擇不做介入。最終選擇不作為的原因大多源于對(duì)操作影響的不確定性。實(shí)踐出真知，下面針對(duì)兩種主要提升事務(wù)回滾速度的方式進(jìn)行驗(yàn)證，一種是提升操作可用內(nèi)存空間，一種是通過(guò)停實(shí)例，禁用 redo 回滾方式進(jìn)行進(jìn)行驗(yàn)證。

仔細(xì)閱讀過(guò)官方手冊(cè)的同學(xué)，一定留意到了對(duì)于提升大事務(wù)回滾效率，官方提供了兩種方法：一是增加 innodb_buffer_pool_size 參數(shù)大小，二是合理利用 innodb_force_recovery=3 參數(shù)，跳過(guò)事務(wù)回滾過(guò)程。第一種方式比較溫和，innodb_buffer_pool_size 參數(shù)是可以動(dòng)態(tài)調(diào)整的，可行性也較高。第二種方式相較之下較暴力，但效果較好。

兩種方式各有自己的優(yōu)點(diǎn)，第一種方式對(duì)線上業(yè)務(wù)系統(tǒng)影響較小，不會(huì)中斷在線業(yè)務(wù)。第二種方式效果更顯著，會(huì)短暫影響業(yè)務(wù)連續(xù)，回滾所有沒(méi)有提交的事務(wù)。

MySQL超大表如何提高c

MySQL超大表如何提高count速度

經(jīng)常用到count統(tǒng)計(jì)記錄數(shù)，表又超級(jí)大，這時(shí)候sql執(zhí)行很慢，就是走索引，也是很慢的，怎么辦呢？

1.這個(gè)時(shí)候我們就要想為什么這么慢：根本原因是訪問(wèn)的數(shù)據(jù)量太大，就算只計(jì)算記錄數(shù)也是很慢的。

2.如何解決？減少數(shù)據(jù)訪問(wèn)量。

3.怎么才能減少訪問(wèn)量呢？更小的索引。

4.怎么能使索引更小呢？創(chuàng)建前綴索引。

至此我們的方案出來(lái)了！下面看看具體的：

表結(jié)構(gòu)：

CREATE TABLE `sbtest3` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`k` int(11) NOT NULL DEFAULT '0',

`c` char(120) NOT NULL DEFAULT '',

`pad` char(60) NOT NULL DEFAULT '',

PRIMARY KEY (`id`),

KEY `k_3` (`k`)

) ENGINE=InnoDB AUTO_INCREMENT=5000001 DEFAULT CHARSET=latin1;

分享名稱：mysql表過(guò)大怎么解決 mysql單表數(shù)據(jù)過(guò)大
本文路徑：http://muchs.cn/article48/hgsdhp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機(jī)網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站、品牌網(wǎng)站制作、企業(yè)網(wǎng)站制作、網(wǎng)站導(dǎo)航、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)