這段時間，系統一步步走來，使用者資料由原來的上百萬到現在的幾千萬，除了前台介面做了很多改變，管理介面的修改也不少，資料量上來後，乙個小的需求可能就涉及到大量的改造。這裡介紹下管理介面時候的查詢改變。
a表現在業務分，一張2000w，一張幾百萬,
還有一張1000w的使用者表,更新操作較多，
資料庫伺服器，32g記憶體，16核，centos,mysql5.7
在單錶還是幾百萬的時候，分布資料查詢就很慢了，10條資料的請求查了10來秒，而且還是有索引的情況下，
關鍵是那個count,之前的分頁外掛程式都是把count一起帶過來的,而count會消耗掉10s中的9s，為了使用者體驗，我們做了兩點操作：
快取的key可以採用 支付介面常常使用的 資料摘要方式進行加密.即把但過了一定階段，對查詢條件加了索引，但limit 還是有點慢,後來發現是 order 慢，業務上有時間，這個時間我們是存string的，採用這個來order發現效果不太理想，於是採用timestamp新建了乙個字段，採用mysql自動更新的機制，發現效果比較好，速度也提了不少, 實際效果是，2000w那張表查詢前面的頁數也是毫秒查，無壓力 。第一步，設所有傳送或者接收到的資料為集合m，將集合m內非空引數值的引數按照引數名ascii碼從小到大排序（字典序），使用url鍵值對的格式（即key1=value1&key2=value2…）拼接成字串stringa.
第二步，對stringa進行md5運算，再將得到的字串所有字元轉換為大寫，得到sign值signvalue。
期間發生過幾次情況,這裡進行描述.
乙個是加索引的情況
大表加索引是個比較頭疼的問題,如果你的表只是insert還好，直接加即可，不會鎖住，如果表有update,則要想想辦法了，思路是用tmp 表和 原表 rename,然後給原表加索引，加完後再rename回來,完成資料的切換。具體可參考另一篇
orderby時緩慢(時間花在creating sort index )
如果遇到limit 前幾頁的時候也會緩慢，而相應的索引也加了，有可能是order by 的字段沒有在where裡面引起的，可嘗試把column加到where語句中.具體可參考
其它關於大表的橫向切分內總部討論過多次，優先肯定業務切分，已經切過幾次了，效果挺好，改動也小。但對於一些難以用業務分的，則要考慮hash切或時間切，時間切的難度相對小，hash的話改動較大，需要謹慎。如果資料庫服務有壓力,可考慮先業務分庫.
千萬級別mysql資料表優化
第一優化你的sql和索引 第二加快取，memcached,redis 第三以上都做了後，還是慢，就做主從複製或主主複製，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要麼效率不高，要麼沒人維護 第四如果以上都做了還是慢，不要想著去做切分，mysql自帶分...
MySQL管理資料表
一 刪除重複性記錄，只保留id最小的一條 方法一 delete from yourtable where id not in select max id from yourtable group by name value 注意 1 mysql資料庫不允許子查詢in中的from與原查詢中的from表...
MySQL千萬級資料表優化思路
本文參考知乎問答整理 喜歡這樣的論調 mysql只做簡單的事情，千萬級的表，無論怎樣優化，同樣的sql，都沒有在十萬級的表中執行效率快 因此，在設計千萬級的大表之前，要先問自己幾個問題 我們當然希望每個應用都可以這樣，但理想終歸是理想，現實中，輪到我們自己擼袖子上陣的時候，坑，大多已經是一眼忘不到底...