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 numnum=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的数据是往内存里放，我内存没那么大导致的。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!