orczhou.com

在机器学习中大量的使用NumPy作为其基础的数据结构，ndarray是NumPy的核心数据对象。对于ndarray高维数组的一个非常容易产生的误解是，使用数学中的矩阵（或者叫“行列式”）概念去尝试理解更高维的场景，或者使用更高维空间去理解，这样都会导致难以较好的理解更高维（5或6维）的数组。本文使用较为直观的示例和可视化的展示，更为“标准”（文档推荐的）的方式去理解ndarray的更高维数组。更多详细内容，可以参考阅读：

• numpy.ndarray
• NumPy: the absolute basics for beginners

问题

>>> import numpy as np
>>> np.array([[[1],[2]],[[3],[4]]]).shape
(考虑输出是什么)

要回答这个问题，则需要建立对于多维数组结构的理解。

文档中对于高维数组理解的建议

在NumPy: the absolute basics for beginners中有如下一段话：

It is familiar practice in mathematics to refer to elements of a matrix by the row index first and the column index second. This happens to be true for two-dimensional arrays, but a better mental model is to think of the column index as coming last and the row index as second to last. This generalizes to arrays with any number of dimensions.

“矩阵”是“线性代数”的主要研究对象，一个\( m \times n \)的矩阵即是一个平面上的\( m \)行\( m \)列的行列式。一种常见的向高维扩展的思考方式是，会将三维数组扩展为三维空间中的数组。但，这样的扩展，非常不利于去理解更高维的数组。这里提到的方案是这样：“a better mental model is to think of the column index as coming last and the row index as second to last.”。

这种理解，也是本文的核心，概况如下：

• 总是将最后一个维度理解为列维度
• 总是将倒数第二个维度理解为行维度
• 剩余的维度，则是通过层的方式去构建

从 4×5 的数组开始

先通过直观的书写表达，看看这样的数组应该是怎样的。

>>> np.arange(20).reshape(4,5)
array([[ 0,  1,  2,  3,  4],
       [ 5,  6,  7,  8,  9],
       [10, 11, 12, 13, 14],
       [15, 16, 17, 18, 19]])

如果按照“矩阵”思想去理解这个矩阵很简单。但这里，我们重新按照上述的原则去理解这个数组。即：

• 最后一个维度（即第二个维度），该维度的长度是5，将其理解为列维度
• 倒数第二个维度，即第一个维度，该维度的长度是4，将其理解为行维度

形式上，这与一般的矩阵，是完全一致的。只是，思维方式，反过来了。

再考虑 3x4x5 的数组

这个数组已经不能用简单的平面表示了，这里使用了符合上述描述的形式描述，“剩余的维度，则是通过层的方式去构建”，则有：

>>> np.arange(60).reshape(3,4,5)
array([[[ 0,  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],
        [45, 46, 47, 48, 49],
        [50, 51, 52, 53, 54],
        [55, 56, 57, 58, 59]]])

这时，矩阵的想法就不太好用了。这里继续按照上面的原则，考虑：

• 最后一个维度，即这里的第三个维度，该维度的长度是5，将其理解为列维度
• 倒数第二个维度，即这里第二个维度，该维度的长度是4，将其理解为行维度
• 倒数第三个维度（第一个维度）该维度长度是3，将其理解为行列式前面的层

循着这样的思考模式，不断地叠加更多的“层”，就可以理解更高维度的数组了。

考虑 2x3x4x5 的数组

这里先试用“层”的思维，可视化的表示该数组如下：

>>> np.arange(120).reshape(2,3,4,5)
array([[[[  0,   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],
         [ 45,  46,  47,  48,  49],
         [ 50,  51,  52,  53,  54],
         [ 55,  56,  57,  58,  59]]],


       [[[ 60,  61,  62,  63,  64],
         [ 65,  66,  67,  68,  69],
         [ 70,  71,  72,  73,  74],
         [ 75,  76,  77,  78,  79]],

        [[ 80,  81,  82,  83,  84],
         [ 85,  86,  87,  88,  89],
         [ 90,  91,  92,  93,  94],
         [ 95,  96,  97,  98,  99]],

        [[100, 101, 102, 103, 104],
         [105, 106, 107, 108, 109],
         [110, 111, 112, 113, 114],
         [115, 116, 117, 118, 119]]]])

继续按照上面的原则，考虑：

• 最后一个维度，即这里的第四个维度，该维度的长度是5，将其理解为列维度
• 倒数第二个维度，即这里第三个维度，该维度的长度是4，将其理解为行维度
• 倒数第三个维度，即第二个维度，该维度的长度是3，将其理解为行列式前面的层
• 倒数第四个维度，即第一个维度，该维度的长度是2，将其理解为行列式前面的层的层，也就是上述的“Layer”

使用这样的模式，就可以将一个多维数组的表示平面化。并且注意到，这与ndarray输出的形式是几乎完全一致的。

回到前面的问题

有了上面的可视化展示以及上面逐步的介绍，应该可以更容易理解前面NumPy: the absolute basics for beginners所提到的直觉“a better mental model is to think of the column index as coming last and the row index as second to last”。

有了这个直觉，我们再来考虑最前面提到的问题：

>>> import numpy as np
>>> np.array([[[1],[2]],[[3],[4]]]).shape

最内层的列，就是最后的维度长度，这里是 1，所以就是 ? x 1；该列所对应的行数，就是倒数第二个维度的长度，这里做如下的格式化，可以看到有两行，所以这是一个? x 2 x 1的数组；再向上看一层，共有两个该2x1的数组，故，该数组的shape时：2x2x1。

[
  [
    [1],
    [2]
  ],
  [
    [3],
    [4]
  ]
]

再确认最后的输出：

>>> import numpy as np
>>> np.array([[[1],[2]],[[3],[4]]]).shape
(2, 2, 1)

最后

这种理解的核心即是“a better mental model is to think of the column index as coming last and the row index as second to last”，简单概括如下：

• 总是将最后一个维度理解为列维度
• 总是将倒数第二个维度理解为行维度
• 剩余的维度，则是通过层的方式去构建

为什么需要间隙锁

关于为什么需要 “Gap Locks” 或者 “Next-key Locks” ，在MySQL的文档“17.7.1 InnoDB Locking”的小节中有较为详细的介绍，这里不再赘述。这里使用一个具体的示例，以便开发者方便构造与观察间隙锁。

在Repeatable-Read隔离级别下，在整个事务的过程中，数据需要保持一致，经常需要使用间隙锁对数据或资源进行保护。例如，在如下的事务中：

DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (
  id int,
  nick varchar(32),
  age int,
  KEY ind_n (nick),
  PRIMARY KEY (id)
);

INSERT INTO t1 VALUES ( 1, "a", 27 );
INSERT INTO t1 VALUES ( 11, "k" ,23 );
INSERT INTO t1 VALUES ( 24, "x" ,22 );

START TRANSACTION;
SELECT * FROM t1 WHERE nick >= "k" for update;
+----+------+------+
| id | nick | age  |
+----+------+------+
| 11 | k    |   23 |
| 24 | x    |   22 |
+----+------+------+
2 rows in set (0.00 sec)  Warnings: 0

在上述事务中，为了实现将 SELECT 涉及的“相关记录”全部加上“排它锁”，从而阻止其他事务对该部分数据进行修改。即，如果有任何其他的事务，尝试修改该事务中的“相关记录”，都需要被阻塞。这里的“相关记录”，具体是指：WHERE nick >= "k" 查询扫描到的索引入口（二级索引），以及对应的数据（即主键入口）。

试想，如果有其他事务尝试写入一条 nick = 'm'的记录，那么上述的...for update语句则也会返回该记录。为了阻止上述的不一致，上述事务不仅要对单个记录或索引入口进行加锁，还需要对索引入口之间的间隙进行加锁。

具体的，该案例中详细的锁信息如下：

mysql> SELECT
    ENGINE_TRANSACTION_ID AS TRX_ID,     OBJECT_NAME,     
    INDEX_NAME, LOCK_MODE,     LOCK_STATUS,     
    LOCK_DATA    FROM performance_schema.data_locks 
  WHERE LOCK_TYPE="RECORD";
+--------+-------------+------------+---------------+-------------+------------------------+
| TRX_ID | OBJECT_NAME | INDEX_NAME | LOCK_MODE     | LOCK_STATUS | LOCK_DATA              |
+--------+-------------+------------+---------------+-------------+------------------------+
|  10703 | t1          | ind_n      | X             | GRANTED     | supremum pseudo-record |
|  10703 | t1          | ind_n      | X             | GRANTED     | 'k', 11                |
|  10703 | t1          | ind_n      | X             | GRANTED     | 'x', 24                |
|  10703 | t1          | PRIMARY    | X,REC_NOT_GAP | GRANTED     | 11                     |
|  10703 | t1          | PRIMARY    | X,REC_NOT_GAP | GRANTED     | 24                     |
+--------+-------------+------------+---------------+-------------+------------------------+

上述的锁信息显示，该事务获得了索引 (a,supremum)间隙的排它锁，以及对应的数据记录锁。

如果说上述案例中的 SELECT ... FOR UPDATE在实际中不那么常见的话，类似的直接使用UPDATE语句也需要类似的加锁信息，这里使用SELECT ... FOR UPDATE展示则更为直接。

InnoDB 中“间隙锁”的表示

理解 InnoDB 锁的困难有很多，其中一个非常大的困难就是理解在 InnoDB 间隙锁的表示，因为 InnoDB 使用了一个比较反直觉的模式去实现间隙锁。具体的：InnoDB 在表示间隙锁的时候，并没有把 GAP或Next-Key当做一个“资源”。而是依旧把Record当做资源，然后，以“锁类型的”（Lock Mode）不同的取值表示记录锁或间隙锁。例如，

• Lock Mode取值为S,GAP时，则表示间隙锁，锁类型为S
• Lock Mode取值为S,REC_NOT_GAP时，则表示记录锁，锁类型为S

锁的对象，均为索引入口或主键入口。

关于该实现，在InnoDB Data Locking – Part 2 “Locks”中有着较为详细的描述：

“Even without knowing too much about how databases like InnoDB operate, we can guess, that sometimes the operation involves just the record, sometimes the gap before a record, and at yet another times we need to access both, the record and a gap. One way to model that, would be to consider records and gaps to be two different kinds of resources which you can lock independently. Current InnoDB implementation takes a different approach: there is just one resource for each point, but there are multiple kinds of access right you can request for it, and the access right specifies if you need the row, the gap or both parts. One benefit of this is that it is optimized for the most common case where you need both.”

InnoDB Data Locking – Part 2 “Locks”

锁类型与加锁模式

这里使用如下表格表示了InnoDB在进行加锁时常见的加锁对象与类型。这里Dm表示具体的加锁数据，例如索引入口数据或主键数据。详细的表格如下：

通常的，

• 在performance_schema中看到的Dm取值可能是这样：0x000000000207

• 在show engine innodb status\G中看到的Dm会是：0: len 4; hex 00000001; asc ;;
• D(m-1)则表示在索引中，Dm前面的一个索引入口或主键取值
• (...)表示开区间；(...]表示半开半闭区间

在 show engine innodb status\G 输出示例：

RECORD LOCKS space id 27 page no 4 n bits 72 index PRIMARY of table `sysbenchdb`.`t1` trx id 10094 lock mode S locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 0: len 4; hex 00000001; asc     ;;
 1: len 6; hex 00000000276d; asc     'm;;
 2: len 7; hex 810000008d0110; asc        ;;
 3: len 1; hex 61; asc a;;
 4: len 4; hex 8000000c; asc     ;;

UPDATE 语句的间隙锁

环境说明

mysql> show variables like '%iso%';
+-----------------------+-----------------+
| Variable_name         | Value           |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
1 row in set (0.01 sec)

场景构造

观测间隙锁

mysql> SELECT      
  ENGINE_TRANSACTION_ID AS TRX_ID,     
  OBJECT_NAME,  INDEX_NAME, LOCK_MODE,     
  LOCK_STATUS,  LOCK_DATA
FROM performance_schema.data_locks WHERE LOCK_TYPE="RECORD";
+--------+-------------+------------+---------------+-------------+-----------+
| TRX_ID | OBJECT_NAME | INDEX_NAME | LOCK_MODE     | LOCK_STATUS | LOCK_DATA |
+--------+-------------+------------+---------------+-------------+-----------+
|  10644 | t1          | ind_n      | X,GAP         | GRANTED     | 'x', 24   |
|  10644 | t1          | ind_n      | X             | GRANTED     | 'k', 11   |
|  10644 | t1          | PRIMARY    | X,REC_NOT_GAP | GRANTED     | 11        |
+--------+-------------+------------+---------------+-------------+-----------+

可以看到，在索引上（KEY ind_n (nick)）的锁范围为：(a,x)。这个范围由两个锁构成，分别是：

• X,GAP : 'x', 24 对应的范围为 (k,x)
• X : 'k', 11 对应的范围为 (a,k]

故，上述两个范围，共同构成的范围为：(a,x),锁类型都是排它锁（X）。

测试验证

可以尝试写入一个在 (a,k)或(k,x)范围为的记录，观察阻塞情况。继续上述的两个Session，并执行如下的SQL 语句进行观察：

参考链接

• Locks @ Operating Systems: Three Easy Pieces