InnoDB行锁的实现分析

2 月 11th, 2010 | Posted by P.Linux | Filed under 未分类

本文内容遵从CC版权协议, 可以随意转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.penglixun.com/database/innodb_next_key_locking.html

感谢Fenng的提醒，已删除锁粒度和死锁的关系，专门撰文写了锁的粒度与死锁的关系。

InnoDB与MyISAM不同，它实现的是一个行级锁，而非MyISAM的表锁。锁的粒度越大，则~~发生死锁的概率越小、~~锁机制开销越小，但并发能力会越低。如果锁的粒度变细，则~~发生死锁的概率也会增大，~~锁机制的开销会更大，但是并发能力能提高。表锁是如何实现的呢，以MyISAM为例，是在每个表的结构中加入一个互斥变量记录锁状态，像：
struct Table {
Row rows[MAXROWS];
pthread_mutex_t lock;//表锁
};
这样做的好处就是锁非常简单，当操作表的时候，直接锁住整个表就行，锁机制的开销非常小。但是问题也很明显，并发量上不去，因为无论多小的操作，都必须锁整个表，这可能带来其他操作的阻塞。
行锁又是如何实现的呢，Oracle是直接在每个行的block上做标记，而InnoDB则是靠索引来做。InnoDB的主键索引跟一般的索引不太一样，Key后面还跟上了整行的数据，互斥变量也是加载主键索引上的，像
struct PK_Idx {
Row row;
pthread_mutex_t lock;//行锁
};
multimap pk_idx;
这样的形式。
这样做的好处是锁的粒度小，只锁住需要的数据不被更改，但是问题也很明显，锁的开销很大，每个主键索引上都要加上一个标记，~~因为锁的粒度很小~~，可能两个不同的操作各锁住一部分行等待对方释放形成死锁，不过这个是有办法解决的，把上锁的操作封装成原子操作就行，不过并发量会受些影响。

下面是类似InnoDB的Next-Key locking算法的演示:
编译需要加-lpthread参数，例如g++ inno.cpp -lpthread -o inno

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define LOCK pthread_mutex_lock(&lock)
#define UNLOCK pthread_mutex_unlock(&lock)
#define PRINT(STR, ...) LOCK;fprintf(stderr, STR,  __VA_ARGS__);UNLOCK

#define MAXROWS 100

using namespace std;

/* 行结构 */
struct Row {
    int     num;
    string  info;
};

/* 主键索引结构 */
struct PK_Idx {
    Row     row;
    pthread_mutex_t lock;//行锁
};

/* 表结构 */
struct Table {
    multimap pk_idx;
    multimap      num_idx;
    multimap   info_idx;
    Row     rows[MAXROWS];
    pthread_mutex_t lock;//表锁
};

Table table;
int pid;
//全局锁
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

/* 随机字符 */
char randChar() {
    return rand()%26+'A';
}
 
/* 随机字符串 */
void randString(string &col, int len) {
    col = "";
    for(int i=0; i(i, pk));
        table.num_idx.insert(pair(pk.row.num, i));
        table.info_idx.insert(pair(pk.row.info, i));
    }
    //初始化表锁
    table.lock = PTHREAD_MUTEX_INITIALIZER;
}

/*获取范围数据*/
void select_num(int begin, int end) {
    int id;
    int cur_pid;
    multimap::iterator it, itlow, itup;
    PK_Idx *pk;
    /* 按字段范围查找ID */
    itlow = table.num_idx.lower_bound (begin);
    itup = table.num_idx.upper_bound (end);

    LOCK;
    cur_pid = pid++;
    UNLOCK;
    PRINT("%d : * Start Select:%d,%d *\n", cur_pid, begin, end);
    for (it=itlow; it!=itup; ++it) {
        id = it->second;
        pk = &(table.pk_idx.find(id)->second);//根据ID去查主键索引
        pthread_mutex_lock(&(pk->lock));//在主键索引上加锁
        PRINT("%d : LOCK Row %d: %d\t%s\n", cur_pid, id, pk->row.num, pk->row.info.c_str());
        Sleep(500);
    }
    for (it=itlow; it!=itup; ++it) {
        id = it->second;
        pk = &(table.pk_idx.find(id)->second);
        PRINT("%d : UNLOCK Row %d\n", cur_pid, id);
        pthread_mutex_unlock(&(pk->lock));//使用完毕依次释放锁
    }
    PRINT("%d : * Select Finished! *\n", cur_pid);
}

/*修改范围数据*/
void update_num(int begin, int end) {
    int id;
    int cur_pid;
    multimap::iterator it, itlow, itup;
    PK_Idx *pk;
    
    itlow = table.num_idx.lower_bound (begin);
    itup = table.num_idx.upper_bound (end);
    
    LOCK;
    cur_pid = pid++;
    UNLOCK;
    PRINT("%d : * Start Update:%d,%d *\n", cur_pid, begin, end);
    for (it=itlow; it!=itup; ++it) {
        id = it->second;
        pk = &(table.pk_idx.find(id)->second);
        pthread_mutex_lock(&(pk->lock));
        PRINT("%d : LOCK Row %d: %d\t%s\n", cur_pid, id, pk->row.num, pk->row.info.c_str());
        Sleep(500);
    }
    for (it=itlow; it!=itup; ++it) {
        id = it->second;
        pk = &(table.pk_idx.find(id)->second);
        PRINT("%d : UNLOCK Row %d\n", cur_pid, id);
        pthread_mutex_unlock(&(pk->lock));
    }
    PRINT("%d : * Update Finished! *\n", cur_pid);
}


void* test_select(void *) {
    int begin, end;
    srand((unsigned)time(0));
    while(1) {
        begin = rand()%(MAXROWS/2);
        end = begin+rand()%(MAXROWS/2);
        select_num(begin, end);
        Sleep(500);
    }
}

void* test_update(void *) {
    int begin, end;
    srand((unsigned)time(0));
    while(1) {
        begin = rand()%(MAXROWS/5);
        end = begin+rand()%(MAXROWS/5);
        update_num(begin, end);
        Sleep(500);
    }
}

void test() {
    pthread_t id[2];
    if(pthread_create(&id[0], NULL, test_select, NULL) != 0)
    {
        PRINT("%s", "Create Thread Error!\n");
    }
    
    if(pthread_create(&id[1], NULL, test_update, NULL) != 0)
    {
        PRINT("%s", "Create Thread Error!\n");
    }
    
    while(1){
		Sleep(500);
	}
}

int main() {
    init();
    test();
    return 0;
}

标签: 数据库, InnoDB, MySQL, 行锁, 锁机制

类似的文章

未来10年之规划每周推特 2010-02-07

Fenng
2 月 12th, 201016:17

回复 | 引用 | #1

“锁的粒度越大，则发生死锁的概率越小”

应该是粒度越大，死锁概率越大

[回复]
P.Linux 回复:
12 2 月, 2010 at 23:19
@Fenng, 已经明白了，我一直想错了，详细了复习了下操作系统的锁机制原理，将专门撰文说明锁粒度和死锁概率的问题。感谢Fenng~

[回复]
MySQL索引与存储方式对性能的影响 | P.Linux Laboratory
3 月 20th, 201017:27

#2
duxing
10 月 20th, 201019:21

回复 | 引用 | #3

应该是锁的粒度越大并发处理不好
但是锁的粒度越大的话应该是出现死锁概率会变小

锁的粒度越小，并发处理较好
但是出现死锁的概率会变大

[回复]
lajabs
7 月 12th, 201119:29

回复 | 引用 | #4

这个在多线程开发里面比较常见，锁的粒度大，并发肯定受阻碍；
锁的粒度小，并发操作越多，从这个角度说死锁的概率必然会增加。

所以我认为死锁和锁的粒度没有直接关系，谈造成死锁没有意义，而造成死锁只是和并发有关。

[回复]
[转载]InnoDB行锁的实现分析 – 数据库 – 开发者
6 月 18th, 201310:48

#5

P.Linux Laboratory

InnoDB行锁的实现分析

类似的文章

订阅统计

分类目录

标签云

近期评论

友情链接

我的网站