Archive for April, 2009
MySQL内存使用-线程独享
Monday, April 20th, 2009
对于任何一个数据库管理系统来说，内存的分配使用绝对可以算的上是其核心之一了，所以很多希望更为深入了解某数据库管理系统的人，都会希望一窥究竟，我也不例外。
从内存的使用方式MySQL 数据库的内存使用主要分为以下两类
线程独享内存
全局共享内存
今天这篇文章暂时先分析 MySQL 中主要的 “线程独享内存” 的。
在 MySQL 中，线程独享内存主要用于各客户端连接线程存储各种操作的独享数据，如线程栈信息，分组排序操作，数据读写缓冲，结果集暂存等等，而且大多数可以通过相关参数来控制内存的使用量。
线程栈信息使用内存(thread_stack)：主要用来存放每一个线程自身的标识信息，如线程id，线程运行时基本信息等等，我们可以通过 thread_stack 参数来设置为每一个线程栈分配多大的内存。
排序使用内存(sort_buffer_size)：MySQL 用此内存区域进行排序操作（filesort），完成客户端的排序请求。当我们设置的排序区缓存大小无法满足排序实际所需内存的时候，MySQL 会将数据写入磁盘文件来完成排序。由于磁盘和内存的读写性能完全不在一个数量级，所以sort_buffer_size参数对排序操作的性能影响绝对不可 小视。排序操作的实现原理请参考：MySQL Order By 的实现分析。
Join操作使用内存(join_buffer_size)：应用程序经常会出现一些两表（或多表）Join的 操作需求，MySQL在完成某些 Join 需求的时候（all/index join），为了减少参与Join的“被驱动表”的读取次数以提高性能，需要使用到 Join Buffer 来协助完成 Join操作（具体 Join 实现算法请参考：MySQL 中的 Join 基本实现原理）。 当 Join Buffer 太小，MySQL 不会将该 Buffer 存入磁盘文件，而是先将Join Buffer中的结果集与需要 Join 的表进行 Join 操作，然后清空 Join Buffer 中的数据，继续将剩余的结果集写入此 Buffer 中，如此往复。这势必会造成被驱动表需要被多次读取，成倍增加 IO 访问，降低效率。
顺序读取数据缓冲区使用内存(read_buffer_size)：这部分内存主要用于当需要顺序读取数据的时 候，如无发使用索引的情况下的全表扫描，全索引扫描等。在这种时候，MySQL 按照数据的存储顺序依次读取数据块，每次读取的数据快首先会暂存在read_buffer_size中，当 buffer 空间被写满或者全部数据读取结束后，再将buffer中的数据返回给上层调用者，以提高效率。
随机读取数据缓冲区使用内存(read_rnd_buffer_size)：和顺序读取相对应，当 MySQL 进行非顺序读取（随机读取）数据块的时候，会利用这个缓冲区暂存读取的数据。如根据索引信息读取表数据，根据排序后的结果集与表进行Join等等。总的来 说，就是当数据块的读取需要满足一定的顺序的情况下，MySQL [...]
关于redolog解析的介绍
Thursday, April 2nd, 2009
1. 什么是redolog解析
redolog 解析是我们自主研发的，通过分析oracle 的redo log ，然后根据oracle的log 还原出sql 的一种技术。功能类似于oralce 的logminer，不过比它更强大。
2. redolog 解析项目背景
做这个项目源自于我们自己主站和镜像站的数据同步需求。至于为什么不使用oracle自带的工具 ，我就不多说了 ， 如果oracle做的好，也不会有sharePlex 和 DSG 公司的
软件了。我们为什么不使用商业软件？ 第一是价格太贵； 第二个是它不能满足我们众多的小需求。
3. redolog 解析各个版本功能
整个redolog 格式的解析我共花了4个月不到的时间 ，并且写了一个包含事务的demo 版C 程序。 接下来架构部门介入，我便把整个程序的后续开发交给了他们。进过几个月的努力，顺利的完成
了交接工作 ，并且写出了C++ 版本的解析程序 。 接下来的一个事情就是如何验证程序的正确性 ，正好数据仓库部门有一个需求 ，他们需要抽取一个表每天变化的数据，而我们的redolog 解析
正好可以做这个事情，分析归档并提取出某段时间变化某个表变化的数据。经过一个月的试运行，利用解析程序提取出每天的变化数据和他们原先方法抽取的变化数据完全吻合 [...]
