mysql表過大怎么解決 mysql單表數據過大

mysql的一個表太大了，400多g,在數據庫里面刪了兩天半都刪不掉，請問可

1把需要的記錄導出.

金水網站制作公司哪家好，找創新互聯建站！從網頁設計、網站建設、微信開發、APP開發、響應式網站等網站項目制作，到程序開發，運營維護。創新互聯建站從2013年成立到現在10年的時間，我們擁有了豐富的建站經驗和運維經驗，來保證我們的工作的順利進行。專注于網站建設就選創新互聯建站。

2 把這個表刪除

3, 建立一個跟原來一樣的表,

4 把導出的數據導入

MySQL 對于千萬級的大表要怎么優化

提問：如何設計或優化千萬級別的大表？此外無其他信息，個人覺得這個話題有點范，就只好簡單說下該如何做，對于一個存儲設計，必須考慮業務特點，收集的信息如下：

1.數據的容量：1-3年內會大概多少條數據，每條數據大概多少字節；

2.數據項：是否有大字段，那些字段的值是否經常被更新；

3.數據查詢SQL條件：哪些數據項的列名稱經常出現在WHERE、GROUP BY、ORDER BY子句中等；

4.數據更新類SQL條件：有多少列經常出現UPDATE或DELETE 的WHERE子句中；

5.SQL量的統計比，如：SELECT：UPDATE+DELETE：INSERT=多少？

6.預計大表及相關聯的SQL，每天總的執行量在何數量級？

7.表中的數據：更新為主的業務 還是 查詢為主的業務

8.打算采用什么數據庫物理服務器，以及數據庫服務器架構？

9.并發如何？

10.存儲引擎選擇InnoDB還是MyISAM？

大致明白以上10個問題，至于如何設計此類的大表，應該什么都清楚了！

至于優化若是指創建好的表，不能變動表結構的話，那建議InnoDB引擎，多利用點內存，減輕磁盤IO負載，因為IO往往是數據庫服務器的瓶頸。

另外對優化索引結構去解決性能問題的話，建議優先考慮修改類SQL語句，使他們更快些，不得已只靠索引組織結構的方式，當然此話前提是， 索引已經創建的非常好，若是讀為主，可以考慮打開query_cache， 以及調整一些參數值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_siz。

更多信息參見：

MySQL數據庫服務器端核心參數詳解和推薦配置

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

我最近正在解決這個問題

我現在的公司有三張表，是5億的數據，每天張表每天的增量是100w

每張表大概在10個columns左右

下面是我做的測試和對比

1.首先看engine,在大數據量情況下，在沒有做分區的情況下

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

2.在做了partition之后，你可以去讀一下mysql的官方文檔，其實對于partition，專門是對myisam做的優化，對于innodb，所有的數據是存在ibdata里面的，所以即使你可以看到schema變了，其實沒有本質的變化

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

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

另外一個問題在于，分區，你怎么分，如果一張表，有三個column都是經常被用于做查詢條件的，其實是一件很悲慘的事情，因為你沒有辦法對所有的sql做針對性的分區，如果你只是如mysql官方文檔上說的，只對時間做一個分區，而且你也只用時間查詢的話，恭喜你

3.表主要用來讀還是寫，其實這個問題是不充分的，應該這樣問，你在寫入的時候，同時并發的查詢多么？我的問題還比較簡單，因為mongodb的 shredding支持不能，在crush之后，還是回到mysql，所以在通常情況下，9am－9pm，寫入的情況很多，這個時候我會做一個 view，view是基于最近被插入或者經常被查詢的，通過做view來分離讀取，就是說寫是在table上的，讀在進行邏輯判斷前是在view上操作的

4做一些archive table，比如先對這些大表做很多已有的統計分析，然后通過已有的分析＋增量來解決

5如果你用mysiam，還有一個問題你要注意，如果你的.configure的時候，加了一個max index length參數的時候，當你的record數大于制定長度的時候，這個index會被disable

mysql數據庫表太大查詢慢優化的幾種方法

優化方案：

主從同步+讀寫分離：

這個表在有設備條件的情況下，讀寫分離，這樣能減少很多壓力，而且數據穩定性也能提高

縱向分表：

根據原則，每個表最多不要超過5個索引，縱向拆分字段，將部分字段拆到一個新表

通常我們按以下原則進行垂直拆分:（先區分這個表中的冷熱數據字段）

把不常用的字段單獨放在一張表;

把text，blob等大字段拆分出來放在附表中;

經常組合查詢的列放在一張表中;

缺點是：很多邏輯需要重寫，帶來很大的工作量。

利用表分區：

這個是推薦的一個解決方案，不會帶來重寫邏輯等，可以根據時間來進行表分區，相當于在同一個磁盤上，表的數據存在不同的文件夾內，能夠極大的提高查詢速度。

橫向分表：

1000W條數據不少的，會帶來一些運維壓力，備份的時候，單表備份所需時間會很長，所以可以根據服務器硬件條件進行水平分表，每個表有多少數據為準。

MySQL 對于大表，要怎么優化

1、做分區表，（哪個字段分區很重要，分錯會影響性能）。

2、拆表，

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

mysql 數據量超過百萬后怎么處理

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

仔細閱讀過官方手冊的同學，一定留意到了對于提升大事務回滾效率，官方提供了兩種方法：一是增加 innodb_buffer_pool_size 參數大小，二是合理利用 innodb_force_recovery=3 參數，跳過事務回滾過程。第一種方式比較溫和，innodb_buffer_pool_size 參數是可以動態調整的，可行性也較高。第二種方式相較之下較暴力，但效果較好。

兩種方式各有自己的優點，第一種方式對線上業務系統影響較小，不會中斷在線業務。第二種方式效果更顯著，會短暫影響業務連續，回滾所有沒有提交的事務。

MySQL超大表如何提高c

MySQL超大表如何提高count速度

經常用到count統計記錄數，表又超級大，這時候sql執行很慢，就是走索引，也是很慢的，怎么辦呢？

1.這個時候我們就要想為什么這么慢：根本原因是訪問的數據量太大，就算只計算記錄數也是很慢的。

2.如何解決？減少數據訪問量。

3.怎么才能減少訪問量呢？更小的索引。

4.怎么能使索引更小呢？創建前綴索引。

至此我們的方案出來了！下面看看具體的：

表結構：

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表過大怎么解決 mysql單表數據過大
本文路徑：http://m.kartarina.com/article48/hgsdhp.html

成都網站建設公司_創新互聯，為您提供手機網站建設、響應式網站、品牌網站制作、企業網站制作、網站導航、定制網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯