省略一切閒言碎語直接上方案。

第一步：建一個表，命名為 test，一個id欄位，再加一個content內容欄位吧；

第二步：往test裡塞1000萬條資料，當然你也可以塞10億條，哈哈哈哈哈；

第三步：建一個表：命名為 table_delete_id_aggregate，兩個欄位，三個欄位，id、did(刪除的id）,tableName(刪除資料的表名稱)；

第四步：某個表（假設A表）刪除資料時需要往table_delete_id_aggregate表中記錄被刪除id和資料表名；

第五步：某個表（假設A表）新增資料時，需要從table_delete_id_aggregate中隨意獲得一個已刪除的id，用來填補已經缺失的id，新增成功後從table_delete_id_aggregate中刪除這個id，目的是為了減少table_delete_id_aggregate的資料量以及讓A表的id變得更連續；

第六步：某個表（假設A表）查詢時，需要先查出這個查詢條件的最小id，得到這個id後，需要用到一個方法，用來向找到資料之間存在多少斷點，譬如已經刪除的id值為1、2、3、4、5、6、7、8、9、10、30、300、1000，最小id是1，分頁需要往後取10條資料，需要遍歷一下這個已刪除的陣列，找到滿足取10條的最大id值，然後交給查詢語句between minid and maxid查出所需的10條資料。然後limit就不需要了。

至此，10億+的mysql表，就再也沒有count(*)、limit查詢語句效能差效率低問題了。當然，這種方法只適合在分頁時使用，不過別的場景應該也沒有多大問題哈。

唉！又免費為社會廣大人民做貢獻了，希望資料庫公司不會因此而倒閉。