MySQL 亿级数据需求的优化思路(一),交易流水记录的查询 |
您所在的位置:网站首页 › 上亿条数据查询用什么数据库 › MySQL 亿级数据需求的优化思路(一),交易流水记录的查询 |
对MySQL的性能和亿级数据的处理方法思考,以及分库分表到底该如何做,在什么场景比较合适? 比如银行交易流水记录的查询 限盐少许,上实际实验过程,以下是在实验的过程中做一些操作,以及踩过的一些坑,我觉得坑对于读者来讲是非常有用的。 首先:建立一个现金流量表,交易历史是各个金融体系下使用率最高,历史存留数据量最大的数据类型。现金流量表的数据搜索,可以根据时间范围,和个人,以及金额进行搜索。 -- 建立一张 现金流量表 DROP TABLE IF EXISTS `yun_cashflow`; CREATE TABLE `yun_cashflow` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `userid` int(11) DEFAULT NULL, `type` int(11) DEFAULT NULL COMMENT '1、入账,2提现', `operatoruserid` int(11) DEFAULT NULL COMMENT '操作员ID', `withdrawdepositid` bigint(20) DEFAULT NULL COMMENT '提现ID', `money` double DEFAULT NULL COMMENT '钱数', `runid` bigint(20) DEFAULT NULL COMMENT '工单ID', `createtime` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=63 DEFAULT CHARSET=utf8;然后开始造1个亿的数据进去。 -- 循环插入 drop PROCEDURE test_insert; DELIMITER;; CREATE PROCEDURE test_insert() begin declare num int; set num=0; while num < 10000 do insert into yun_cashflow(userid,type,operatoruserid,withdrawdepositid,money) values(FLOOR(7 + (RAND() * 6))+FLOOR(22 + (RAND() * 9)),1,FLOOR(97 + (RAND() * 6))+FLOOR(2 + (RAND() * 9)),FLOOR(17 + (RAND() * 6))+FLOOR(2 + (RAND() * 9)),FLOOR(5 + (RAND() * 6))+FLOOR(2 + (RAND() * 9))); set num=num+1; end while; END;; call test_insert(); 坑一: 这个存储过程建立好了之后,发现插入数据特别的慢,一天一晚上也插入不到100万条数据,平均每秒40~60条数据,中间我停过几次,以为是随机函数的问题,都变成常数,但效果一样,还是很慢,当时让我对这个MySQL数据库感觉到悲观,毕竟Oracle用惯了,那插速是真的很快,不过功夫不负有心人,原来可以用另外一种写法造数据,速度很快,上代码。 INSERT INTO example (example_id, name, value, other_value) VALUES (100, 'Name 1', 'Value 1', 'Other 1'), (101, 'Name 2', 'Value 2', 'Other 2'), (102, 'Name 3', 'Value 3', 'Other 3'), (103, 'Name 4', 'Value 4', 'Other 4');就是在循环里,用这种格式造很多数据,VALUES后面以,隔开,然后把数据写上去,我用Excel造了1万条数据,按照语句格式粘贴了出来,就变成每循环一次,就1万条数据,这样没多久1亿数据就造好了。 select count(*) from yun_cashflow 我还比较好奇,8个字段1亿条数据,到底占了多大的地方,通过以下语句找到数据的路径。 show global variables like "%datadir%"; 通过查看文件,是7.78GB,看来如果字段不是很多,数据量大的话,其实不是什么问题,这其实作为架构师来讲,在估算机器配置硬盘冗余的时候,这是最简单直接粗暴的换算思路。 行了,表建完了,各种实验开始 首先,啥条件不加看看咋样。 呵呵了,Out of memory,看来这个查询是真往内存里整,内存整冒烟了,看来7.8G的数据是往内存里放,我内存没那么大导致的。 资金流水一般会按照时间进行查询,看看这速度到底怎样。 select * from yun_cashflow where createtime between '2018-10-23 09:06:58' and '2018-10-23 09:06:59' 我去,脑补一下,当你拿这支付宝查历史资金明细的时候,56条信息,103.489秒,也就是将近2分钟的查询速度,你会是怎样的体验。哦 哦,不对,这个还没加用条件,那下面单独试试某个用户不限时间范围的条件是怎样的。 select count(*) from yun_cashflow where userid=21 也是将近1分半的速度,那在试试金额的条件。 select count(*) from yun_cashflow where money |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |