最终问题归结到m_part_spec.end_part 的生成原因。通过对end_part 使用地方进行排查，最终在get_partition_set函数中定位到该变量在使用前的初始设置值。从代码中可以看出，每次单条记录的update操作，在进行index scan上锁时，对分区表数目相同的行数进行上锁。这个是根本原因。
验证结论
根据之前的分析，每次单条记录的update操作，会对分区表数目相同的行数进行上锁。我们尝试验证我们的发现。
新增如下两条记录：
INSERT INTO t2 VALUES (4, NOW(), '4');
INSERT INTO t2 VALUES (5, NOW(), '5');
// SESSION 1 对id = 1的 记录 做一个更新操作，事务先不提交。
BEGIN;UPDATE t2 SET DATA = '12' WHERE id = 1;
// SESSION 2 现在对id = 4 的记录做一个更新。
BEGIN;UPDATE t2 SET DATA = '44' WHERE id = 4;
我们发现，对id = 4的更新可以正常进行。不会受到id = 1 的更新影响。这是因为id=4的记录，超过了测试案例的分区个数，不会被锁住。在实际应用中，分区表所定义分区数不会如测试用例中的只有3个，而是数十个乃至数百个。这样进行上锁的结果，将加剧更新情况下的锁冲突，导致事务处于锁等待状态。如下图所示，每个事务都上N个行锁，那么这些上锁记录互相覆盖的可能性就极大的提高，也就导致并发下降，效率降低。
结论
通过上述分析，我们非常确认，这个应该是MySQL 5.7版本的一个regression.我们提交了一个Bug到开源社区。Oracle确认是一个问题。需进一步分析调查这个Bug.
Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx