javascript 闭包详解

来源:极客标签   时间:2014-11-13 10:25:04   阅读数:26771

分享到:3

[导读] 今天我们从内存结构上来讲解下javascript中的闭包概念。闭包:是指有权访问另外一个函数作用域中的变量的函数。创建闭包的常见方式就是在一个函数内部创建另外一个函数。在javascript中没有块级作用域,一般为了

\
(单击图片查看大图)
今天我们从内存结构上来讲解下 javascript中的闭包概念。

闭包:是指有权访问另外一个函数作用域中的变量的函数。创建闭包的常见方式就是在一个函数内部创建另外一个函数。

在javascript中没有块级作用域,一般为了给某个函数申明一些只有该函数才能使用的局部变量时,我们就会用到闭包,这样我们可以很大程度上减少全局作用域中的变量,净化全局作用域。

使用闭包有如上的好处,当然这样的好处是需要付出代价的,代价就是内存的占用。

如何理解上面的那句话呢?

每个函数的执行,都会创建一个与该函数相关的函数执行环境,或者说是函数执行上下文。这个执行上下文中有一个属性 scope chain(作用域链指针),这个指针指向一个作用域链结构,作用域链中的指针又都指向各个作用域对应的活动对象。正常情况,一个函数在调用开始执行时创建这个函数执行上下文及相应的作用域链,在函数执行结束后释放函数执行上下文及相应作用域链所占的空间。

比如:

//声明函数
function test(){
var str = “hello world”;
console.log(str);
}

//调用函数
test();

在调用函数的时候会在内存中生成如下图的结构:
\
(单击图片查看大图)
但是闭包的情况就有点特殊了,由于闭包函数可以访问外层函数中的变量,所以外层函数在执行结束后,其作用域活动对象并不会被释放(注意,外层函数执行结束后执行环境和对应的作用域链就会被销毁),而是被闭包函数的作用域链所引用,直到闭包函数被销毁后,外层函数的作用域活动对象才会被销毁。这也正是闭包要占用内存的原因。

所以使用闭包有好处,也有坏处,滥用闭包会造成内存的大量消耗。

使用闭包还有其他的副作用,可以说是bug,也可以说不是,相对不同的业务可能就会有不同的看法。

这个副作用是闭包函数只能取到外层函数变量的最终值。

测试代码如下:(这里使用了jquery对象)

/*闭包缺陷*/
(function($){
var result = new Array(),
i = 0;
for(;i<10;i++){
result[i] = function(){
return i;
};
}
$.RES1 = result;
})(jQuery);
// 执行数组中的函数
$.RES1[0]();

上面的代码先通过匿名函数表达式开辟了一块私有作用域,这个匿名函数就是我们上面所说的外层函数,该外层函数有一个参数$,同时还定义了变量result和 I , 通过for循环给数组result赋值一个匿名函数,这个匿名函数就是闭包,他访问了外层函数的变量I , 理论上数组result[i]() 会返回相应的数组下标值,实际情况却不如所愿。

如上代码 $.RES1[0]() 的执行结果是10.

为什么会这样呢,因为i的最终值就是10.

下面我们通过下图来详细说明下,上面的那段代码执行时在内存中到底发生了什么:
\
(单击图片查看大图)
那么这个副作用有没有办法可以修复呢?当然可以!

我们可以通过下面的代码来达到我们的预期。

/*修复闭包缺陷*/
(function($){
var result = new Array(),
i = 0;
for(;i<10;i++){
result[i] = function(num){
return function(){
return num;
}
}(i);
}
$.RES2 = result;
})(jQuery);
//调用闭包函数
console.log($.RES2[0]());

上面的代码又在内存中发生了什么?我们同样用下面的一幅图来详细解释。看懂了上面的图,我们也就不难理解下面的图。
\
(单击图片查看大图)
只要看懂上面的三张图,我们也就可以深入的理解清楚javascript中闭包的原理,以及闭包的好处和弊端,在我们的代码中合理的使用闭包,达到代码的整洁和高效。

JavaScript 事件属性绑定带参数的函数

作者: 字体:[增加 减小] 类型:转载 时间:2009-03-13 我要评论

在JavaScript中,为了实现表现和控制相分离,可以通过0级的DOM事件属性或者2级的事件模型来实现,不过这两者在针对某个事件类型调用相应的事件句柄的时候,不能给事件句柄提供参数,也就是说,事件属性的值只能是一个函数引用。
例如不能采用这种调用方式:element.onclick = test();element.onclick = test(arg1,arg2);只能通过element.onclick = function(){ … };或者element.onclick = test这种方式来实现,所以无法给函数传递参数。参考了大量的网上资料,解决这个问题的方式,以代码为例,如下所示:

复制代码代码如下:
function Handler() { };
Handler.prototype = {
/*
* 把eventType类型的事件绑定到element元素,并使用handler事件句柄进行处理
* 兼容 IE 及 Firefox 等浏览器
*
* @param element 在其上注册事件的对象(Object)
* @param eventType 注册的事件类型(String),不加“on”
* @param handler 事件句柄(Function)
*/
registerEvent : function(element, eventType, handler) {
if(element.attachEvent) { //2级DOM的事件处理
element.attachEvent(‘on’+ eventType, handler);
}else if (element.addEventListener) {
element.addEventListener(eventType, handler, false);
} else { //0级DOM的事件处理
element[‘on’+ eventType] = handler;
}
},
/*
* 获得带参数的事件句柄的引用
*
* @param obj 需要绑定事件处理函数的所有者,null 表示 window 对象
* @param func 需要绑定的事件处理函数名
* @param … 第三个参数开始为绑定事件处理函数的参数,由 0 到多个构成
*/
bind: function(obj, handler) {
obj = obj || window;
var args = [];
for(var i =2; i < arguments.length; i++)
{
args.push(arguments[i]);
}
return function() { handler.apply(obj, args) };
}
}
可能是使用方式为:
function show(txtObj) {
alert(txtObj.value);
txtObj.focus();
txtObj.select();
}
window.onload = function(){
var handler = new Handler();
handler.registerEvent($(“txt”), “change”, handler.bind(null,show,$(“txt”)));//采用2级事件模型的方式
//$(“txt”).onchange = handler.bind(null,show,$(“txt”));//JavaScript事件属性的方式
}

Javascript事件绑定的几种方式

 

来源:http://www.cnblogs.com/rainman/archive/2009/02/11/1387955.html

上篇文章讲到了事件绑定的3中常用方法:传统绑定、W3C绑定方法、IE绑定方法。但是,在实际开发中对于我们来讲重要的是需要一个通用的、跨浏览器的绑定方法。如果我们在互联网上搜索一下会发现许多方法,一下是比较知名的几种方法:

在开始学期下面几种方法之前,应当讨论一下,一个好的addEvent()方法应当达到哪些要求:

a、支持同一元素的同一事件句柄可以绑定多个监听函数;

b、如果在同一元素的同一事件句柄上多次注册同一函数,那么第一次注册后的所有注册都被忽略;

c、函数体内的this指向的应当是正在处理事件的节点(如当前正在运行事件句柄的节点);

d、监听函数的执行顺序应当是按照绑定的顺序执行;

e、在函数体内不用使用 event = event || window.event; 来标准化Event对象;

一、John Resig 所写的 addEvent() 函数:http://ejohn.org/projects/flexible-javascript-events/

[javascript] view plain copy

  1. function addEvent( obj, type, fn ) {
  2.         if ( obj.attachEvent ) {
  3.             obj[‘e’+type+fn] = fn;
  4.             obj[type+fn] = function(){obj[‘e’+type+fn]( window.event );}
  5.             obj.attachEvent( ‘on’+type, obj[type+fn] );
  6.         } else
  7.             obj.addEventListener( type, fn, false );
  8.     }
  9.     function removeEvent( obj, type, fn ) {
  10.         if ( obj.detachEvent ) {
  11.             obj.detachEvent( ‘on’+type, obj[type+fn] );
  12.             obj[type+fn] = null;
  13.         } else
  14.             obj.removeEventListener( type, fn, false );
  15.     }

 

这个函数如此简单易懂,的确非常令人惊讶。那么我们还是要看看上面的五点要求:

对于第一点满足了;

对于第三点和第五点,肯定也满足了;

对于第二点,并没有满足,因为addEventListener()会忽略重复注册,而attachEvent()则不会忽略;

但是第四点,并没有满足,因为Dom标准没有确定调用一个对象的时间处理函数的顺序,所以不应该想当然的认为它们以注册的顺序调用。

但是这个函数仍然是一个非常优秀的函数。

二、Dean Edward 所写的 addEvent() 函数 :http://dean.edwards.name/weblog/2005/10/add-event2/

[javascript] view plain copy

  1. function addEvent(element, type, handler) {
  2.     if (!handler.
    guid)handler.

    guid = addEvent.guid++;

  3.     if (!element.events) element.events = {};
  4.         var handlers = element.events[type];
  5.     if (!handlers) {
  6.         handlers = element.events[type] = {};
  7.         if (element[“on” + type]) {
  8.             handlers[0] = element[“on” + type];
  9.         }
  10.     }
  11.     handlers[handler.$$guid] = handler;
  12.     element[“on” + type] = handleEvent;
  13. }
  14. addEvent.guid = 1;
  15. function removeEvent(element, type, handler) {
  16.     if (element.events && element.events[type]) {
  17.         delete element.events[type][handler.$$guid];
  18.     }
  19. }
  20. function handleEvent(event) {
  21.     var returnValue = true;
  22.     event = event || fixEvent(window.event);
  23.     var handlers = this.events[event.type];
  24.     for (var i in handlers) {
  25.         this.$$handleEvent = handlers[i];
  26.         if (this.$$handleEvent(event) === false) {
  27.             returnValue = false;
  28.         }
  29.     }
  30.     return returnValue;
  31. };
  32. function fixEvent(event) {
  33.     event.preventDefault = fixEvent.preventDefault;
  34.     event.stopPropagation = fixEvent.stopPropagation;
  35.     return event;
  36. };
  37. fixEvent.preventDefault = function() {
  38.     this.returnValue = false;
  39. };
  40. fixEvent.stopPropagation = function() {
  41.     this.cancelBubble = true;
  42. };

该函数使用了传统的绑定方法,所以它可以在所有的浏览器中工作,也不会造成内存泄露。

但是对于最初提出的5点,该函数只是满足了前四点。只有最后一点没有满足,因为在JavaScript中对for/in语句的执行顺序没有规定是按照赋值的顺序执行,尽管大部分时刻是按照预期的顺序执行,因此在不同的JavaScript版本或实现中这一语句的顺序有可能不同。

三、Dean Edward 的 addEvent() 函数的改进

[javascript] view plain copy

  1. Array.prototype.indexOf = function( obj ){
  2.     var result = -1 , length = this.length , i=length – 1;
  3.     for ( ; i>=0 ; i– ) {
  4.         if ( this[i] == obj ) {
  5.             result = i;
  6.             break;
  7.         }
  8.     }
  9.     return result;
  10. }
  11. Array.prototype.contains = function( obj ) {
  12.     return ( this.indexOf( obj ) >=0 )
  13. }
  14. Array.prototype.append = function( obj , nodup ) {
  15.     if ( !(nodup && this.contains( obj )) ) {
  16.         this[this.length] = obj;
  17.     }
  18. }
  19. Array.prototype.remove = function( obj ) {
  20.     var index = this.indexOf( obj );
  21.     if ( !index ) return ;
  22.     return this.splice( index , 1);
  23. };
  24. function addEvent(element , type , fun){
  25.     if (!element.events) element.events = {};
  26.     var handlers = element.events[type];
  27.     if (!handlers) {
  28.         handlers = element.events[type] = [];
  29.         if(element[‘on’ + type]) {
  30.             handlers[0] = element[‘on’ + type];
  31.         }
  32.     }
  33.     handlers.append( fun , true)
  34.     element[‘on’ + type] = handleEvent;
  35. }
  36. function removeEvent(element , type , fun) {
  37.     if (element.events && element.events[type]) {
  38.         element.events[type].remove(fun);
  39.     }
  40. }
  41. function handleEvent(event) {
  42.     var returnValue = true , i=0;
  43.     event = event || fixEvent(window.event);
  44.     var handlers = this.events[event.type] , length = handlers.length;
  45.     for ( ; i < length ; i++) {
  46.         if ( handlers[i].call( this , event) === false ){
  47.             returnValue = false;
  48.         }
  49.     }
  50.     return returnValue;
  51. }
  52. function fixEvent(event) {
  53.     event.preventDefault = fixEvent.preventDefault;
  54.     event.stopPropagation = fixEvent.stopPropagation;
  55.     return event;
  56. }
  57. fixEvent.preventDefault = function() {
  58.     this.returnValue = false;
  59. };
  60. fixEvent.stopPropagation = function() {
  61.     this.cancelBubble = true;
  62. };

该函数是本人对Dean Edward 的 addEvent() 函数的改进,完全满足了最初提出的5点要求。如果大家有更好的方法,期待分享!

来源:http://blog.csdn.net/haijiaoxiaowu/article/details/5150389

Javascript的事件绑定主要有四种方法(一下在IE中运行正常,但不保证其他浏览器):

[注:onXXX为某一事件,fun为某一function,domId为某一DOM对象id,event类型见后边附录。]

1、在DOM中,直接用onXXX=”fun();”进行绑定

2、在Javascript代码中用 DOM对象.onXXX=fun 进行绑定

3、用 DOM对象.attachEvent(“onXXX”,fun) 进行绑定

4、用<script for=”domId” event=”onXXX”>fun();</script> 进行绑定

  1. <html>
  2. <head>
  3. <title>event test</title>
  4. </head>
  5. <body onload=“init()”>
  6. <!– 绑定方式一:在元素中,通过onXXX(事件)设置绑定方法 –>
  7. <button id=“btn1” onclick=“display()” >绑定方式一</button>
  8. <!– 绑定方式二:在Javascript代码中,通过获得元素,为元素的onXXX(事件)设置绑定方法  –>
  9. <button id=“btn2”>绑定方式二</button>
  10. <!– 绑定方式三:通过for、event为元素绑定事件(IE4+)。for后面是元素id,event是具体事件  –>
  11. <button id=“btn3”>绑定方式三</button>
  12. <!– 绑定方式四:通过attachEvent为元素绑定事件(IE5+)。第一个参数是事件名,第二个参数是绑定的方法 –>
  13. <button id=“btn4”>绑定方式四</button>
  14. </body>
  15. </html>
  16. <script type=“text/javascript”>
  17.     function init() {
  18.         document.getElementById(“btn2”).onclick = display;//为button2绑定事件
  19.         document.getElementById(“btn4”).attachEvent(“onclick”, display);//为button4绑定事件
  20.     }
  21.     function display(event) {
  22.         var targ;//触发事件的对象引用
  23.         if (!event) {
  24.             var event = window.event;//获得当前事件(IE)
  25.         }
  26.         if (event.target) {//IE没有target
  27.             targ = evente.target;
  28.         } else if (event.srcElement) {//适用于IE
  29.             targ = event.srcElement;
  30.         }
  31.         //对触发事件的对象进行操作
  32.         alert(targ.tagName+”-“+targ.id+”-“+event.x+”-“+event.offsetX);
  33.         targ.disabled=“disabled” ;
  34.     }
  35. <script>
  36. <script for=“btn3” event=“onclick”>
  37.     display();//为button3绑定事件
  38. <script>

 

附一:event事件:

onabort: 图像的加载被中断
onblur: 元素失去焦点
onchange: 域的内容被改变
onclick: 当用户点击某个对象时调用的事件句柄
ondblclick: 当用户双击某个对象时调用的事件句柄
onerror: 在加载文档或图像时发生错误
onfocus: 元素获得焦点
onkeydown: 某个键盘按键被按下
onkeypress: 某个键盘按键被按下并松开
onkeyup: 某个键盘按键被松开
onload: 一张页面或一幅图像完成加载
onmousedown: 鼠标按钮被按下
onmousemove: 鼠标被移动
onmouseout: 鼠标从某元素移开
onmouseover: 鼠标移到某元素之上
onmouseup: 鼠标按键被松开
onreset: 重置按钮被点击
onresize: 窗口或框架被重新调整大小
onselect: 文本被选中
onsubmit: 确认按钮被点击
onunload: 用户退出页面

 

附二:IE event属性:

cancelBubble: 如果事件句柄想阻止事件传播到包容对象,必须把该属性设为 true。
fromElement :对于 mouseover 和 mouseout 事件,fromElement 引用移出鼠标的元素。
keyCode :对于 keypress 事件,该属性声明了被敲击的键生成的 Unicode 字符码。对于 keydown 和 keyup 事件,它指定了被敲击的键的虚拟键盘码。虚拟键盘码可能和使用的键盘的布局相关。
offsetX,offsetY :发生事件的地点在事件源元素的坐标系统中的 x 坐标和 y 坐标。
returnValue: 如果设置了该属性,它的值比事件句柄的返回值优先级高。把这个属性设置为 fasle,可以取消发生事件的源元素的默认动作。
srcElement :对于生成事件的 Window 对象、Document 对象或 Element 对象的引用。
toElement: 对于 mouseover 和 mouseout 事件,该属性引用移入鼠标的元素。
x,y: 事件发生的位置的 x 坐标和 y 坐标,它们相对于用CSS动态定位的最内层包容元素。

JavaScript与HTML交互——事件

JavaScript和HTML的交互是通过事件实现的。JavaScript采用异步事件驱动编程模型,当文档、浏览器、元素或与之相关对象发生特定事情时,浏览器会产生事件。如果JavaScript关注特定类型事件,那么它可以注册当这类事件发生时要调用的句柄。

事件流

事件流描述的是从页面中接收事件的顺序,比如有两个嵌套的div,点击了内层的div,这时候是内层的div先出发click事件还是外层先触发?目前主要有三种模型

IE的事件冒泡:事件开始时由最具体的元素接收,然后逐级向上传播到较为不具体的元素

Netscape的事件捕获:不太具体的节点更早接收事件,而最具体的元素最后接收事件,和事件冒泡相反

DOM事件流:DOM2级事件规定事件流包括三个阶段,事件捕获阶段,处于目标阶段,事件冒泡阶段,首先发生的是事件捕获,为截取事件提供机会,然后是实际目标接收事件,最后是冒泡句阶段。

Opera、Firefox、Chrome、Safari都支持DOM事件流,IE不支持事件流,只支持事件冒泡

如有以下html,点击div区域

复制代码
<!DOCTYPE html >
<html>
<head>
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <title>Test Page</title>
</head>
<body>
    <div>
        Click Here</div>
</body>
</html>
复制代码

Untitled

Untitled

Untitled

事件冒泡模型

事件捕获模型

DOM事件流

 

事件处理程序(handler)

我们也称之为事件侦听器(listener),事件就是用户或浏览器自身执行的某种动作。比如click、load、moseover等,都是事件类型(俗称事件名称),而响应某个事件的方法就叫做事件处理程序或者事件监听器或者事件句柄,事件处理程序名字是:on+事件类型。

了解了这些,我们看看如何给元素添加事件处理程序

HTML事件处理程序

元素支持的每个事件都可以使用一个相应事件处理程序同名的HTML属性指定。这个属性的值应该是可以执行的JavaScript代码,我们可以为一个button添加 click事件处理程序

<input type="button" value="Click Here" onclick="alert('Clicked!');" />

在HTML事件处理程序中可以包含要执行的具体动作,也可以调用在页面其它地方定义的脚本,刚才的例子可以写成这样

<input type="button" value="Click Here" onclick="showMessage();" />
    <script type="text/javascript">
        function showMessage() {
            alert('Clicked!');
        }

在HTML中指定事件处理程序书写很方便,但是有两个缺点。

首先,存在加载顺序问题,如果事件处理程序在html代码之后加载,用户可能在事件处理程序还未加载完成时就点击按钮之类的触发事件,存在时间差问题。

其次,这样书写html代码和JavaScript代码紧密耦合,维护不方便。

JavaScript指定事件处理程序

通过JavaScript指定事件处理程序就是把一个方法赋值给一个元素的事件处理程序属性。每个元素都有自己的事件处理程序属性,这些属性名称通常为小写,如onclick等,将这些属性的值设置为一个方法,就可以指定事件处理程序,如下

复制代码
<input id="btnClick" type="button" value="Click Here" />

    <script type="text/javascript">
        var btnClick = document.getElementById('btnClick');
        btnClick.onclick = function showMessage() {
            alert(this.id);
        };
    </script>
复制代码

这样处理,事件处理程序被认为是元素的方法,事件处理程序在元素的作用域下运行,this就是当前元素,所以点击button结果是:btnClick

这样还有一个好处,我们可以删除事件处理程序,只需把元素的onclick属性赋为null即可

DOM2事件处理程序

DOM2级事件定义了两个方法用于处理指定和删除事件处理程序的操作:addEventListener和removeEventListener。所有的DOM节点都包含这两个方法,并且它们都接受三个参数:事件类型、事件处理方法、一个布尔值。最后布尔参数如果是true表示在捕获阶段调用事件处理程序,如果是false,则是在事件冒泡阶段处理。

刚才的例子我们可以这样写

复制代码
<input id="btnClick" type="button" value="Click Here" />

    <script type="text/javascript">
        var btnClick = document.getElementById('btnClick');
        btnClick.addEventListener('click', function() {
            alert(this.id);
        }, false);
    </script>
复制代码

上面代码为button添加了click事件的处理程序,在冒泡阶段触发,与上一种方法一样,这个程序也是在元素的作用域下运行,不过有一个好处,我们可以为click事件添加多个处理程序

复制代码
<input id="btnClick" type="button" value="Click Here" />

    <script type="text/javascript">
        var btnClick = document.getElementById('btnClick');
        btnClick.addEventListener('click', function() {
            alert(this.id);
        }, false);
        btnClick.addEventListener('click', function() {
            alert('Hello!');
        }, false);
    </script>
复制代码

这样两个事件处理程序会在用户点击button后按照添加顺序依次执行。

通过addEventListener添加的事件处理程序只能通过removeEventListener移除,移除时参数与添加的时候相同,这就意味着刚才我们添加的匿名函数无法移除,因为匿名函数虽然方法体一样,但是句柄却不相同,所以当我们有移除事件处理程序的时候可以这样写

复制代码
<input id="btnClick" type="button" value="Click Here" />

    <script type="text/javascript">
        var btnClick = document.getElementById('btnClick');
        var handler=function() {
            alert(this.id);
        }
        btnClick.addEventListener('click', handler, false);
        btnClick.removeEventListener('click', handler, false);
    </script>
复制代码

下面就是老生常谈的IE兼容性问题了。。。

IE并不支持addEventListener和removeEventListener方法,而是实现了两个类似的方法attachEvent和detachEvent,这两个方法都接收两个相同的参数,事件处理程序名称和事件处理程序方法,由于IE指支持事件冒泡,所以添加的程序会被添加到冒泡阶段。

使用attachEvent添加事件处理程序可以如下

复制代码
<input id="btnClick" type="button" value="Click Here" />

    <script type="text/javascript">
        var btnClick = document.getElementById('btnClick');
        var handler=function() {
            alert(this.id);
        }
        btnClick.attachEvent(

‘onclick’

, handler);
    </script>
复制代码

结果是undefined,很奇怪,一会儿我们会介绍到

使用attachEvent添加的事件处理程序可以通过detachEvent移除,条件也是相同的参数,匿名函数不能被移除。

复制代码
<input id="btnClick" type="button" value="Click Here" />

    <script type="text/javascript">
        var btnClick = document.getElementById('btnClick');
        var handler=function() {
            alert(this.id);
        }
        btnClick.attachEvent('onclick', handler);
        btnClick.detachEvent('onclick', handler);
    </script>
复制代码

跨浏览器的事件处理程序

前面内容我们可以看到,在不同的浏览器下,添加和移除事件处理程序方式不相同,要想写出跨浏览器的事件处理程序,首先我们要了解不同的浏览器下处理事件处理程序的区别

在添加事件处理程序事addEventListener和attachEvent主要有几个区别

1. 参数个数不相同,这个最直观,addEventListener有三个参数,attachEvent只有两个,attachEvent添加的事件处理程序只能发生在冒泡阶段,addEventListener第三个参数可以决定添加的事件处理程序是在捕获阶段还是冒泡阶段处理(我们一般为了浏览器兼容性都设置为冒泡阶段)

2. 第一个参数意义不同,addEventListener第一个参数是事件类型(比如click,load),而attachEvent第一个参数指明的是事件处理函数名称(onclick,onload)

3. 事件处理程序的作用域不相同,addEventListener得作用域是元素本身,this是指的触发元素,而attachEvent事件处理程序会在全局变量内运行,this是window,所以刚才例子才会返回undefined,而不是元素id

4. 为一个事件添加多个事件处理程序时,执行顺序不同,addEventListener添加会按照添加顺序执行,而attachEvent添加多个事件处理程序时顺序无规律(添加的方法少的时候大多是按添加顺序的反顺序执行的,但是添加的多了就无规律了),所以添加多个的时候,不依赖执行顺序的还好,若是依赖于函数执行顺序,最好自己处理,不要指望浏览器

 

了解了这四点区别后我们可以尝试写一个浏览器兼容性比较好的添加事件处理程序方法

复制代码
function addEvent(node, type, handler) {
            if (!node) return false;
            if (node.addEventListener) {
                node.addEventListener(type, handler, false);
                return true;
            }
            else if (node.attachEvent) {
                node.attachEvent('on' + type, handler, );
                return true;
            }
            return false;
        }
复制代码

这样,首先我们解决了第一个问题参数个数不同,现在三个参数,采用事件冒泡阶段触发,第二个问题也得以解决,如果是IE,我们给type添加上on,第四个问题目前还没有解决方案,需要用户自己注意,一般情况下,大家也不会添加很多事件处理程序,试试这个方法感觉很不错,但是我们没有解决第三个问题,由于处理程序作用域不同,如果handler内有this之类操作,那么就会出错在IE下,实际上大多数函数都会有this操作。

复制代码
function addEvent(node, type, handler) {
            if (!node) return false;
            if (node.addEventListener) {
                node.addEventListener(type, handler, false);
                return true;
            }
            else if (node.attachEvent) {
                node.attachEvent('on' + type, function() { handler.apply(node); });
                return true;
            }
            return false;
        }
复制代码

这样处理就可以解决this的问题了,但是新的问题又来了,我们这样等于添加了一个匿名的事件处理程序,无法用detachEvent取消事件处理程序,有很多解决方案,我们可以借鉴大师的处理方式,jQuery创始人John Resig是这样做的

复制代码
function addEvent(node, type, handler) {
            if (!node) return false;
            if (node.addEventListener) {
                node.addEventListener(type, handler, false);
                return true;
            }
            else if (node.attachEvent) {
                node['e' + type + handler] = handler;
                node[type + handler] = function() {
                    node['e' + type + handler](window.event);
                };
                node.attachEvent('on' + type, node[type + handler]);
                return true;
            }
            return false;
        }
复制代码

在取消事件处理程序的时候

复制代码
function removeEvent(node, type, handler) {
            if (!node) return false;
            if (node.removeEventListener) {
                node.removeEventListener(type, handler, false);
                return true;
            }
            else if (node.detachEvent) {
                node.detachEvent('on' + type, node[type + handler]);
                node[type + handler] = null;
            }
            return false;
        }
复制代码

John Resig很巧妙地利用了闭包,看起来很不错。

事件对象

在触发DOM上的某个事件的时候会产生一个事件对象event,这个对象包含着所有与事件有关的信息,包括产生事件的元素、事件类型等相关信息。所有浏览都支持event对象,但支持方式不同。

DOM中的事件对象

兼容DOM的浏览器会产生一个event对象传入事件处理程序中。应用一下刚才我们写的addEvent方法

var btnClick = document.getElementById('btnClick');
    addEvent(btnClick, 'click', handler);

点击button的时候我们可以看到弹出内容是click的弹窗

event对象包含与创建它的特定事件有关的属性和方法,触发事件的类型不同,可用的属性和方法也不同,但是所有事件都会包含

属性/方法

类型

读/写

说明

bubbles Boolean 只读 事件是否冒泡
cancelable Boolean 只读 是否可以取消事件的默认行为
currentTarget Element 只读 事件处理程序当前处理元素
detail Integer 只读 与事件相关细节信息
eventPhase Integer 只读 事件处理程序阶段:1 捕获阶段,2 处于目标阶段,3 冒泡阶段
preventDefault() Function 只读 取消事件默认行为
stopPropagation() Function 只读 取消事件进一步捕获或冒泡
target Element 只读 事件的目标元素
type String 只读 被触发的事件类型
view AbstractView 只读 与事件关联的抽象视图,等同于发生事件的window对象

在事件处理程序内部,this始终等同于currentTarget,而target是事件的实际目标。

要阻止事件的默认行为,可以使用preventDefault()方法,前提是cancelable值为true,比如我们可以阻止链接导航这一默认行为

document.getElementsByTagName('a').onclick = function (e) {
            e.preventDefault();
        }

stopPaopagation()方法可以停止事件在DOM层次的传播,即取消进一步的事件捕获或冒泡。我们可以在button的事件处理程序中调用stopPropagation()从而避免注册在body上的事件发生

复制代码
var handler = function (e) {
            alert(e.type);
            e.stopPropagation();
        }
        addEvent(document.body, 'click', function () { alert('Clicked body')});
        var btnClick = document.getElementById('btnClick');
        addEvent(btnClick, 'click', handler);
复制代码

若是注释掉e.stopPropagation(); 在点击button的时候,由于事件冒泡,body的click事件也会触发,但是调用这句后,事件会停止传播。

IE中的事件对象

访问IE中的event对象有几种不同的方式,取决于指定事件处理程序的方法。直接为DOM元素添加事件处理程序时,event对象作为window对象的一个属性存在

复制代码
var handler = function () {
            var e = window.event;
            alert(e.type);
        }
        var btnClick = document.getElementById('btnClick');
        btnClick.onclick = handler;
复制代码

我们通过window.event取得了event对象,并检测到了其类型,可是如果事件处理程序是通过attachEvent添加的,那么就会有一个event对象被传入事件处理程序中

var handler = function (e) {
            alert(e.type);
        }
        var btnClick = document.getElementById('btnClick');
        attachEvent(btnClick, handler);

当然这时候也可以通过window对象访问event,方便起见,我们一般会传入event对象,IE中所有的事件都包含以下属性方法

属性/方法

类型

读/写

说明

cancelBulle Boolean 读/写 默认为false,设置为true后可以取消事件冒泡
returnValue Boolean 读/写 默认为true,设为false可以取消事件默认行为
srcElement Element 只读 事件的目标元素
type String 只读 被触发的事件类型
跨浏览器的事件对象

虽然DOM和IE的event对象不同,但基于它们的相似性,我们还是可以写出跨浏览器的事件对象方案

复制代码
function getEvent(e) {
            return e || window.event;
        }

        function getTarget(e) {
            return e.target || e.scrElement;
        }

        function preventDefault(e) {
            if (e.preventDefault)
                e.preventDefault();
            else
                e.returnValue = false;
        }

        function stopPropagation(e) {
            if (e.stopPropagation)
                e.stopPropagation();
            else
                e.cancelBubble = true;
        }
复制代码

 

常用HTML事件

有一些HTML事件我们会经常用到,这些事件不一定与用户操作有关,这里只是简单提及,详细用法大家就得百度谷歌了

  1. load:当页面完全加载后在window上触发,当图像加载完成后在img元素上触发,或当嵌入内容加载完成时,在object元素上触发
  2. unload:页面完全卸载后在window上触发,或嵌入内容卸载后在object元素触发
  3. select:用户选择文本框中的字符时触发
  4. change:文本框焦点变化后其值改变时触发
  5. submit:用户提交表单的时候触发
  6. resize:窗口或框架大小变化的时候在window上触发
  7. scrool:用户滚动带滚动条的元素时,在该元素上触发
  8. focus:页面或元素获得焦点时在window及相应元素上触发
  9. blur:页面或元素失去焦点时在window及相应元素上触发
  10. beforeunload:页面卸载前在window上触发
  11. mousewheel:不算HTML的,当用户通过鼠标滚轮与页面交互,在垂直方向滚动页面时触发

NoSQL数据库探讨

NoSQL数据库探讨之一 - 为什么要用非关系数据库?(转载:http://robbin.javaeye.com/blog/524977)

关键字: nosql

随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速。

而传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,

暴露了很多难以克服的问题,例如:

1、High performance – 对数据库高并发读写的需求

web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息,所以基本上无法使用动态页面静态化技术,因此数据库并发负载非常高,往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住,但是应付上万次SQL写数据请求,硬盘IO就已经无法承受了。其实对于普通的BBS网站,往往也存在对高并发写请求的需求,例如像JavaEye网站的实时统计在线用户状态,记录热门帖子的点击次数,投票计数等,因此这是一个相当普遍的需求。

 

2、Huge Storage – 对海量数据的高效率存储和访问的需求

类似Facebook,twitter,Friendfeed这样的SNS网站,每天用户产生海量的用户动态,以Friendfeed为例,一个月就达到了2.5亿条用户动态,对于关系数据库来说,在一张2.5亿条记录的表里面进行SQL查询,效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统,例如腾讯,盛大,动辄数以亿计的帐号,关系数据库也很难应付。

 

3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

在基于web的架构当中,数据库是最难进行横向扩展的,当一个应用系统的用户量和访问量与日俱增的时候,你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说,对数据库系统进行升级和扩展是非常痛苦的事情,往往需要停机维护和数据迁移,为什么数据库不能通过不断的添加服务器节点来实现扩展呢?

 

在上面提到的“三高”需求面前,关系数据库遇到了难以克服的障碍,而对于web2.0网站来说,关系数据库的很多主要特性却往往无用武之地,例如:

1、数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务,对读一致性的要求很低,有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

2、数据库的写实时性和读实时性需求

对关系数据库来说,插入一条数据之后立刻查询,是肯定可以读出来这条数据的,但是对于很多web应用来说,并不要求这么高的实时性,比方说我(JavaEye的robbin)发一条消息之后,过几秒乃至十几秒之后,我的订阅者才看到这条动态是完全可以接受的。

3、对复杂的SQL查询,特别是多表关联查询的需求

任何大数据量的web系统,都非常忌讳多个大表的关联查询,以及复杂的数据分析类型的复杂SQL报表查询,特别是SNS类型的网站,从需求以及产品设计角度,就避免了这种情况的产生。往往更多的只是单表的主键查询,以及单表的简单条件分页查询,SQL的功能被极大的弱化了。

 

因此,关系数据库在这些越来越多的应用场景下显得不那么合适了,为了解决这类问题的非关系数据库应运而生,现在这两年,各种各样非关系数据库,特别是键值数据库(Key-Value Store DB)风起云涌,多得让人眼花缭乱。前不久国外刚刚举办了NoSQL Conference,各路NoSQL数据库纷纷亮相,加上未亮相但是名声在外的,起码有超过10个开源的NoSQLDB,例如:

Redis,Tokyo Cabinet,Cassandra,Voldemort,MongoDB,Dynomite,HBase,CouchDB,Hypertable, Riak,Tin, Flare, Lightcloud, KiokuDB,Scalaris, Kai, ThruDB, ……

 

这些NoSQL数据库,有的是用C/C++编写的,有的是用Java编写的,还有的是用Erlang编写的,每个都有自己的独到之处,看都看不过来了,我(robbin)也只能从中挑选一些比较有特色,看起来更有前景的产品学习和了解一下。这些NoSQL数据库大致可以分为以下的三类:

 

 一、满足极高读写性能需求的Kye-Value数据库:Redis,Tokyo Cabinet, Flare

高性能Key-Value数据库的主要特点就是具有极高的并发读写性能,Redis,Tokyo Cabinet, Flare,这3个Key-Value DB都是用C编写的,他们的性能都相当出色,但出了出色的性能,他们还有自己独特的功能:

1、Redis

是一个很新的项目,刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。

1)高性能读写:因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过10万次读写操作,是我知道的性能最快的Key-Value DB。

2)支持保存List链表和Set集合的数据结构,而且还支持对List进行各种操作:Redis的出色之处不仅仅是性能,Redis最大的魅力是支持保存List链表和Set集合的数据结构,而且还支持对List进行各种操作:例如从List两端push和pop数据,取List区间,排序等等,对Set支持各种集合的并集交集操作,

3)value可以存1G:单个value的最大限制是1GB,不像memcached只能保存1MB的数据,因此Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性能消息队列服务,用他的Set可以做高性能的tag系统等等。

4) 加强版的memcached来用:另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一个功能加强版的memcached来用。

Redis的主要缺点是数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,并且它没有原生的可扩展机制,不具有scale(可扩展)能力,要依赖客户端来实现分布式读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有github,Engine Yard。

 

2、Tokyo Cabinet

Tokyo Cabinet 和Tokoy Tyrant TC和TT的开发者是日本人Mikio Hirabayashi,主要被用在日本最大的SNS网站mixi.jp上,TC发展的时间最早,现在已经是一个非常成熟的项目,也是Kye-Value数据库领域最大的热点,现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎,而TT提供了多线程高并发服务器,性能也非常出色,每秒可以处理4-5万次读写操作。 TC除了支持Key-Value存储之外,还支持保存Hashtable数据类型,因此很像一个简单的数据库表,并且还支持基于column的条件查询,分页查询和排序功能,基本上相当于支持单表的基础查询功能了,所以可以简单的替代关系数据库的很多操作,这也是TC受到大家欢迎的主要原因之一,有一个Ruby的项目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作,用起来非常爽。 TC/TT在mixi的实际应用当中,存储了2000万条以上的数据,同时支撑了上万个并发连接,是一个久经考验的项目。TC在保证了极高的并发读写性能的同时,具有可靠的数据持久化机制,同时还支持类似关系数据库表结构的hashtable以及简单的条件,分页和排序操作,是一个很棒的NoSQL数据库。

TC的主要缺点是在数据量达到上亿级别以后,并发写数据性能会大幅度下降,NoSQL: If Only It Was That Easy提到,他们发现在TC里面插入1.6亿条2-20KB数据的时候,写入性能开始急剧下降。看来是当数据量上亿条的时候,TC性能开始大幅度下降,从TC作者自己提供的mixi数据来看,至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。 这个是Tim Yang做的一个Memcached,Redis和Tokyo Tyrant的简单的性能评测,仅供参考

3、Flare

Flare TC是日本第一大SNS网站mixi开发的,而Flare是日本第二大SNS网站green.jp开发的,有意思吧。Flare简单的说就是给TC添加了scale功能。他替换掉了TT部分,自己另外给TC写了网络服务器,Flare的主要特点就是支持scale能力,他在网络服务端之前添加了一个node server,来管理后端的多个服务器节点,因此可以动态添加数据库服务节点,删除服务器节点,也支持failover。如果你的使用场景必须要让TC可以scale,那么可以考虑flare。

flare唯一的缺点就是他只支持memcached协议,因此当你使用flare的时候,就不能使用TC的table数据结构了,只能使用TC的key-value数据结构存储。

 

二、满足海量存储需求和访问的面向文档的数据库:MongoDB,CouchDB

面向文档的非关系数据库主要解决的问题不是高性能的并发读写,而是保证海量数据存储的同时,具有良好的查询性能。MongoDB是用C++开发的,而CouchDB则是Erlang开发的:

1、MongoDB

MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。

1)支持的数据结构非常松散,是类似json的bjson格式(BJSON全称:Binary JSON,BJSON把文件的二进制格式的数据直接保存到MongoDB的文档结构中),因此可以存储比较复杂的数据类型。

  2)支持的查询语言非常强大,Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。

3) 海量数据的访问效率,Mongo主要解决的是海量数据的访问效率问题,根据官方的文档,当数据量达到50GB以上的时候,Mongo的数据库访问速度是MySQL的10倍以上。Mongo的并发读写效率不是特别出色,根据官方提供的性能测试表明,大约每秒可以处理0.5万-1.5次读写请求。对于Mongo的并发读写性能,我(robbin)也打算有空的时候好好测试一下。 因为Mongo主要是支持海量数据存储的,所以Mongo还自带了一个出色的分布式文件系统GridFS,可以支持海量的数据存储,但我也看到有些评论认为GridFS性能不佳,这一点还是有待亲自做点测试来验证了。 最后由于Mongo可以支持复杂的数据结构,而且带有强大的数据查询功能,因此非常受到欢迎,很多项目都考虑用MongoDB来替代MySQL来实现不是特别复杂的Web应用,比方说why we migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例,由于数据量实在太大,所以迁移到了Mongo上面,数据查询的速度得到了非常显著的提升。 MongoDB也有一个ruby的项目MongoMapper,是模仿Merb的DataMapper编写的MongoDB的接口,使用起来非常简单,几乎和DataMapper一模一样,功能非常强大易用。

2、CouchDB

CouchDB现在是一个非常有名气的项目,似乎不用多介绍了。但是我却对CouchDB没有什么兴趣,主要是因为CouchDB仅仅提供了基于HTTP REST的接口,因此CouchDB单纯从并发读写性能来说,是非常糟糕的,这让我立刻抛弃了对CouchDB的兴趣。

 

三、满足高可扩展性和可用性的面向分布式计算的数据库:Cassandra,Voldemort

面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样,它首先必须是一个分布式的数据库系统,由分布在不同节点上面的数据库共同构成一个数据库服务系统,并且根据这种分布式架构来提供online的,具有弹性的可扩展能力,例如可以不停机的添加更多数据节点,删除数据节点等等。因此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的:

1、Cassandra

Cassandra项目是Facebook在2008年开源出来的,随后Facebook自己使用Cassandra的另外一个不开源的分支,而开源出来的Cassandra主要被Amazon的Dynamite团队来维护,并且Cassandra被认为是Dynamite2.0版本。目前除了Facebook之外,twitter和digg.com都在使用Cassandra。 Cassandra的主要特点就是它不是一个数据库,而是由一堆数据库节点共同构成的一个分布式网络服务,对Cassandra的一个写操作,会被复制到其他节点上去,对Cassandra的读操作,也会被路由到某个节点上面去读取。

对于一个Cassandra群集来说,扩展性能是比较简单的事情,只管在群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。 Cassandra也支持比较丰富的数据结构和功能强大的查询语言,和MongoDB比较类似,查询功能比MongoDB稍弱一些,twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra:http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/,有非常详细的介绍。 Cassandra以单个节点来衡量,其节点的并发读写性能不是特别好,有文章说评测下来Cassandra每秒大约不到1万次读写请求,我也看到一些对这个问题进行质疑的评论,但是评价Cassandra单个节点的性能是没有意义的,真实的分布式数据库访问系统必然是n多个节点构成的系统,其并发性能取决于整个系统的节点数量,路由效率,而不仅仅是单节点的并发负载能力。

2、Voldemort

Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统,Cassandra来自于Facebook这个SNS网站,而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库,例如Cassandar,Voldemort,Tokyo Cabinet,Flare等等。Voldemort的资料不是很多,因此我没有特别仔细去钻研,Voldemort官方给出Voldemort的并发读写性能也很不错,每秒超过了1.5万次读写。 从Facebook开发Cassandra,Linkedin开发Voldemort,我们也可以大致看出国外大型SNS网站对于分布式数据库,特别是对数据库的scale能力方面的需求是多么殷切。前面我(robbin)提到,web应用的架构当中,web层和app层相对来说都很容易横向扩展,唯有数据库是单点的,极难scale,现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向,这也是为什么现在Cassandra这么热门的主要原因。 如今,NoSQL数据库是个令人很兴奋的领域,总是不断有新的技术新的产品冒出来,改变我们已经形成的固有的技术观念,我自己(robbin)稍微了解了一些,就感觉自己深深的沉迷进去了,可以说NoSQL数据库领域也是博大精深的,我(robbin)也只能浅尝辄止,我(robbin)写这篇文章既是自己一点点钻研心得,也是抛砖引玉,希望吸引对这个领域有经验的朋友来讨论和交流。 从我(robbin)个人的兴趣来说,分布式数据库系统不是我能实际用到的技术,因此不打算花时间深入,而其他两个数据领域(高性能NoSQLDB和海量存储NoSQLDB)都是我很感兴趣的,特别是Redis,TT/TC和MongoDB这3个NoSQL数据库,因此我接下来将写三篇文章分别详细介绍这3个数据库。

8种Nosql数据库系统对比

读:Kristóf Kovács 是一位软件架构师和咨询顾问,他最近发布了一片对比各种类型NoSQL数据库的文章。

虽然SQL数据库是非常有用的工具,但经历了15年的一支独秀之后垄断即将被打破。这只是时间问题:被迫使用关系数据库,但最终发现不能适应需求的情况不胜枚举。

但是NoSQL数据库之间的不同,远超过两 SQL数据库之间的差别。这意味着软件架构师更应该在项目开始时就选择好一个适合的 NoSQL数据库。针对这种情况,这里对CassandraMongodbCouchDBRedis、 RiakMembaseNeo4j 和 HBase 进行了比较:

(编注1:NoSQL:是一项全新的数据库革命性运动,NoSQL的拥护者们提倡运用非关系型的数据存储。现今的计算机体系结构在数据存储方面要求具 备庞大的水平扩 展性,而NoSQL致力于改变这一现状。目前Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。 参见NoSQL词条。)

 

1. CouchDB

  • 所用语言: Erlang
  • 特点:DB一致性,易于使用
  • 使用许可: Apache
  • 协议: HTTP/REST
  • 双向数据复制,
  • 持续进行或临时处理,
  • 处理时带冲突检查,
  • 因此,采用的是master-master复制(见编注2)
  • MVCC – 写操作不阻塞读操作
  • 可保存文件之前的版本
  • Crash-only(可靠的)设计
  • 需要不时地进行数据压缩
  • 视图:嵌入式 映射/减少
  • 格式化视图:列表显示
  • 支持进行服务器端文档验证
  • 支持认证
  • 根据变化实时更新
  • 支持附件处理
  • 因此, CouchApps(独立的 js应用程序)
  • 需要 jQuery程序库

 

最佳应用场景:适用于数据变化较少,执行预定义查询,进行数据统计的应用程序。适用于需要提供数据版本支持的应用程序。

例如: CRM、CMS系统。 master-master复制对于多站点部署是非常有用的。

(编注2:master-master复制:是一种数据库同步方法,允许数据在一组计算机之间共享数据,并且可以通过小组中任意成员在组内进行数据更新。)

 

2. Redis

  • 所用语言:C/C++
  • 特点:运行异常快
  • 使用许可: BSD
  • 协议:类 Telnet
  • 有硬盘存储支持的内存数据库,
  • 但自2.0版本以后可以将数据交换到硬盘(注意, 2.4以后版本不支持该特性!)
  • Master-slave复制(见编注3)
  • 虽然采用简单数据或以键值索引的哈希表,但也支持复杂操作,例如 ZREVRANGEBYSCORE。
  • INCR & co (适合计算极限值或统计数据)
  • 支持 sets(同时也支持 union/diff/inter)
  • 支持列表(同时也支持队列;阻塞式 pop操作)
  • 支持哈希表(带有多个域的对象)
  • 支持排序 sets(高得分表,适用于范围查询)
  • Redis支持事务
  • 支持将数据设置成过期数据(类似快速缓冲区设计)
  • Pub/Sub允许用户实现消息机制

 

最佳应用场景:适用于数据变化快且数据库大小可遇见(适合内存容量)的应用程序。

例如:股票价格、数据分析、实时数据搜集、实时通讯。

(编注3:Master-slave复制:如果同一时刻只有一台服务器处理所有的复制请求,这被称为 Master-slave复制,通常应用在需要提供高可用性的服务器集群。)

 

3. MongoDB

  • 所用语言:C++
  • 特点:保留了SQL一些友好的特性(查询,索引)。
  • 使用许可: AGPL(发起者: Apache)
  • 协议: Custom, binary( BSON)
  • Master/slave复制(支持自动错误恢复,使用 sets 复制)
  • 内建分片机制
  • 支持 javascript表达式查询
  • 可在服务器端执行任意的 javascript函数
  • update-in-place支持比CouchDB更好
  • 在数据存储时采用内存到文件映射
  • 对性能的关注超过对功能的要求
  • 建议最好打开日志功能(参数 –journal)
  • 在32位操作系统上,数据库大小限制在约2.5Gb
  • 空数据库大约占 192Mb
  • 采用 GridFS存储大数据或元数据(不是真正的文件系统)

 

最佳应用场景:适用于需要动态查询支持;需要使用索引而不是 map/reduce功能;需要对大数据库有性能要求;需要使用 CouchDB但因为数据改变太频繁而占满内存的应用程序。

例如:你本打算采用 MySQL或 PostgreSQL,但因为它们本身自带的预定义栏让你望而却步。

 

4. Riak

  • 所用语言:Erlang和C,以及一些Javascript
  • 特点:具备容错能力
  • 使用许可: Apache
  • 协议: HTTP/REST或者 custom binary
  • 可调节的分发及复制(N, R, W)
  • 用 JavaScript or Erlang在操作前或操作后进行验证和安全支持。
  • 使用JavaScript或Erlang进行 Map/reduce
  • 连接及连接遍历:可作为图形数据库使用
  • 索引:输入元数据进行搜索(1.0版本即将支持)
  • 大数据对象支持( Luwak)
  • 提供“开源”和“企业”两个版本
  • 全文本搜索,索引,通过 Riak搜索服务器查询( beta版)
  • 支持Masterless多站点复制及商业许可的 SNMP监控

 

最佳应用场景:适用于想使用类似 Cassandra(类似Dynamo)数据库但无法处理 bloat及复杂性的情况。适用于你打算做多站点复制,但又需要对单个站点的扩展性,可用性及出错处理有要求的情况。

例如:销售数据搜集,工厂控制系统;对宕机时间有严格要求;可以作为易于更新的 web服务器使用。

5. Membase

  • 所用语言: Erlang和C
  • 特点:兼容 Memcache,但同时兼具持久化和支持集群
  • 使用许可: Apache 2.0
  • 协议:分布式缓存及扩展
  • 非常快速(200k+/秒),通过键值索引数据
  • 可持久化存储到硬盘
  • 所有节点都是唯一的( master-master复制)
  • 在内存中同样支持类似分布式缓存的缓存单元
  • 写数据时通过去除重复数据来减少 IO
  • 提供非常好的集群管理 web界面
  • 更新软件时软无需停止数据库服务
  • 支持连接池和多路复用的连接代理

 

最佳应用场景:适用于需要低延迟数据访问,高并发支持以及高可用性的应用程序

例如:低延迟数据访问比如以广告为目标的应用,高并发的 web 应用比如网络游戏(例如 Zynga)

 

6. Neo4j

  • 所用语言: Java
  • 特点:基于关系的图形数据库
  • 使用许可: GPL,其中一些特性使用 AGPL/商业许可
  • 协议: HTTP/REST(或嵌入在 Java中)
  • 可独立使用或嵌入到 Java应用程序
  • 图形的节点和边都可以带有元数据
  • 很好的自带web管理功能
  • 使用多种算法支持路径搜索
  • 使用键值和关系进行索引
  • 为读操作进行优化
  • 支持事务(用 Java api)
  • 使用 Gremlin图形遍历语言
  • 支持 Groovy脚本
  • 支持在线备份,高级监控及高可靠性支持使用 AGPL/商业许可

 

最佳应用场景:适用于图形一类数据。这是 Neo4j与其他nosql数据库的最显著区别

例如:社会关系,公共交通网络,地图及网络拓谱

 

7. Cassandra

  • 所用语言: Java
  • 特点:对大型表格和 Dynamo支持得最好
  • 使用许可: Apache
  • 协议: Custom, binary (节约型)
  • 可调节的分发及复制(N, R, W)
  • 支持以某个范围的键值通过列查询
  • 类似大表格的功能:列,某个特性的列集合
  • 写操作比读操作更快
  • 基于 Apache分布式平台尽可能地 Map/reduce
  • 我承认对 Cassandra有偏见,一部分是因为它本身的臃肿和复杂性,也因为 Java的问题(配置,出现异常,等等)

 

最佳应用场景:当使用写操作多过读操作(记录日志)如果每个系统组建都必须用 Java编写(没有人因为选用 Apache的软件被解雇)

例如:银行业,金融业(虽然对于金融交易不是必须的,但这些产业对数据库的要求会比它们更大)写比读更快,所以一个自然的特性就是实时数据分析

 

8. HBase

(配合 ghshephard使用)

  • 所用语言: Java
  • 特点:支持数十亿行X上百万列
  • 使用许可: Apache
  • 协议:HTTP/REST (支持 Thrift,见编注4)
  • 在 BigTable之后建模
  • 采用分布式架构 Map/reduce
  • 对实时查询进行优化
  • 高性能 Thrift网关
  • 通过在server端扫描及过滤实现对查询操作预判
  • 支持 XML, Protobuf, 和binary的HTTP
  • Cascading, hive, and pig source and sink modules
  • 基于 Jruby( JIRB)的shell
  • 对配置改变和较小的升级都会重新回滚
  • 不会出现单点故障
  • 堪比MySQL的随机访问性能

 

最佳应用场景:适用于偏好BigTable:)并且需要对大数据进行随机、实时访问的场合。

例如: Facebook消息数据库(更多通用的用例即将出现)

编注4:Thrift 是一种接口定义语言,为多种其他语言提供定义和创建服务,由Facebook开发并开源

当然,所有的系统都不只具有上面列出的这些特性。这里我仅仅根据自己的观点列出一些我认为的重要特性。与此同时,技术进步是飞速的,所以上述的内容肯定需要不断更新。我会尽我所能地更新这个列表。

MySQL索引原理及慢查询优化

MySQL凭借着出色的性能、低廉的成本、丰富的资源,已经成为绝大多数互联网公司的首选关系型数据库。虽然性能出色,但所谓“好马配好鞍”,如何能够更好的使用它,已经成为开发工程师的必修课,我们经常会从职位描述上看到诸如“精通MySQL”、“SQL语句优化”、“了解数据库原理”等要求。我们知道一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,所以查询语句的优化显然是重中之重。

本人从13年7月份起,一直在美团核心业务系统部做慢查询的优化工作,共计十余个系统,累计解决和积累了上百个慢查询案例。随着业务的复杂性提升,遇到的问题千奇百怪,五花八门,匪夷所思。本文旨在以开发工程师的角度来解释数据库索引的原理和如何优化慢查询。

一个慢查询引发的思考

1
2
3
4
5
6
7
8
9
10
select
   count(*)
from
   task
where
   status=2
   and operator_id=20839
   and operate_time>1371169729
   and operate_time<1371174603
   and type=2;

系统使用者反应有一个功能越来越慢,于是工程师找到了上面的SQL。

并且兴致冲冲的找到了我,“这个SQL需要优化,给我把每个字段都加上索引”

我很惊讶,问道“为什么需要每个字段都加上索引?”

“把查询的字段都加上索引会更快”工程师信心满满

“这种情况完全可以建一个联合索引,因为是最左前缀匹配,所以operate_time需要放到最后,而且还需要把其他相关的查询都拿来,需要做一个综合评估。”

“联合索引?最左前缀匹配?综合评估?”工程师不禁陷入了沉思。

多数情况下,我们知道索引能够提高查询效率,但应该如何建立索引?索引的顺序如何?许多人却只知道大概。其实理解这些概念并不难,而且索引的原理远没有想象的那么复杂。

MySQL索引原理

索引目的

索引的目的在于提高查询效率,可以类比字典,如果要查“mysql”这个单词,我们肯定需要定位到m字母,然后从下往下找到y字母,再找到剩下的sql。如果没有索引,那么你可能需要把所有单词看一遍才能找到你想要的,如果我想找到m开头的单词呢?或者ze开头的单词呢?是不是觉得如果没有索引,这个事情根本无法完成?

索引原理

除了词典,生活中随处可见索引的例子,如火车站的车次表、图书的目录等。它们的原理都是一样的,通过不断的缩小想要获得数据的范围来筛选出最终想要的结果,同时把随机的事件变成顺序的事件,也就是我们总是通过同一种查找方式来锁定数据。

数据库也是一样,但显然要复杂许多,因为不仅面临着等值查询,还有范围查询(>、<、between、in)、模糊查询(like)、并集查询(or)等等。数据库应该选择怎么样的方式来应对所有的问题呢?我们回想字典的例子,能不能把数据分成段,然后分段查询呢?最简单的如果1000条数据,1到100分成第一段,101到200分成第二段,201到300分成第三段……这样查第250条数据,只要找第三段就可以了,一下子去除了90%的无效数据。但如果是1千万的记录呢,分成几段比较好?稍有算法基础的同学会想到搜索树,其平均复杂度是lgN,具有不错的查询性能。但这里我们忽略了一个关键的问题,复杂度模型是基于每次相同的操作成本来考虑的,数据库实现比较复杂,数据保存在磁盘上,而为了提高性能,每次又可以把部分数据读入内存来计算,因为我们知道访问磁盘的成本大概是访问内存的十万倍左右,所以简单的搜索树难以满足复杂的应用场景。

磁盘IO与预读

前面提到了访问磁盘,那么这里先简单介绍一下磁盘IO和预读,磁盘读取数据靠的是机械运动,每次读取数据花费的时间可以分为寻道时间、旋转延迟、传输时间三个部分,寻道时间指的是磁臂移动到指定磁道所需要的时间,主流磁盘一般在5ms以下;旋转延迟就是我们经常听说的磁盘转速,比如一个磁盘7200转,表示每分钟能转7200次,也就是说1秒钟能转120次,旋转延迟就是1/120/2 = 4.17ms;传输时间指的是从磁盘读出或将数据写入磁盘的时间,一般在零点几毫秒,相对于前两个时间可以忽略不计。那么访问一次磁盘的时间,即一次磁盘IO的时间约等于5+4.17 = 9ms左右,听起来还挺不错的,但要知道一台500 -MIPS的机器每秒可以执行5亿条指令,因为指令依靠的是电的性质,换句话说执行一次IO的时间可以执行40万条指令,数据库动辄十万百万乃至千万级数据,每次9毫秒的时间,显然是个灾难。下图是计算机硬件延迟的对比图,供大家参考:

考虑到磁盘IO是非常高昂的操作,计算机操作系统做了一些优化,当一次IO时,不光把当前磁盘地址的数据,而是把相邻的数据也都读取到内存缓冲区内,因为局部预读性原理告诉我们,当计算机访问一个地址的数据的时候,与其相邻的数据也会很快被访问到。每一次IO读取的数据我们称之为一页(page)。具体一页有多大数据跟操作系统有关,一般为4k或8k,也就是我们读取一页内的数据时候,实际上才发生了一次IO,这个理论对于索引的数据结构设计非常有帮助。

索引的数据结构

前面讲了生活中索引的例子,索引的基本原理,数据库的复杂性,又讲了操作系统的相关知识,目的就是让大家了解,任何一种数据结构都不是凭空产生的,一定会有它的背景和使用场景,我们现在总结一下,我们需要这种数据结构能够做些什么,其实很简单,那就是:每次查找数据时把磁盘IO次数控制在一个很小的数量级,最好是常数数量级。那么我们就想到如果一个高度可控的多路搜索树是否能满足需求呢?就这样,b+树应运而生。

详解b+树

如上图,是一颗b+树,关于b+树的定义可以参见B+树,这里只说一些重点,浅蓝色的块我们称之为一个磁盘块,可以看到每个磁盘块包含几个数据项(深蓝色所示)和指针(黄色所示),如磁盘块1包含数据项17和35,包含指针P1、P2、P3,P1表示小于17的磁盘块,P2表示在17和35之间的磁盘块,P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶子节点只不存储真实的数据,只存储指引搜索方向的数据项,如17、35并不真实存在于数据表中。

b+树的查找过程

如图所示,如果要查找数据项29,那么首先会把磁盘块1由磁盘加载到内存,此时发生一次IO,在内存中用二分查找确定29在17和35之间,锁定磁盘块1的P2指针,内存时间因为非常短(相比磁盘的IO)可以忽略不计,通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存,发生第二次IO,29在26和30之间,锁定磁盘块3的P2指针,通过指针加载磁盘块8到内存,发生第三次IO,同时内存中做二分查找找到29,结束查询,总计三次IO。真实的情况是,3层的b+树可以表示上百万的数据,如果上百万的数据查找只需要三次IO,性能提高将是巨大的,如果没有索引,每个数据项都要发生一次IO,那么总共需要百万次的IO,显然成本非常非常高。

b+树性质

1.通过上面的分析,我们知道IO次数取决于b+数的高度h,假设当前数据表的数据为N,每个磁盘块的数据项的数量是m,则有h=㏒(m+1)N,当数据量N一定的情况下,m越大,h越小;而m = 磁盘块的大小 / 数据项的大小,磁盘块的大小也就是一个数据页的大小,是固定的,如果数据项占的空间越小,数据项的数量越多,树的高度越低。这就是为什么每个数据项,即索引字段要尽量的小,比如int占4字节,要比bigint8字节少一半。这也是为什么b+树要求把真实的数据放到叶子节点而不是内层节点,一旦放到内层节点,磁盘块的数据项会大幅度下降,导致树增高。当数据项等于1时将会退化成线性表。

2.当b+树的数据项是复合的数据结构,比如(name,age,sex)的时候,b+数是按照从左到右的顺序来建立搜索树的,比如当(张三,20,F)这样的数据来检索的时候,b+树会优先比较name来确定下一步的所搜方向,如果name相同再依次比较age和sex,最后得到检索的数据;但当(20,F)这样的没有name的数据来的时候,b+树就不知道下一步该查哪个节点,因为建立搜索树的时候name就是第一个比较因子,必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时,b+树可以用name来指定搜索方向,但下一个字段age的缺失,所以只能把名字等于张三的数据都找到,然后再匹配性别是F的数据了, 这个是非常重要的性质,即索引的最左匹配特性。

慢查询优化

关于MySQL索引原理是比较枯燥的东西,大家只需要有一个感性的认识,并不需要理解得非常透彻和深入。我们回头来看看一开始我们说的慢查询,了解完索引原理之后,大家是不是有什么想法呢?先总结一下索引的几大基本原则

建索引的几大原则

1.最左前缀匹配原则,非常重要的原则,mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配,比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引,d是用不到索引的,如果建立(a,b,d,c)的索引则都可以用到,a,b,d的顺序可以任意调整。

2.=和in可以乱序,比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序,mysql的查询优化器会帮你优化成索引可以识别的形式

3.尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*),表示字段不重复的比例,比例越大我们扫描的记录数越少,唯一键的区分度是1,而一些状态、性别字段可能在大数据面前区分度就是0,那可能有人会问,这个比例有什么经验值吗?使用场景不同,这个值也很难确定,一般需要join的字段我们都要求是0.1以上,即平均1条扫描10条记录

4.索引列不能参与计算,保持列“干净”,比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引,原因很简单,b+树中存的都是数据表中的字段值,但进行检索时,需要把所有元素都应用函数才能比较,显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);

5.尽量的扩展索引,不要新建索引。比如表中已经有a的索引,现在要加(a,b)的索引,那么只需要修改原来的索引即可

回到开始的慢查询

根据最左匹配原则,最开始的sql语句的索引应该是status、operator_id、type、operate_time的联合索引;其中status、operator_id、type的顺序可以颠倒,所以我才会说,把这个表的所有相关查询都找到,会综合分析;
比如还有如下查询

1
2
select * from task where status = 0 and type = 12 limit 10;
select count(*) from task where status = 0 ;

那么索引建立成(status,type,operator_id,operate_time)就是非常正确的,因为可以覆盖到所有情况。这个就是利用了索引的最左匹配的原则

查询优化神器 – explain命令

关于explain命令相信大家并不陌生,具体用法和字段含义可以参考官网explain-output,这里需要强调rows是核心指标,绝大部分rows小的语句执行一定很快(有例外,下面会讲到)。所以优化语句基本上都是在优化rows。

慢查询优化基本步骤

0.先运行看看是否真的很慢,注意设置SQL_NO_CACHE
1.where条件单表查,锁定最小返回记录表。这句话的意思是把查询语句的where都应用到表中返回的记录数最小的表开始查起,单表每个字段分别查询,看哪个字段的区分度最高
2.explain查看执行计划,是否与1预期一致(从锁定记录较少的表开始查询)
3.order by limit 形式的sql语句让排序的表优先查
4.了解业务方使用场景
5.加索引时参照建索引的几大原则
6.观察结果,不符合预期继续从0分析

几个慢查询案例

下面几个例子详细解释了如何分析和优化慢查询

复杂语句写法

很多情况下,我们写SQL只是为了实现功能,这只是第一步,不同的语句书写方式对于效率往往有本质的差别,这要求我们对mysql的执行计划和索引原则有非常清楚的认识,请看下面的语句

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
select
   distinct cert.emp_id
from
   cm_log cl
inner join
   (
      select
         emp.id as emp_id,
         emp_cert.id as cert_id
      from
         employee emp
      left join
         emp_certificate emp_cert
            on emp.id = emp_cert.emp_id
      where
         emp.is_deleted=0
   ) cert
      on (
         cl.ref_table='Employee'
         and cl.ref_oid= cert.emp_id
      )
      or (
         cl.ref_table='EmpCertificate'
         and cl.ref_oid= cert.cert_id
      )
where
   cl.last_upd_date >='2013-11-07 15:03:00'
   and cl.last_upd_date<='2013-11-08 16:00:00';

0.先运行一下,53条记录 1.87秒,又没有用聚合语句,比较慢

1
53 rows in set (1.87 sec)

1.explain

1
2
3
4
5
6
7
8
+----+-------------+------------+-------+---------------------------------+-----------------------+---------+-------------------+-------+--------------------------------+
| id | select_type | table      | type  | possible_keys                   | key                   | key_len | ref               | rows  | Extra                          |
+----+-------------+------------+-------+---------------------------------+-----------------------+---------+-------------------+-------+--------------------------------+
1 | PRIMARY     | cl         | range | cm_log_cls_id,idx_last_upd_date | idx_last_upd_date     | 8       | NULL              |   379 | Using where; Using temporary   |
1 | PRIMARY     | <derived2> | ALL   | NULL                            | NULL                  | NULL    | NULL              | 63727 | Using where; Using join buffer |
2 | DERIVED     | emp        | ALL   | NULL                            | NULL                  | NULL    | NULL              | 13317 | Using where                    |
2 | DERIVED     | emp_cert   | ref   | emp_certificate_empid           | emp_certificate_empid | 4       | meituanorg.emp.id |     1 | Using index                    |
+----+-------------+------------+-------+---------------------------------+-----------------------+---------+-------------------+-------+--------------------------------+

简述一下执行计划,首先mysql根据idx_last_upd_date索引扫描cm_log表获得379条记录;然后查表扫描了63727条记录,分为两部分,derived表示构造表,也就是不存在的表,可以简单理解成是一个语句形成的结果集,后面的数字表示语句的ID。derived2表示的是ID = 2的查询构造了虚拟表,并且返回了63727条记录。我们再来看看ID = 2的语句究竟做了写什么返回了这么大量的数据,首先全表扫描employee表13317条记录,然后根据索引emp_certificate_empid关联emp_certificate表,rows = 1表示,每个关联都只锁定了一条记录,效率比较高。获得后,再和cm_log的379条记录根据规则关联。从执行过程上可以看出返回了太多的数据,返回的数据绝大部分cm_log都用不到,因为cm_log只锁定了379条记录。

如何优化呢?可以看到我们在运行完后还是要和cm_log做join,那么我们能不能之前和cm_log做join呢?仔细分析语句不难发现,其基本思想是如果cm_log的ref_table是EmpCertificate就关联emp_certificate表,如果ref_table是Employee就关联employee表,我们完全可以拆成两部分,并用union连接起来,注意这里用union,而不用union all是因为原语句有“distinct”来得到唯一的记录,而union恰好具备了这种功能。如果原语句中没有distinct不需要去重,我们就可以直接使用union all了,因为使用union需要去重的动作,会影响SQL性能。
优化过的语句如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
select
   emp.id
from
   cm_log cl
inner join
   employee emp
      on cl.ref_table = 'Employee'
      and cl.ref_oid = emp.id 
where
   cl.last_upd_date >='2013-11-07 15:03:00'
   and cl.last_upd_date<='2013-11-08 16:00:00'
   and emp.is_deleted = 0 
union
select
   emp.id
from
   cm_log cl
inner join
   emp_certificate ec
      on cl.ref_table = 'EmpCertificate'
      and cl.ref_oid = ec.id 
inner join
   employee emp
      on emp.id = ec.emp_id 
where
   cl.last_upd_date >='2013-11-07 15:03:00'
   and cl.last_upd_date<='2013-11-08 16:00:00'
   and emp.is_deleted = 0

4.不需要了解业务场景,只需要改造的语句和改造之前的语句保持结果一致

5.现有索引可以满足,不需要建索引

6.用改造后的语句实验一下,只需要10ms 降低了近200倍!

1
2
3
4
5
6
7
8
9
10
+----+--------------+------------+--------+---------------------------------+-------------------+---------+-----------------------+------+-------------+
| id | select_type  | table      | type   | possible_keys                   | key               | key_len | ref                   | rows | Extra       |
+----+--------------+------------+--------+---------------------------------+-------------------+---------+-----------------------+------+-------------+
1 | PRIMARY      | cl         | range  | cm_log_cls_id,idx_last_upd_date | idx_last_upd_date | 8       | NULL                  |  379 | Using where |
1 | PRIMARY      | emp        | eq_ref | PRIMARY                         | PRIMARY           | 4       | meituanorg.cl.ref_oid |    1 | Using where |
2 | UNION        | cl         | range  | cm_log_cls_id,idx_last_upd_date | idx_last_upd_date | 8       | NULL                  |  379 | Using where |
2 | UNION        | ec         | eq_ref | PRIMARY,emp_certificate_empid   | PRIMARY           | 4       | meituanorg.cl.ref_oid |    1 |             |
2 | UNION        | emp        | eq_ref | PRIMARY                         | PRIMARY           | 4       | meituanorg.ec.emp_id  |    1 | Using where |
| NULL | UNION RESULT | <union1,2> | ALL    | NULL                            | NULL              | NULL    | NULL                  | NULL |             |
+----+--------------+------------+--------+---------------------------------+-------------------+---------+-----------------------+------+-------------+

明确应用场景

举这个例子的目的在于颠覆我们对列的区分度的认知,一般上我们认为区分度越高的列,越容易锁定更少的记录,但在一些特殊的情况下,这种理论是有局限性的

1
2
3
4
5
6
7
8
9
10
11
select
   *
from
   stage_poi sp
where
   sp.accurate_result=1
   and (
      sp.sync_status=0
      or sp.sync_status=2
      or sp.sync_status=4
   );

0.先看看运行多长时间,951条数据6.22秒,真的很慢

1
951 rows in set (6.22 sec)

1.先explain,rows达到了361万,type = ALL表明是全表扫描

1
2
3
4
5
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows    | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+
1 | SIMPLE      | sp    | ALL  | NULL          | NULL | NULL    | NULL | 3613155 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+

2.所有字段都应用查询返回记录数,因为是单表查询 0已经做过了951条

3.让explain的rows 尽量逼近951

看一下accurate_result = 1的记录数

1
2
3
4
5
6
7
8
select count(*),accurate_result from stage_poi  group by accurate_result;
+----------+-----------------+
| count(*) | accurate_result |
+----------+-----------------+
|     1023 |              -1 |
2114655 |               0 |
|   972815 |               1 |
+----------+-----------------+

我们看到accurate_result这个字段的区分度非常低,整个表只有-1,0,1三个值,加上索引也无法锁定特别少量的数据

再看一下sync_status字段的情况

1
2
3
4
5
6
7
select count(*),sync_status from stage_poi  group by sync_status;
+----------+-------------+
| count(*) | sync_status |
+----------+-------------+
|     3080 |           0 |
3085413 |           3 |
+----------+-------------+

同样的区分度也很低,根据理论,也不适合建立索引

问题分析到这,好像得出了这个表无法优化的结论,两个列的区分度都很低,即便加上索引也只能适应这种情况,很难做普遍性的优化,比如当sync_status 0、3分布的很平均,那么锁定记录也是百万级别的

4.找业务方去沟通,看看使用场景。业务方是这么来使用这个SQL语句的,每隔五分钟会扫描符合条件的数据,处理完成后把sync_status这个字段变成1,五分钟符合条件的记录数并不会太多,1000个左右。了解了业务方的使用场景后,优化这个SQL就变得简单了,因为业务方保证了数据的不平衡,如果加上索引可以过滤掉绝大部分不需要的数据

5.根据建立索引规则,使用如下语句建立索引

1
alter table stage_poi add index idx_acc_status(accurate_result,sync_status);

6.观察预期结果,发现只需要200ms,快了30多倍。

1
952 rows in set (0.20 sec)

我们再来回顾一下分析问题的过程,单表查询相对来说比较好优化,大部分时候只需要把where条件里面的字段依照规则加上索引就好,如果只是这种“无脑”优化的话,显然一些区分度非常低的列,不应该加索引的列也会被加上索引,这样会对插入、更新性能造成严重的影响,同时也有可能影响其它的查询语句。所以我们第4步调差SQL的使用场景非常关键,我们只有知道这个业务场景,才能更好地辅助我们更好的分析和优化查询语句。

无法优化的语句

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
select
   c.id,
   c.name,
   c.position,
   c.sex,
   c.phone,
   c.office_phone,
   c.feature_info,
   c.birthday,
   c.creator_id,
   c.is_keyperson,
   c.giveup_reason,
   c.status,
   c.data_source,
   from_unixtime(c.created_time) as created_time,
   from_unixtime(c.last_modified) as last_modified,
   c.last_modified_user_id 
from
   contact c 
inner join
   contact_branch cb
      on  c.id = cb.contact_id 
inner join
   branch_user bu
      on  cb.branch_id = bu.branch_id
      and bu.status in (
         1,
      2) 
   inner join
      org_emp_info oei
         on  oei.data_id = bu.user_id
         and oei.node_left >= 2875
         and oei.node_right <= 10802
         and oei.org_category = - 1 
   order by
      c.created_time desc  limit 0 ,
      10;

还是几个步骤

0.先看语句运行多长时间,10条记录用了13秒,已经不可忍受

1
10 rows in set (13.06 sec)

1.explain

1
2
3
4
5
6
7
8
+----+-------------+-------+--------+-------------------------------------+-------------------------+---------+--------------------------+------+----------------------------------------------+
| id | select_type | table | type   | possible_keys                       | key                     | key_len | ref                      | rows | Extra                                        |
+----+-------------+-------+--------+-------------------------------------+-------------------------+---------+--------------------------+------+----------------------------------------------+
1 | SIMPLE      | oei   | ref    | idx_category_left_right,idx_data_id | idx_category_left_right | 5       | const                    | 8849 | Using where; Using temporary; Using filesort |
1 | SIMPLE      | bu    | ref    | PRIMARY,idx_userid_status           | idx_userid_status       | 4       | meituancrm.oei.data_id   |   76 | Using where; Using index                     |
1 | SIMPLE      | cb    | ref    | idx_branch_id,idx_contact_branch_id | idx_branch_id           | 4       | meituancrm.bu.branch_id  |    1 |                                              |
1 | SIMPLE      | c     | eq_ref | PRIMARY                             | PRIMARY                 | 108     | meituancrm.cb.contact_id |    1 |                                              |
+----+-------------+-------+--------+-------------------------------------+-------------------------+---------+--------------------------+------+----------------------------------------------+

从执行计划上看,mysql先查org_emp_info表扫描8849记录,再用索引idx_userid_status关联branch_user表,再用索引idx_branch_id关联contact_branch表,最后主键关联contact表。

rows返回的都非常少,看不到有什么异常情况。我们在看一下语句,发现后面有order by + limit组合,会不会是排序量太大搞的?于是我们简化SQL,去掉后面的order by 和 limit,看看到底用了多少记录来排序

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
select
  count(*)
from
   contact c 
inner join
   contact_branch cb
      on  c.id = cb.contact_id 
inner join
   branch_user bu
      on  cb.branch_id = bu.branch_id
      and bu.status in (
         1,
      2) 
   inner join
      org_emp_info oei
         on  oei.data_id = bu.user_id
         and oei.node_left >= 2875
         and oei.node_right <= 10802
         and oei.org_category = - 1 
+----------+
| count(*) |
+----------+
|   778878 |
+----------+
1 row in set (5.19 sec)

发现排序之前居然锁定了778878条记录,如果针对70万的结果集排序,将是灾难性的,怪不得这么慢,那我们能不能换个思路,先根据contact的created_time排序,再来join会不会比较快呢?

于是改造成下面的语句,也可以用straight_join来优化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
select
c.id,
c.name,
c.position,
c.sex,
c.phone,
c.office_phone,
c.feature_info,
c.birthday,
c.creator_id,
c.is_keyperson,
c.giveup_reason,
c.status,
c.data_source,
from_unixtime(c.created_time) as created_time,
from_unixtime(c.last_modified) as last_modified,
c.last_modified_user_id
from
contact c
where
exists (
select
1
from
contact_branch cb
inner join
branch_user bu
on cb.branch_id = bu.branch_id
and bu.status in (
1,
2)
inner join
org_emp_info oei
on oei.data_id = bu.user_id
and oei.node_left >= 2875
and oei.node_right <= 10802
and oei.org_category = - 1
where
c.id = cb.contact_id
)
order by
c.created_time desc limit 0 ,
10;

验证一下效果 预计在1ms内,提升了13000多倍!

1
10 rows in set (0.00 sec)

本以为至此大工告成,但我们在前面的分析中漏了一个细节,先排序再join和先join再排序理论上开销是一样的,为何提升这么多是因为有一个limit!大致执行过程是:mysql先按索引排序得到前10条记录,然后再去join过滤,当发现不够10条的时候,再次去10条,再次join,这显然在内层join过滤的数据非常多的时候,将是灾难的,极端情况,内层一条数据都找不到,mysql还傻乎乎的每次取10条,几乎遍历了这个数据表!

用不同参数的SQL试验下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
select
   sql_no_cache   c.id,
   c.name,
   c.position,
   c.sex,
   c.phone,
   c.office_phone,
   c.feature_info,
   c.birthday,
   c.creator_id,
   c.is_keyperson,
   c.giveup_reason,
   c.status,
   c.data_source,
   from_unixtime(c.created_time) as created_time,
   from_unixtime(c.last_modified) as last_modified,
   c.last_modified_user_id   
from
   contact c  
where
   exists (
      select
         1       
      from
         contact_branch cb        
      inner join
         branch_user bu                    
            on  cb.branch_id = bu.branch_id                    
            and bu.status in (
               1,
            2)               
         inner join
            org_emp_info oei                          
               on  oei.data_id = bu.user_id                          
               and oei.node_left >= 2875                          
               and oei.node_right <= 2875                          
               and oei.org_category = - 1               
         where
            c.id = cb.contact_id          
      )       
   order by
      c.created_time desc  limit 0 ,
      10;
Empty set (2 min 18.99 sec)

2 min 18.99 sec!比之前的情况还糟糕很多。由于mysql的nested loop机制,遇到这种情况,基本是无法优化的。这条语句最终也只能交给应用系统去优化自己的逻辑了。

通过这个例子我们可以看到,并不是所有语句都能优化,而往往我们优化时,由于SQL用例回归时落掉一些极端情况,会造成比原来还严重的后果。所以,第一:不要指望所有语句都能通过SQL优化,第二:不要过于自信,只针对具体case来优化,而忽略了更复杂的情况。

慢查询的案例就分析到这儿,以上只是一些比较典型的案例。我们在优化过程中遇到过超过1000行,涉及到16个表join的“垃圾SQL”,也遇到过线上线下数据库差异导致应用直接被慢查询拖死,也遇到过varchar等值比较没有写单引号,还遇到过笛卡尔积查询直接把从库搞死。再多的案例其实也只是一些经验的积累,如果我们熟悉查询优化器、索引的内部原理,那么分析这些案例就变得特别简单了。

写在后面的话

本文以一个慢查询案例引入了MySQL索引原理、优化慢查询的一些方法论;并针对遇到的典型案例做了详细的分析。其实做了这么长时间的语句优化后才发现,任何数据库层面的优化都抵不上应用系统的优化,同样是MySQL,可以用来支撑Google/FaceBook/Taobao应用,但可能连你的个人网站都撑不住。套用最近比较流行的话:“查询容易,优化不易,且写且珍惜!”

参考

参考文献如下:

1.《高性能MySQL》
2.《数据结构与算法分析》