摘要：筆者現(xiàn)在遇到這么一個(gè)場景一個(gè)單表中包含有的數(shù)據(jù)然而你又不能拆分需要分別統(tǒng)計(jì)表中有多少數(shù)據(jù)產(chǎn)品有多少產(chǎn)品有多少這幾個(gè)數(shù)據(jù)在為優(yōu)化之前表結(jié)構(gòu)如下為了隱藏內(nèi)容我將相應(yīng)字段做了模糊化處理這個(gè)一個(gè)常規(guī)的的表格所以它的比起的效率慢很多所顯示的的行數(shù)不很

筆者現(xiàn)在遇到這么一個(gè)場景,

一個(gè)單表中包含有6000w+的數(shù)據(jù),然而你又不能拆分.需要分別統(tǒng)計(jì)表中有多少數(shù)據(jù),A產(chǎn)品有多少,B產(chǎn)品有多少這幾個(gè)數(shù)據(jù).

在為優(yōu)化之前.表結(jié)構(gòu)如下,為了隱藏內(nèi)容我將相應(yīng)字段做了模糊化處理.

CREATE TABLE `xxxx` (
  `link` varchar(200) DEFAULT NULL,
  `test0` varchar(500) DEFAULT NULL,
  `test1` varchar(50) DEFAULT NULL,
  `test2` int(11) DEFAULT NULL,
  `test3` varchar(20) DEFAULT NULL,
  `test4` varchar(50) DEFAULT NULL,
  `test5` varchar(50) NOT NULL,
  `inserttime` datetime DEFAULT NULL,
  `test6` bit(1) NOT NULL DEFAULT b"0",
  `A` bit(1) NOT NULL DEFAULT b"0",
  `B` bit(1) NOT NULL DEFAULT b"0" ,
  PRIMARY KEY (`test5`),
  KEY `test6` (`test6`) USING BTREE,
  KEY `A` (`A`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

這個(gè)一個(gè)常規(guī)的InnoDB的表格,所以它的count(*)比起MyISAM的效率慢很多,InnoDB所顯示的row的行數(shù)不很準(zhǔn)確,所以在這這里我需要統(tǒng)計(jì)一下.有這么幾個(gè)策略.
共計(jì)61500000數(shù)據(jù)

count(*) 耗時(shí) 1539.499s

count(1) 耗時(shí) 907.581s

count(A) 對索引進(jìn)行count.

count(test6) 對主鍵進(jìn)行count.

無一例外,由于這個(gè)表沒有優(yōu)化好上面無論哪一種都需要幾千秒的時(shí)間,這個(gè)是我們無法忍受的.

下面我們開始著手分析處理這個(gè)問題.

預(yù)期整個(gè)表的count(*)應(yīng)該在200s以內(nèi)為正常,100以內(nèi)為良好,50以內(nèi)為優(yōu)秀.

首先我將里面test6抽取了出來,多帶帶形成了一個(gè)表.對其進(jìn)行操作.
共計(jì)61500000數(shù)據(jù)

count(*) 耗時(shí)10.238s

count(1) 耗時(shí)8.710s

count(test6) 對主鍵進(jìn)行count.耗時(shí)12.957s

其中count(1)的效率最高,比最慢count(pk)速度提升了52.0%.

將你能確定的字段改為最優(yōu)值,例如:

varchar更為char.雖然varchar可以自動(dòng)分配存儲(chǔ)空間的大小但是.varchar需要使用1到2個(gè)額外的字節(jié)來記錄字符串的長度,增加它的update的操作時(shí)間,

datetime改為timestamp后者在1978-2038年之間

最后使用count(1)檢驗(yàn)的時(shí)候最快耗時(shí),168s.雖然有些慢但是可以接受.

總結(jié):

重新設(shè)計(jì)你表中的字段,盡量優(yōu)化它的長度.不要一味使用過多的varchar.

使用count(1)而不是count(*)來檢索.