MySQL下海量数据的迁移步骤分享

公司数据中心计划将海量数据做一次迁移,同时增加某时间字段(原来是datatime类型,现在增加一个date类型),单表数据量达到6亿多条记录,数据是基于时间(月)做的partition由于比较忙,一直没有总结,所以很细节的地方都记不清楚了,此处只是简单总结下当时的情形,备忘

乱打乱撞

最初接到任务,没有明确的入手点,直接就是select * from db limit 10000,动态修改翻页数量,通过控制台看耗时情况,慢

代码如下:

SELECT IR_SID,IR_HKEY,IR_GROUPNAME,IR_SITENAME,IR_CHANNEL,IR_MID,IR_URLNAME,IR_STATUS_CONTENT,IR_CREATED_AT,date_format(IR_CREATED_AT,'%Y.%m.%d'),IR_LASTTIME,IR_VIA,IR_THUMBNAIL_PIC,IR_RTTCOUNT,IR_COMMTCOUNT,IR_UID,IR_SCREEN_NAME,IR_RETWEETED_UID,IR_RETWEETED_SCREEN_NAME,IR_RETWEETED_MID,IR_RETWEETED_URL,IR_STATUS_BODY FROM TB_SINA_STATUS WHERE IR_SID>40000 AND IR_SID<50001 INTO OUTFILE '/home/mysql/data/data_outfile.txt'; LOAD DATA INFILE '/home/mysql/data/data_outfile.txt' INTO TABLE NEW_TB_SINA_STATUS;

是否可以基于partition读数据呢

既然数据库是按partition做分区,是否可以按partition读数据呢,如果可以改用怎样的语法读呢?时间上只要按月读数据,mysql会自动的基于partition读,具体可以用命令:explain partition即可看到具有基于哪个partition
    读大数据会十分耗时,对于数据进行到什么状态,我们可能十分想了解,可以用命令:show status查看,我印象中主要是sending data,writting to net之类的。
    innodb引擎的性能较myIsam引擎到底如何?
    导库实验中导出并导入一个月的数据(8G的文本量,2500w条记录),在myisam引擎下需要不到4h(测试环境为pc机),但是在innodb引擎下,却需要32小时,改善索引之类的,也需要28h,性能有8倍之差。

在网上找到了高人关于innodb与myisam区别,说需要修改innodb_buffer_pool_size、innodb_flush_log_at_trx_commit

可保证没有太大差别,尝试了没有明显改善,在本机倒是可以,为什么呢???这个折腾了我好长时间

innodb_flush_log_at_trx_commit

是否为Innodb比MyISAM慢1000倍而头大?看来也许你忘了修改这个参数了。默认值是 1,这意味着每次提交的更新事务(或者每个事务之外的语句)都会刷新到磁盘中,而这相当耗费资源,尤其是没有电池备用缓存时。很多应用程序,尤其是从 MyISAM转变过来的那些,把它的值设置为 2 就可以了,也就是不把日志刷新到磁盘上,而只刷新到操作系统的缓存上。日志仍然会每秒刷新到磁盘中去,因此通常不会丢失每秒1-2次更新的消耗。如果设置 为 0 就快很多了,不过也相对不安全了 — MySQL服务器崩溃时就会丢失一些事务。设置为 2 只会丢失刷新到操作系统缓存的那部分事务。

innodb_buffer_pool_size

Innodb在默认的 innodb_buffer_pool_size 设置下跟蜗牛似的。由于Innodb把数据和索引都缓存起来,无需留给操作系统太多的内存,因此如果只需要用Innodb的话则可以设置它高达 70-80% 的可用内存。

最后千辛万苦的、跋山涉水的,找到了另外两个参数

innodb_log_file_size

在高写入负载尤其是大数据集的情况下很重要。这个值越大则性能相对越高,但是要注意到可能会增加恢复时间。我经常设置为 64-512MB,跟据服务器大小而异。

innodb_log_buffer_size
    默认的设置在中等强度写入负载以及较短事务的情况下,服务器性能还可以。如果存在更新操作峰值或者负载较大,就应该考虑加大它的值了。如果它的值设置太高了,可能会浪费内存 — 它每秒都会刷新一次,因此无需设置超过1秒所需的内存空间。通常 8-16MB 就足够了。越小的系统它的值越小。

最终搞定,myisam与innodb的导数据的性能基本一致,2500的数据约需要3.5h,单库读数据需要2h,这个只是一个示意值仅供参考(pc上的测试),正式服务的上的测试结果更加明显

性能调优语句参考

代码如下:

set profiling = 1;
show profiles\G
SHOW profile CPU,BLOCK IO io FOR query 1;
show status
Show Processlist
explain

并行读取是否会更快?

如果基于partition导数据,还是不能达到既定目标,我最终是通过编写shell脚步,多进程并行基于partition导数据,即启动多个mysql -uroot -p db < exp201201.sql 、mysql -uroot -p db < exp201202.sql,每个sql下按天做读写(事件环境下是按月做partition的)

代码如下:

SELECT IR_SID,IR_HKEY,IR_GROUPNAME,IR_SITENAME,IR_CHANNEL,IR_MID,IR_URLNAME,IR_STATUS_CONTENT,IR_CREATED_AT,date_format(IR_CREATED_AT,'%Y.%m.%d'),IR_LASTTIME,IR_VIA,IR_THUMBNAIL_PIC,IR_RTTCOUNT,IR_COMMTCOUNT,IR_UID,IR_SCREEN_NAME,IR_RETWEETED_UID,IR_RETWEETED_SCREEN_NAME,IR_RETWEETED_MID,IR_RETWEETED_URL,IR_STATUS_BODY
INTO OUTFILE '/home/mysql/data/sinawb20120724/111101.txt'
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' ESCAPED BY '\\'
LINES TERMINATED BY '\n'
FROM TB_SINA_STATUS 
WHERE ir_created_at >='2011-11-01 00:00:00' and ir_created_at <'2011-11-01 23:59:59'

LOAD DATA  LOCAL INFILE '/home/mysql/data/sinawb20120724/111101.txt'
IGNORE INTO TABLE `NEW_TB_SINA_STATUS`
CHARACTER SET UTF8 
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' ESCAPED BY '\\'
LINES TERMINATED BY '\n'

时间: 2013-10-24

C#如何在海量数据下的高效读取写入MySQL

前提 由于工作的原因,经常需要对海量数据进行处理,做的数据爬虫相关,动辄千万级别的数据,单表几十个G都是都是家常便饭.  主要开发语言是C#,数据库使用的是MySQL. 最常见的操作便是 select 读取数据,然后在C#中对数据进行处理, 完毕后再插入数据库中.  简而言之就 select -> process -> insert三个步骤. 对于数据量小的情况下(百万级别 or 几百兆)可能最多1个小时就处理完了.但是对于千万级数据可能几天,甚至更多. 那么问题来了,如何优化?? (数据库的

mysql处理海量数据时的一些优化查询速度方法

由于在参与的实际项目中发现当mysql表的数据量达到百万级时,普通SQL查询效率呈直线下降,而且如果where中的查询条件较多时,其查询速度简直无法容忍.曾经测试对一个包含400多万条记录(有索引)的表执行一条条件查询,其查询时间竟然高达40几秒,相信这么高的查询延时,任何用户都会抓狂.因此如何提高sql语句查询效率,显得十分重要.以下是网上流传比较广泛的30种SQL查询语句优化方法: 1.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描. 2.对查询

mysql 海量数据的存储和访问解决方案

第1章  引言 随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题.对于一个大型的互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载.对于系统的稳定性和扩展性造成了极大的问题.通过数据切分来提高网站性能,横向扩展数据层已经成为架构研发人员首选的方式.水平切分数据库,可以降低单台机器的负载,同时最大限度的降低了了宕机造成的损失.通过负载均衡策略,有效的降低了单台机器的访问负载,降低了宕机的可能性:通过集群方案,解决了数据库宕机带来的单点数据库不能访问的问题:通过读写分离

MySQL无法存储emoji表情解决方案分析

本文实例讲述了MySQL无法存储emoji表情解决方案.分享给大家供大家参考,具体如下: 今天学习爬虫爬伯乐在线的文章,由于在文章中有emoji表情,导致有emoji表情的文章都爬取不下来 经过一番搜索之后终于解决了问题. 相关文章可参考: ①. MySQL无法存储Emoji表情问题 ②. mysql存emoji表情报错处理 1. 在navicat中 如果在新建表之前就改变数据库的编码,建表的时候好像可以自己转变过来吧 查看字符集编码: show variables like '%char%';

MySQL 压缩的使用场景和解决方案

导语 描述 MySQL 压缩的使用场景和解决方案,包括压缩传输协议.压缩列解决方案和压缩表解决方案. 提到 MySQL 压缩相关的内容,我们能想到的可能是如下几种和压缩相关的场景: 1.客户端和服务器之间传输的数据量太大,需要进行压缩,节约带宽 2.MySQL 某个列的数据量大,只针对某个列的数据压缩 3.MySQL 某个或者某几个表数据太多,需要将表数据压缩存放,减少磁盘空间的占用 这几个问题在 MySQL 侧都有很好的解决方案 ,针对第 1 个问题,可以使用 MySQL 的压缩协议解决:针对

MySQL的常见存储引擎介绍与参数设置调优

MySQL常用存储引擎之MyISAM 特性: 1.并发性与锁级别 2.表损坏修复 check table tablename repair table tablename 3.MyISAM表支持的索引类型 ①.全文索引 ②.前缀索引 4.MyISAM表支持数据压缩 myisampack 限制: 版本 < MySQL5.0时默认表大小为4G 如存储达标则要修改MAX_Rows和AVG_ROW_LENGTH 版本 > MySQL5.0时默认支持为256TB 适用场景: 1.非事务形应用 2.只读类

MySQL启用SSD存储的实例详解

MySQL启用SSD存储的实例详解 有时OS读写慢会降低MySQL服务器的性能,尤其是OS与MySQL使用同一磁盘时.故最好是让MySQL使用单独的磁盘,能使用SSD更好.要做到这一点,需要把SSD新磁盘挂载到服务器上,假定新磁盘在/dev/sdb. 1.准备新磁盘: # fdisk /dev/sdb 按下"n"将创建一个新分区:按下"p"将创建新的主分区.接着设置分区号(从1-4),再选择分区的尺寸,按下回车键. 如果不想使用整个磁盘作为一个分区,那么还需要继续创

在android开发中进行数据存储与访问的多种方式介绍

数据存储与访问 很多时候我们的软件需要对处理后的数据进行存储或再次访问.Android为数据存储提供了多种方式,分别有如下几种: 文件 SharedPreferences SQLite数据库 内容提供者(Content provider) 网络 使用文件进行数据存储 首先给大家介绍使用文件如何对数据进行存储,Activity提供了openFileOutput()方法可以用于把数据输出到文件中,具体的实现过程与在J2SE环境中保存数据到文件中是一样的. 复制代码 代码如下: public clas

Mysql更换MyISAM存储引擎为Innodb的操作记录总结

一般情况下,mysql会默认提供多种存储引擎,可以通过下面的查看: 1)查看mysql是否安装了innodb插件. 通过下面的命令结果可知,已经安装了innodb插件. mysql> show plugins; +------------+--------+----------------+---------+---------+ | Name | Status | Type | Library | License | +------------+--------+---------------

Mysql 切换数据存储目录的实现方法

Mysql 切换数据存储目录的实现方法 今日,工作中遇到,mysql,存储所在分区空间都已使用完,导致mysql无法正常启动,为此只能迁移数据存储目录. 1.将现有的数据存储目录,转移到别的存储空间,今日转移时 50G的数据文件,拷贝了 30多分钟,有些慢. 2.修改my.cf配置文件 修改 存储目录 [mysqld] datadir=/home/mysql socket=/home/mysql/mysql.sock [mysql_safe] pid-file=/home/mysql/mysql

MySQL修改默认存储引擎的实现方法

mysql存储引擎: MySQL服务器采用了模块化风格,各部分之间保持相对独立,尤其体现在存储架构上.存储引擎负责管理数据存储,以及MySQL的索引管理.通过定义的API,MySQL服务器能够与存储引擎进行通信.目前使用最多的是MyISAM和InnoDB.InnoDB被Oracle收购后,MySQL自行开发的新存储引擎Falcon将在MySQL6.0版本引进. MyISAM引擎是一种非事务性的引擎,提供高速存储和检索,以及全文搜索能力,适合数据仓库等查询频繁的应用.MyISAM中,一个table

Mysql以utf8存储gbk输出的实现方法提供

一个站有可能经历gb2312(gbk,big5)到utf8的转换过程,其中会遇到很多的问题.站点太庞大了怎么办呢,只能一步步来了.要是能在极少改动前端代码的情况下,先完成数据的转换将会使整件事情容易得多.经过几天测试终于发现,Mysql以utf8存储gbk输出是可以实现的.mysql4.1后都有个特性,可以指定当前客户端连接所使用的字符集,mysql默认都是latin1,或由mysql server端配置的字符集进行连接校对.我使用utf8_general_ci来创建字段.  DB: SQL代码