InnoDB一点零散的知识点

外键不加索引会引起死锁的问题

情景

主表parent主键id，字表child主键cid，cid为parent外键，和parent中id来源一致
当对parent或者child进行删除操作时，如果外键没有索引，数据库就会将行锁升级为表锁，从而可能导致大量的等待和死锁
大多数数据库现在致力于解决这个问题，但也只是降低了这种情况下死锁的风险，并没有完全消除

解决

外键加上索引就可以了，事实表明，这种方式最有效

InnoDB聚集索引和辅助索引（二级索引）

1.InnoDB采用B+树实现索引，默认会在每个表的主键加上聚集索引，这种索引中，数据物理上不是连续存放（我们的教程有误解），但逻辑上是连续的。
2.InnoDB聚集索引中，B+的深度一般在2到3层，叶子节点会存放数据的所有值（完全行数据）
3.辅助索引仅会在B+树叶子节点存放当前列的值和主键的索引键，通过这个找到聚集索引中改行数据
4.聚集索引中每个叶子节点是物理上一页（InnoDB最小的物理存储单位）的数据，找到这个页之后，根绝这个页的 page directory二分找到所需要的数据（InnoDB聚集索引是按照主键有序存放数据的）

InnoDB联合索引

    联合索引实际上是对创建索引的这几列做排序，使用联合索引的时候，先根据第一个索引去找，找到再根据第二个索引去找，依次下去，这样的查找逻辑，可以保证按照顺序查找
    如果不是这样的顺序，InnoDB优化器可能就不会使用联合索引，这就是所谓的联合索引的最左原则。因为如果从第二列或者第三列开始的话，可能就不会是有序的。
例子是这样的（网上找的例子，意思是一样的）
    假设数据 表T (a,b,c) rowid 为物理位置
rowid a b c
(1) 1 1 1
(2) 2 1 13
(3) 2 2 14
(4) 1 3 3
(5) 2 3 12
(6) 1 2 5
(7) 2 3 9
(8) 1 2 2
(9) 1 3 6
(10) 2 2 11
(11) 2 2 8
(12) 1 1 7
(13) 2 3 15
(14) 1 1 4
(15) 2 1 10


当你创建一个索引 create index xxx on t(a,b), 则索引文件逻辑上等同于如下
a b rowid
1 1 1
1 1 12
1 1 14
1 2 6
1 2 8
1 3 4
1 3 9
2 1 2
2 1 15
2 2 3
2 2 10
2 2 11
2 3 5
2 3 7
2 3 13
再根据上边的查找逻辑去看看这个索引，是不是就一目了然呢