Archive for December, 2008
本 Team 招聘告示
Friday, December 26th, 2008
Team 招聘告示，详细信息如下：
MySQL DBA
职位描述：
管理MySQL数据库
开发项目支持与优化
MySQL数据库性能优化
MySQL数据库高级特性测试，优化与实践
岗位要求：
精通SQL
熟悉SQL Tuning
熟悉MySQL数据库架构与管理
熟悉MySQL Replication与NDB cluster的原理
熟悉LINUX操作系统
熟悉shell,perl(掌握一门)
良好的沟通技能、团队合作能力
熟悉unix环境下C语言编程者优先
Oracle 开发 DBA
职位描述：
评估，跟踪，支持开发项目
数据库变更管理
Schema设计与审核
数据库开发性能优化
开发、测试环境管理与维护
岗位要求：
精通SQL,PL/SQL
精通SQL Tuning
精通数据库建模
熟悉Oracle基本管理
有开发经验者优先
良好的沟通技能、团队合作能力
有意者请将简历 Mail 至本人邮箱： sky000 [AT] gmail.com
写了个监控网络流量的脚本
Thursday, December 18th, 2008
在我们的日常工作当中，监控网络要么使用iptarf,ifstat这些命令实现的，但是需要装额外的RPM包。特别是iptarf装起来麻烦。
我看了下，linux下的/proc/net/dev记录了每块网卡发送和接受的包和字节数。因此萌生想法，写了一个。运行效果：
root@:/root/wt>sh aa.sh
Current Ip: inet addr:10.0.65.52 Bcast:10.0.65.255 Mask:255.255.255.0
Summry info: RX bytes:2424183819 (2311.8 Mb) TX bytes:3519850565 (3356.7 Mb)
eth0 Receive Bytes: 61147 Packets: 433
eth0 Send Bytes: 86458 Packets: 372
eth0 Receive Bytes: 156051 Packets: 924
eth0 Send Bytes: 230962 Packets: 877
eth0 Receive Bytes: 192537 Packets: 1118
eth0 Send Bytes: 283893 Packets: 1073
具体脚本的内容如下，几乎不需要修改，就可以拿到任何机器上去使用了。
root@:/root/wt>cat aa.sh
#! /bin/bash
#Author: Vogts WangTao 2008-12-18
#Get summry info
echo “Current Ip: [...]
调用JS产生乱码
Monday, December 15th, 2008
今天在做一个测试，发现网页是正常的，就是调用JS的那个页面全部是乱码。
一开始不知道其中的原因，因为我在HTML里都显式的指定了编码格式：
<code><meta http-equiv=Content-Type content=text/html; charset=gb2312></code>
哪怕是用utf8也不行。
后来google了一下，发现当我们保存JS脚本的时候，要把文件保存的格式指定成“utf8”。这样就不会报错了。网页显示就很正常了。
arraysize对TFS和IFFS的影响
Saturday, December 13th, 2008
今天发现一个问题，对一个索引执行index fast full scan 的时候，如果在这之前进行了排序，逻辑读会少很多：
例子：
select id from A ;
xecution Plan
———————————————————-
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=62 Card=275240 Bytes=1100960)
1 0 INDEX (FAST FULL SCAN) OF ‘PK_T’ (NON-UNIQUE) (Cost=62 Card=275240 Bytes=1100960)
Statistics
———————————————————-
0 recursive calls
0 db block gets
3326 consistent gets
0 physical reads
0 redo size
1955968 bytes sent via SQL*Net to client
30397 bytes received [...]
MySQL DISTINCT 的基本实现原理
Friday, December 12th, 2008
接上一篇： MySQL 中 GROUP BY 基本实现原理
DISTINCT 实际上和 GROUP BY 操作的实现非常相似，只不过是在 GROUP BY 之后的每组中只取出一条记录而已。所以，DISTINCT 的实现和 GROUP BY 的实现也基本差不多，没有太大的区别。同样可以通过松散索引扫描或者是紧凑索引扫描来实现，当然，在无法仅仅使用索引即能完成 DISTINCT 的时候，MySQL 只能通过临时表来完成。但是，和 GROUP BY 有一点差别的是，DISTINCT 并不需要进行排序。也就是说，在仅仅只是 DISTINCT 操作的 Query 如果无法仅仅利用索引完成操作的时候，MySQL 会利用临时表来做一次数据的“缓存”，但是不会对临时表中的数据进行 filesort 操作。当然，如果我们在进行 DISTINCT 的时候还使用了 GROUP BY 并进行了分组，并使用了类似于 MAX 之类的聚合函数操作，就无法避免 filesort 了。
下面我们就通过几个简单的 Query 示例来展示一下 DISTINCT 的实现。
1.首先看看通过松散索引扫描完成 DISTINCT 的操作：
sky@localhost : example 11:03:41> EXPLAIN SELECT DISTINCT group_id
-> FROM group_message\G
*************************** [...]
MySQL 中 GROUP BY 基本实现原理
Tuesday, December 9th, 2008
之前连着写了几篇关于 MySQL 中常用操作的一些基本实现原理，如，MySQL ORDER BY，MySQL Join，这次再写一篇 MySQL 中 GROUP BY 的基本实现原理。
由于 GROUP BY 实际上也同样会进行排序操作，而且与 ORDER BY 相比，GROUP BY 主要只是多了排序之后的分组操作。当然，如果在分组的时候还使用了其他的一些聚合函数，那么还需要一些聚合函数的计算。所以，在GROUP BY 的实现过程中，与 ORDER BY 一样也可以利用到索引。
在 MySQL 中，GROUP BY 的实现同样有多种（三种）方式，其中有两种方式会利用现有的索引信息来完成 GROUP BY，另外一种为完全无法使用索引的场景下使用。下面我们分别针对这三种实现方式做一个分析。
1.使用松散（Loose）索引扫描实现 GROUP BY
何谓松散索引扫描实现 GROUP BY 呢？实际上就是当 MySQL 完全利用索引扫描来实现 GROUP BY 的时候，并不需要扫描所有满足条件的索引键即可完成操作得出结果。
下面我们通过一个示例来描述松散索引扫描实现 GROUP BY，在示例之前我们需要首先调整一下 group_message 表的索引，将 gmt_create 字段添加到 group_id 和 user_id 字段的索引中：
sky@localhost : example 08:49:45> create index [...]
关于磁盘的一些知识
Sunday, December 7th, 2008
最近在拜读张冬瓜的存储大作,收获还是很多的,这本书对于一些底层的技术细节阐述的比较细致,作者的思维,处理问题的方式也是活跃且严谨,
建议大家有时间可以看看,我梳理了些关于磁盘的概念,贴出来
1.磁盘组成,扇区,磁道,柱面
磁盘由若干盘片组成,在盘片上分布了很多细小的磁粒,每个小颗粒有自己的南北极,当磁头进行感应的时候,通过磁极就变成了电路上的1010信号,这样就达到了记录最原始的2进制信息的目的,在一个盘片上,盘片被划为很多同心圆,这个叫磁道,每个磁道又被划分为小块的细小圆弧段,一般是512字节,这个称为扇区,距离轴心近的磁道上包含的扇区比远的磁道要少很多,因为周长不一样,所以盘片旋转一圈,从外边缘获取的数据是最多的.若干盘片叠在一起,各个盘片上相同半径的同心圆就组成了一个柱面,当向一个磁盘读写数据的时候,如果是连续IO,磁盘会比较倾向于按照柱面来进行,因为写完一个盘片的磁道,切换到另外一个盘片的相同磁道,只需要切换磁头就可以了,如果是连续在一个盘片上写几个磁道,就涉及到磁臂换道,这个是机械动作 ,就慢的多了,如果是离散IO,那磁臂基本就像振动的蜜蜂翅膀.
2.低级格式化
磁盘生产出来的时候,上面是没有什么磁道,扇区的东西的,低级格式化就是在每个盘片上划分,标明这些东西,而高级格式化,比如WINDOWS里面的格式化,他是绝对不会影响一个磁盘的磁道,扇区结构的,这好比低级格式化是造房子,打框架,高级格式化是给房子里面做装潢
3.io size
一次IO的大小,这个解释很晦涩,从用户发起修改数据指令到数据最终落定到磁盘,这里面有很多层面,数据库的IO,文件系统的IO,磁盘控制器的IO,等等,其实这些IO经过多个层面,已经经过了多次的分解,最终落到磁盘的也就是那512字节的扇区,有人曾经问过这样的问题,IO最终到磁盘的是一个扇区,那上面有必要弄这么多IO SIZE出来吗?统一一下不更省事吗?其实这个问题最好自己到邮局去看看他们的流程,你去邮寄东西,他们会给你几组不同尺寸的箱子,主要看你的物品大小,适合用什么箱子,但他们最大的箱子也只能装比如1吨的物品,那你超过的话就只能分拆,当然你只邮寄个小铅笔的话,他们肯定不会建议你用很大的箱子,这些东西组合后邮寄出去,分到下面的中转站,经过诺干解包,或者合并,再次分发,最终,成为了一个一个的小包裹,由邮递员送到了目的地,我们的IO其实就和这个过程差不多,IO SIZE的大小决定了你与下层系统交互的次数,你应用程序的类型决定了你的IO SIZE
4.stripe size是128K,如果我就写一个8K的block,会怎么办,假设是8块盘做的raid0?
这个问题遇到过很多答案,有的说是继续做stripe,把8K分成8个1K的数据,写8个盘,也有的说是等后面的IO过来,攒满128K的时候再发出去,这些思路都是错误的,
这个时候不会再做stripe,而是随即的选择1块磁盘,将这个8K写入,如果有多个进程都发起这种IO,从总体上看,IO就分散到各个磁盘了,并且是可以并行执行的,
称做磁盘的并发率比较高,读取的话也是到各个盘去找,从单进程看,没有了stripe,但宏观上看,是很好的并发了
对于前台数据库系统,IO基本是小而且离散的,并发量也 比较大,这个时候就需要有比较高的磁盘并发率,如果你的IO SIZE总是大于stripe size,那就意味这每个IO会牵动
这个stripe下的所有磁盘,竞争就比较大了
MySQL 中 Join 的基本实现原理
Thursday, December 4th, 2008
在 MySQL 中，只有一种 Join 算法，就是大名鼎鼎的 Nested Loop Join，他没有其他很多数据库所提供的 Hash Join，也没有 Sort Merge Join。顾名思义，Nested Loop Join 实际上就是通过驱动表的结果集作为循环基础数据，然后一条一条的通过该结果集中的数据作为过滤条件到下一个表中查询数据，然后合并结果。如果还有第三个参 与 Join，则再通过前两个表的 Join 结果集作为循环基础数据，再一次通过循环查询条件到第三个表中查询数据，如此往复。
还是通过示例和图解来说明吧，后面将通过我个人数据库测试环境中的一个 example（自行设计，非MySQL 自己提供） 数据库中的三个表的 Join 查询来进行示例。
注意：由于这里有些内容需要在MySQL 5.1.18之后的版本中才会体现出来，所以本测试的MySQL 版本为5.1.26
表结构：
sky@localhost : example 11:09:32> show create table user_group\G
*************************** 1. row ***************************
Table: user_group
Create Table: CREATE TABLE `user_group` (
`user_id` int(11) NOT NULL,
`group_id` int(11) NOT NULL,
`user_type` int(11) NOT NULL,
`gmt_create` datetime NOT NULL,
`gmt_modified` [...]
