摘要:笔者现在遇到这么一个场景一个单表中包含有的数据然而你又不能拆分需要分别统计表中有多少数据产品有多少产品有多少这几个数据在为优化之前表结构如下为了隐藏内容我将相应字段做了模糊化处理这个一个常规的的表格所以它的比起的效率慢很多所显示的的行数不很
笔者现在遇到这么一个场景,
一个单表中包含有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(*)来检索.
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/42205.html
摘要:也就是说当使用字符型存储数据后,该数据转换为二进制时的长度超过了位,那么该数据将不会完整存储,会丢失一部分数据。 showImg(https://segmentfault.com/img/bVbuYxg?w=3484&h=2480); 阅读本文大约需要 8 分钟。 写在前面 数据库打算只写 MySQL,Redis 两部分,不会很细,主要以面试题为主。这次写的是 MySQL 篇。 1.说...
阅读 1919·2023-04-26 01:56
阅读 3113·2021-11-18 10:02
阅读 3053·2021-09-09 11:35
阅读 1287·2021-09-03 10:28
阅读 3413·2019-08-29 18:36
阅读 2848·2019-08-29 17:14
阅读 834·2019-08-29 16:10
阅读 1617·2019-08-26 13:45