1把需要的記錄導出.
金水網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應式網(wǎng)站等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)建站從2013年成立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。
2 把這個表刪除
3, 建立一個跟原來一樣的表,
4 把導出的數(shù)據(jù)導入
提問：如何設(shè)計或優(yōu)化千萬級別的大表？此外無其他信息，個人覺得這個話題有點范，就只好簡單說下該如何做，對于一個存儲設(shè)計，必須考慮業(yè)務特點，收集的信息如下：
1.數(shù)據(jù)的容量：1-3年內(nèi)會大概多少條數(shù)據(jù)，每條數(shù)據(jù)大概多少字節(jié)；
2.數(shù)據(jù)項：是否有大字段，那些字段的值是否經(jīng)常被更新；
3.數(shù)據(jù)查詢SQL條件：哪些數(shù)據(jù)項的列名稱經(jīng)常出現(xiàn)在WHERE、GROUP BY、ORDER BY子句中等；
4.數(shù)據(jù)更新類SQL條件：有多少列經(jīng)常出現(xiàn)UPDATE或DELETE 的WHERE子句中；
5.SQL量的統(tǒng)計比，如：SELECT：UPDATE+DELETE：INSERT=多少？
6.預計大表及相關(guān)聯(lián)的SQL，每天總的執(zhí)行量在何數(shù)量級？
7.表中的數(shù)據(jù)：更新為主的業(yè)務 還是 查詢?yōu)橹鞯臉I(yè)務
8.打算采用什么數(shù)據(jù)庫物理服務器，以及數(shù)據(jù)庫服務器架構(gòu)？
9.并發(fā)如何？
10.存儲引擎選擇InnoDB還是MyISAM？
大致明白以上10個問題，至于如何設(shè)計此類的大表，應該什么都清楚了！
至于優(yōu)化若是指創(chuàng)建好的表，不能變動表結(jié)構(gòu)的話，那建議InnoDB引擎，多利用點內(nèi)存，減輕磁盤IO負載，因為IO往往是數(shù)據(jù)庫服務器的瓶頸。
另外對優(yōu)化索引結(jié)構(gòu)去解決性能問題的話，建議優(yōu)先考慮修改類SQL語句，使他們更快些，不得已只靠索引組織結(jié)構(gòu)的方式，當然此話前提是， 索引已經(jīng)創(chuàng)建的非常好，若是讀為主，可以考慮打開query_cache， 以及調(diào)整一些參數(shù)值：sort_buffer_size,read_buffer_size,read_rnd_buffer_size,join_buffer_siz。
更多信息參見：
MySQL數(shù)據(jù)庫服務器端核心參數(shù)詳解和推薦配置
不紙上談兵，說一下我的思路以及我的解決，拋磚引玉了
我最近正在解決這個問題
我現(xiàn)在的公司有三張表，是5億的數(shù)據(jù)，每天張表每天的增量是100w
每張表大概在10個columns左右
下面是我做的測試和對比
1.首先看engine,在大數(shù)據(jù)量情況下，在沒有做分區(qū)的情況下
mysiam比innodb在只讀的情況下，效率要高13％左右
2.在做了partition之后，你可以去讀一下mysql的官方文檔，其實對于partition，專門是對myisam做的優(yōu)化，對于innodb，所有的數(shù)據(jù)是存在ibdata里面的，所以即使你可以看到schema變了，其實沒有本質(zhì)的變化
在分區(qū)出于同一個physical disk下面的情況下，提升大概只有1％
在分區(qū)在不同的physical disk下，我分到了三個不同的disks下，提升大概在3％，其實所謂的吞吐量，由很多因素決定的，比如你的explain parition時候可以看到，record在那一個分區(qū)，如果每個分區(qū)都有，其實本質(zhì)上沒有解決讀的問題，這樣只會提升寫的效率。
另外一個問題在于，分區(qū)，你怎么分，如果一張表，有三個column都是經(jīng)常被用于做查詢條件的，其實是一件很悲慘的事情，因為你沒有辦法對所有的sql做針對性的分區(qū)，如果你只是如mysql官方文檔上說的，只對時間做一個分區(qū)，而且你也只用時間查詢的話，恭喜你
3.表主要用來讀還是寫，其實這個問題是不充分的，應該這樣問，你在寫入的時候，同時并發(fā)的查詢多么？我的問題還比較簡單，因為mongodb的 shredding支持不能，在crush之后，還是回到mysql，所以在通常情況下，9am－9pm，寫入的情況很多，這個時候我會做一個 view，view是基于最近被插入或者經(jīng)常被查詢的，通過做view來分離讀取，就是說寫是在table上的，讀在進行邏輯判斷前是在view上操作的
4做一些archive table，比如先對這些大表做很多已有的統(tǒng)計分析，然后通過已有的分析＋增量來解決
5如果你用mysiam，還有一個問題你要注意，如果你的.configure的時候，加了一個max index length參數(shù)的時候，當你的record數(shù)大于制定長度的時候，這個index會被disable
優(yōu)化方案：
主從同步+讀寫分離：
這個表在有設(shè)備條件的情況下，讀寫分離，這樣能減少很多壓力，而且數(shù)據(jù)穩(wěn)定性也能提高
縱向分表：
根據(jù)原則，每個表最多不要超過5個索引，縱向拆分字段，將部分字段拆到一個新表
通常我們按以下原則進行垂直拆分:（先區(qū)分這個表中的冷熱數(shù)據(jù)字段）
把不常用的字段單獨放在一張表;
把text，blob等大字段拆分出來放在附表中;
經(jīng)常組合查詢的列放在一張表中;
缺點是：很多邏輯需要重寫，帶來很大的工作量。
利用表分區(qū)：
這個是推薦的一個解決方案，不會帶來重寫邏輯等，可以根據(jù)時間來進行表分區(qū)，相當于在同一個磁盤上，表的數(shù)據(jù)存在不同的文件夾內(nèi)，能夠極大的提高查詢速度。
橫向分表：
1000W條數(shù)據(jù)不少的，會帶來一些運維壓力，備份的時候，單表備份所需時間會很長，所以可以根據(jù)服務器硬件條件進行水平分表，每個表有多少數(shù)據(jù)為準。
1、做分區(qū)表，（哪個字段分區(qū)很重要，分錯會影響性能）。
2、拆表，
可以將歷史數(shù)據(jù)放到 其他表中，例如 abc表中，2013年的數(shù)據(jù)，拆到 abc_2013表中，2014年的數(shù)據(jù)拆到abc_2014表中。
我們經(jīng)常會遇到操作一張大表，發(fā)現(xiàn)操作時間過長或影響在線業(yè)務了，想要回退大表操作的場景。在我們停止大表操作之后，等待回滾是一個很漫長的過程，盡管你可能對知道一些縮短時間的方法，處于對生產(chǎn)環(huán)境數(shù)據(jù)完整性的敬畏，也會選擇不做介入。最終選擇不作為的原因大多源于對操作影響的不確定性。實踐出真知，下面針對兩種主要提升事務回滾速度的方式進行驗證，一種是提升操作可用內(nèi)存空間，一種是通過停實例，禁用 redo 回滾方式進行進行驗證。
仔細閱讀過官方手冊的同學，一定留意到了對于提升大事務回滾效率，官方提供了兩種方法：一是增加 innodb_buffer_pool_size 參數(shù)大小，二是合理利用 innodb_force_recovery=3 參數(shù)，跳過事務回滾過程。第一種方式比較溫和，innodb_buffer_pool_size 參數(shù)是可以動態(tài)調(diào)整的，可行性也較高。第二種方式相較之下較暴力，但效果較好。
兩種方式各有自己的優(yōu)點，第一種方式對線上業(yè)務系統(tǒng)影響較小，不會中斷在線業(yè)務。第二種方式效果更顯著，會短暫影響業(yè)務連續(xù)，回滾所有沒有提交的事務。
MySQL超大表如何提高count速度
經(jīng)常用到count統(tǒng)計記錄數(shù)，表又超級大，這時候sql執(zhí)行很慢，就是走索引，也是很慢的，怎么辦呢？
1.這個時候我們就要想為什么這么慢：根本原因是訪問的數(shù)據(jù)量太大，就算只計算記錄數(shù)也是很慢的。
2.如何解決？減少數(shù)據(jù)訪問量。
3.怎么才能減少訪問量呢？更小的索引。
4.怎么能使索引更小呢？創(chuàng)建前綴索引。
至此我們的方案出來了！下面看看具體的：
表結(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;
重慶分公司
重慶分公司
