這裡先說明一下，網上很多人說阿里規定500w資料就要分庫分表。實際上，這個500w並不是定義死的，而是與mysql的配置以及機器的硬體有關。my為了提公升效能，會將表的索引裝載到記憶體中。但是當表的資料到達一定的量的時候，會導致記憶體無法儲存這些索引，無法儲存索引，就只能進行磁碟io，從而導致效能下降。
我這裡有張表，資料有1000w，目前只有乙個主鍵索引
create table `user` (
`id` int(10) not null auto_increment,
`uname` varchar(20) default null comment '賬號',
`pwd` varchar(20) default null comment '密碼',
`addr` varchar(80) default null comment '位址',
`tel` varchar(20) default null comment '**',
`regtime` char(30) default null comment '註冊時間',
`age` int(11) default null comment '年齡',
primary key (`id`)
) engine=innodb auto_increment=10000003 default charset=utf8;
查詢所有大概16s。可謂是相當慢了。通常我們乙個後台系統，比如這個是乙個電商平台，這個是使用者表。後台管理系統，一般會查詢這些使用者資訊，做一些操作，比如後台直接新增使用者啊，或者刪除使用者啊這些操作。
所以這裡就誕生了兩個需求，乙個是查詢count，乙個是分頁查詢
我們分別來測試一下count用的時間和分頁查詢所用的時間
select * from user limit 1, 10 //幾乎不用時
select * from user limit 1000000, 10
select * from user limit 5000000, 10
select * from user limit 9000000, 10
select count(1) from user
從上面查詢所用時間可以看出來，如果是分頁查詢的話，查詢的資料越往後用時是越長的，查詢count也需要1.程式設計客棧7s。這顯然是不符合我們的要求的。所以，這裡我們就需要優化。首先我們這裡進行索引優化試試
首先看一下這是只有主鍵索引的執行計畫：
alter table `user` add index `sindex` (`uname`,`pwd`,`addr`,`tel`,`regtime`,`age`)
看上面的執行計畫，雖然type是從all->index,走了sindex索引，但是實際上查詢速度並沒有發生改變。
其實，建立聯合索引，是為了有條件查詢的時候速度更快，而不是全表查詢
select * from user where uname='6.445329111484186' 無聯合索引)
select * from user where uname='6.445329111484186' 有聯合索引)
所以這就是有聯合索引和無索引的差距
這裡基本上可以證明，加了索引和不加索引，進行全表查詢的時候，效率就是會很慢
既然索引這個結果已經不好使了，那就只能找其他方案了。根據我之前mysql面試裡面講的，count我們可以單獨儲存到乙個表裡面
create table `attribute` (
`id` int(11) not null,
`formname` varchar(50) collate utf8_bin not null程式設計客棧 comment '表名',
`formcount` int(11) not null comment '表總資料',
primary key (`id`)
) engine=innodb default charset=utf8 collate=utf8_bin;
這裡說一下，這種表一般不會查所有，只會查詢一條，所以建表的時候，可以建成hash
select formcount from attribute where formname='user' //幾乎不用時
count就進行優化完了。如果上面有選擇條件的話，就可以建立索引，通過走索引篩選的形式來查詢，這樣就可以不用讀這個count了。
那麼，count是沒問題了，分頁查詢優化要如何優化呢？這裡可以使用子查詢來優化
select * from user where
id>=(select id from user limit 9000000,1) limit 10
其實子查詢這種寫法，判斷id，其實就是通過覆蓋索引來查詢。效率會大大增加。不過我這裡測試是1.7s，以前在公司優化這方面的時候，比這個查詢時間要低，大家也可以自己生成資料自己測試
但是如果說數程式設計客棧據量太大了，我還是建議走es或者進行一些預設選擇，count可以單獨列出來
至此，乙個千萬級的資料分頁查詢的優化就完成了。
MySQL千萬級資料表優化思路
本文參考知乎問答整理 喜歡這樣的論調 mysql只做簡單的事情，千萬級的表，無論怎樣優化，同樣的sql，都沒有在十萬級的表中執行效率快 因此，在設計千萬級的大表之前，要先問自己幾個問題 我們當然希望每個應用都可以這樣，但理想終歸是理想，現實中，輪到我們自己擼袖子上陣的時候，坑，大多已經是一眼忘不到底...
千萬級別mysql資料表優化
第一優化你的sql和索引 第二加快取，memcached,redis 第三以上都做了後，還是慢，就做主從複製或主主複製，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護 第四如果以上都做了還是慢，不要想著去做切分，mysql自帶分...
mysql千萬級資料大表該如何優化
1.資料的容量 1 3年內會大概多少條資料，每條資料大概多少位元組 2.資料項 是否有大字段，那些欄位的值是否經常被更新 3.資料查詢sql條件 哪些資料項的列名稱經常出現在where group by order by子句中等 4.資料更新類sql條件 有多少列經常出現update或delete ...