摘要:筆者現在遇到這么一個場景一個單表中包含有的數據然而你又不能拆分需要分別統計表中有多少數據產品有多少產品有多少這幾個數據在為優化之前表結構如下為了隱藏內容我將相應字段做了模糊化處理這個一個常規的的表格所以它的比起的效率慢很多所顯示的的行數不很
筆者現在遇到這么一個場景,
一個單表中包含有6000w+的數據,然而你又不能拆分.需要分別統計表中有多少數據,A產品有多少,B產品有多少這幾個數據.
在為優化之前.表結構如下,為了隱藏內容我將相應字段做了模糊化處理.
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;
這個一個常規的InnoDB的表格,所以它的count(*)比起MyISAM的效率慢很多,InnoDB所顯示的row的行數不很準確,所以在這這里我需要統計一下.有這么幾個策略.
共計61500000數據
count(*) 耗時 1539.499s
count(1) 耗時 907.581s
count(A) 對索引進行count.
count(test6) 對主鍵進行count.
無一例外,由于這個表沒有優化好上面無論哪一種都需要幾千秒的時間,這個是我們無法忍受的.
下面我們開始著手分析處理這個問題.
預期整個表的count(*)應該在200s以內為正常,100以內為良好,50以內為優秀.
首先我將里面test6抽取了出來,多帶帶形成了一個表.對其進行操作.
共計61500000數據
count(*) 耗時10.238s
count(1) 耗時8.710s
count(test6) 對主鍵進行count.耗時12.957s
其中count(1)的效率最高,比最慢count(pk)速度提升了52.0%.
將你能確定的字段改為最優值,例如:
varchar更為char.雖然varchar可以自動分配存儲空間的大小但是.varchar需要使用1到2個額外的字節來記錄字符串的長度,增加它的update的操作時間,
datetime改為timestamp后者在1978-2038年之間
最后使用count(1)檢驗的時候最快耗時,168s.雖然有些慢但是可以接受.
總結:
重新設計你表中的字段,盡量優化它的長度.不要一味使用過多的varchar.
使用count(1)而不是count(*)來檢索.
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/42205.html
摘要:也就是說當使用字符型存儲數據后,該數據轉換為二進制時的長度超過了位,那么該數據將不會完整存儲,會丟失一部分數據。 showImg(https://segmentfault.com/img/bVbuYxg?w=3484&h=2480); 閱讀本文大約需要 8 分鐘。 寫在前面 數據庫打算只寫 MySQL,Redis 兩部分,不會很細,主要以面試題為主。這次寫的是 MySQL 篇。 1.說...
閱讀 1915·2023-04-26 01:56
閱讀 3112·2021-11-18 10:02
閱讀 3049·2021-09-09 11:35
閱讀 1284·2021-09-03 10:28
閱讀 3408·2019-08-29 18:36
閱讀 2846·2019-08-29 17:14
閱讀 833·2019-08-29 16:10
閱讀 1616·2019-08-26 13:45