决战圣地玛丽乔亚Day18----关于mysql死锁+ mysql索引的数据结构相关

Mysql为什么会产生死锁？

 事务A、B分别拿到1,4的独占行锁，然后再去拿4，1的行锁，都会由于另一个事务不释放锁等待，造成了循环等待的局面。

• (1)同一时刻只能有一个事务持有这把锁;

• (2）其他的事务需要在这个事务释放锁之后才能获取锁，而不可以强行剥夺;

• (3）当多个事务形成等待环路的时候，即发生死锁。

 

如何去检测死锁？

show status命令查看行锁相关参数

show status like 'innodb_row_lock_%';

lnnodb_row_lock_current_waits:当前正在等待锁定的数量;
lnnodb_row_lock_time :从系统启动到现在锁定的总时间长度，单位ms;
Innodb_row_lock_time_avg :每次等待所花平均时间;
Innodb_row_lock_time_max:从系统启动到现在等待最长的一次所花的时间;
lnnodb_row_lock_waits :从系统启动到现在总共等待的次数。

show status只是来看一下大概的情况，具体情况还需要用到Innodb提供的三张表

具体的处理：

通过这三条命令看锁和事务的关系

select * from information_schema.INNODB_TRX; --当前运行的所有事务﹐还有具体的语句
select* from information_schema.INNODB_LOCKS; --当前出现的锁
select * from information_schema.INNODB_LOCK_WAITS; --锁等待的对应关系

kill掉事务的线程id     INNODB_TRX表中的trx_mysql_thread_id

但是kill需要手动，我们不可能每次都自己去kill掉死锁问题，还是应该从代码层出发，尽量不让死锁发生。

• 1、在程序中，操作多张表时，尽量以相同的顺序来访问（避免形成等待环路)

• 2、批量操作单张表数据的时候，先对数据进行排序(避免形成等待环路);

• 3、申请足够级别的锁，如果要操作数据，就申请排它锁;

• 4、尽量使用索引访问数据，避免没有where条件的操作，避免锁表;

• 5、如果可以，大事务化成小事务;

• 6、使用等值查询而不是范围查询查询数据，命中记录，避免间隙锁对并发的影响。

 

 

Mysql索引的数据结构：

Hash:

myisam和innodb都不支持hash索引。

hash索引是基于hash表来实现，那么就是两次查询，第一次根据hash值找到hash表对应的位置，然后根据位置上的值找到数据。

只有查询条件在精确匹配hash表的所有值得时候，才用到hash索引。  hash索引包括一个hash码，键值和指针。

既然是hash表的形式，那么hash的缺点也就很明显：
1.二次查找的性能消耗。

2.hash值碰撞问题，如果冲突，那么找到新位置的性能消耗很大。

3.hash索引没有办法外排序，因为他存的不是实际的数据值，而是hash码

4.最重要的一点！hash不支持范围索引，只有在等值索引才能派上用场。

 

B+树和B树：

B树：

 

 B+树:

 

 不难看出B树键和值放在每个节点。 B+树的内部节点只存储键，在叶子节点存键值并且用链表串起来。

B+树和Hash的优缺点：

Hash由于通过hash函数去hash表获取相应键值，然后再回表查询对应的值得特性。

1.由于hash索引建立的无序，所以不能范围查找，只能等值查找。

2.必须要回表，B+树在覆盖索引和聚簇索引可以不回表。

3.虽然hash等值查找快，但是由于hash碰撞会带来不确定性，不推荐用hash

 

B+树和B树：

B树由于内部存放键和值，如果把热点数据放在接近根节点的位置，查询效率更高。所以B+树在特定数据重复多次查询场景更高效。

B+树由于叶子节点存值，内部节点只存键。因此内存页可以存更多的键，对于数据量高的情况下，B+树更有优势。

1.B树不支持顺序索引，B+树支持

2.相同IO次数，B+树空间利用率高，读写的代价更低

3.B树的查询效率不稳定，由于不确定关键字在树的哪个位置，相当于不断做二分查找，最快一次，最慢就不知道了。

   B+树的查询效率很稳定，因为每个数据的查询至少都要走到叶子节点。

4.B树没有解决遍历的问题，B+树通过把叶子节点链表存储解决。

5.增删效率方面，B+树由于可以顺序查找，效率一定是更高的。

 

 

聚簇索引和非聚簇索引：

聚簇索引：将数据存储与索引放到了一块，找到索引也就找到了数据

非聚簇索引：

 

Full-text：