在项目开发中,需要写个windows服务从sqlserver复制数据到mysql(5.6.13 Win64(x86_64)),然后对这些数据进行计算分析。
每15分钟复制一次,每次复制大概200条数据,每隔1小时对新同步的数据进行计算。

我们的mysql服务器是个破台式机,如下:(最初4G内存)

随着时间推移,数据量不断增加,目前数据表有7295400条数据。
眼看着同步数据耗时越来越长,从最初的10秒左右,到目前的7,8分钟,有时更甚达到十几分钟。
计算服务耗时从最初的几分钟到目前的40多分钟。
磁盘使用率一直在100%左右,mysql数据库的innodb buffer 使用率一直100%。

因此赶快买了个8G内存条(原来只有4G),然后修改mysql变量:
innodb_buffer_pool_size=2G(原innodb_buffer_pool_size=99MB);
innodb_flush_log_at_trx_commit=0(原innodb_flush_log_at_trx_commit=1)

效果十分明显:同步数据又回到了以前的10秒左右,计算服务现在耗时不到10分钟;

innodb buffer usage大概在50%左右,磁盘使用率也只是在数据插入时比较高,其它时间也就0%。

现在来看看innodb_buffer_pool_size,innodb_flush_log_at_trx_commit的注释说明:

innodb_buffer_pool_size

InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and
row data. The bigger you set this the less disk I/O is needed to
access data in tables. On a dedicated database server you may set this
parameter up to 80% of the machine physical memory size. Do not set it
too large, though, because competition of the physical memory may
cause paging in the operating system. Note that on 32bit systems you
might be limited to 2-3.5G of user level memory per process, so do not
set it too high.

Innodb,使用一个缓冲池来缓存索引和数据行,你设置的越大,磁盘I/O访问越小,设置值大概在数据库服务器物理内存的80%左右,

当然也不能过高,我的设置在2G显然够用了,在32为系统中,我们一般只能用3G内存,所有不要设置太高。

innodb_flush_log_at_trx_commit

If set to 1, InnoDB will flush (fsync) the transaction logs to the
disk at each commit, which offers full ACID behavior. If you are
willing to compromise this safety, and you are running small
transactions, you may set this to 0 or 2 to reduce disk I/O to the
logs. Value 0 means that the log is only written to the log file and
the log file flushed to disk approximately once per second. Value 2
means the log is written to the log file at each commit, but the log
file is only flushed to disk approximately once per second.

默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入(flush)硬盘,这是很费时的。特别是使用电 池供电缓存(Battery backed up cache)时。设成2对于很多运用,特别是从MyISAM表转过来的是可以的,它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘,所以你一般不会丢失超过1-2秒的更新。设成0会更快一点,但安全方面比较差,即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。

附加:2014-10-17

# The number of regions that the InnoDB buffer pool is divided into.
# For systems with buffer pools in the multi-gigabyte range, dividing the buffer pool into separate instances can improve concurrency,
# by reducing contention as different threads read and write to cached pages.
innodb_buffer_pool_instances=8

当innodb_buffer_pool_instances=1时,innodb_buffer_pool_size>1G是无效的,mysql无法启动,因此当设置innodb_buffer_pool_size>1G时,

应该设置innodb_buffer_pool_instances>1

以上仅仅是工作中的一点点经验,也不是很具有说明性,但对于mysql查询优化还是有一点点帮助。

Mysql优化小记1的更多相关文章

  1. MySQL优化聊两句

    原文地址:http://www.cnblogs.com/verrion/p/mysql_optimised.html MySQL优化聊两句 MySQL不多介绍,今天聊两句该如何优化以及从哪些方面入手, ...

  2. 0104探究MySQL优化器对索引和JOIN顺序的选择

    转自http://www.jb51.net/article/67007.htm,感谢博主 本文通过一个案例来看看MySQL优化器如何选择索引和JOIN顺序.表结构和数据准备参考本文最后部分" ...

  3. mysql 优化

    1.存储过程造数据 CREATE DEFINER=`root`@`localhost` PROCEDURE `generate_test_data`(`n` int) begin declare i ...

  4. mysql优化笔记之分页

    过年闲得蛋疼,于是看看mysql优化,看了网上好多关于分页的优化方法,但是呢,我亲自试上一把的时候,没有出现他们说的现象...难道是我的机器问题么? 下面看看我的实践记录,希望看到的加入进来交流一下O ...

  5. MySQL优化概述

    一. MySQL优化要点 MySQL优化是一门复杂的综合性技术,主要包括: 1 表的设计合理化(符合 3NF,必要时允许数据冗余) 2.1 SQL语句优化(以查询为主) 2.2 适当添加索引(主键索引 ...

  6. MySQL优化实例

    这周就要从泰笛离职了,在公司内部的wiki上,根据公司实际的项目,写了一些mysql的优化方法,供小组里的小伙伴参考下,没想到大家的热情很高,还专门搞了个ppt讲解了一下. 举了三个大家很容易犯错的地 ...

  7. Mysql优化系列(2)--通用化操作梳理

    前面有两篇文章详细介绍了mysql优化举措:Mysql优化系列(0)--总结性梳理Mysql优化系列(1)--Innodb引擎下mysql自身配置优化 下面分类罗列下Mysql性能优化的一些技巧,熟练 ...

  8. mysql优化记录

    老板反应项目的反应越来越慢,叫优化一下,顺便学习总结一下mysql优化. 不同引擎的优化,myisam读的效果好,写的效率差,使用场景 非事务型应用只读类应用空间类应用 Innodb的特性,innod ...

  9. mysql 优化实例之索引创建

    mysql 优化实例之索引创建 优化前: pt-query-degist分析结果: # Query 23: 0.00 QPS, 0.00x concurrency, ID 0x78761E301CC7 ...

随机推荐

  1. 美美哒rand()函数

     2016.3.7     天气:大雪都已经三月份竟然还下了这么大的雪,真是少见呀.今天为了提交软件工程的作业我们需要注册git的账号,真是前途艰难呀,后台服务器都要爆炸了,其实我觉得这个平台的服务器 ...

  2. HBase 参考文档翻译之 Getting Started

    本篇是对HBase官方参考文档的大体翻译,介于本人英文水平实在有限,难免有纰漏之处.本篇不只是对官方文档的翻译,还加入了一些本人对HBase的理解.在翻译过程中,一些没有营养的废话,我就忽略了没有翻译 ...

  3. 对Android体系结构的理解--后续会补充

    1.最底层_硬件 任何Android设备最底层的硬件包括 显示屏, wifi ,存储设备 等. Android最底层的硬件会根据需要进行裁剪,选择自己需要的硬件. 2.Linux内核层 该层主要对硬件 ...

  4. Calculator Part Ⅰ

    GitHub/object-oriented The title of the work 关于这次的作业,一开始我是觉得不难的,毕竟学长在已经提供了足够多的提示,实现步骤.需要那些方面的知识等等.但是 ...

  5. iOS- iOS 7 的后台多任务 (Multitasking) 对比之前的异同、具体机制、变化

    简单来说,这玩意是对开发者友好,但对设备不友好的(可能会偷偷摸摸地占用流量和电量).对用户来说,如果你带宽够,对发热不敏感的话,会得到更好的应用体验. 从 iOS 4 开始,应用就可以在退到后台后,继 ...

  6. iOS- 用UICollectionViewController 来进行横竖屏九宫格布局

    1.简单说说UICollectionViewController 我们在做九宫格布局时,可以使用UIScrollView,也可以使用UICollectionViewController. 当我们用UI ...

  7. 【Redis】- 主从复制

    Redis跟MySQL一样,拥有非常强大的主从复制功能,而且还支持一个master可以拥有多个slave,而一个slave又可以拥有多个slave,从而形成强大的多级服务器集群架构. redis的主从 ...

  8. C# #pragma warning disable/restore

    #pragma warning 可以启用或禁用特定警告. 语法 #pragma warning disable warning-list #pragma warning restore warning ...

  9. ExtremeComponents源码解析(一)

    一.前言 因参与公司框架改造,在负责前端table组件选型时,原本选了jqGrid和Bootstraptable作为备选方案,评审会上,武哥提了EXtremeComponents,让我也去了解下,看下 ...

  10. BZOJ 1415 聪聪和可可(期望DP)

    我们可以用n次BFS预处理出 to[][]数组,to[i][j]表示聪聪从i点到j点第一步会走哪个点. 那么对于聪聪在i点,可可在j点,聪聪先走,定义dp[i][j]表示步数期望. 那么显然有dp[i ...