根据worklog的描述，该特性主要是为了解决WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS的缺点：
#该功能依赖于slave来运行，如果复制线程没有启动或者出错了，就会返回错误。在某些情况下我们需要一直等待；
#返回的是执行的事件的个数，这通常是没有意义的，返回成功或者失败即可。
引入新的语法：
WAIT_FOR_EXECUTED_GTID_SET(GTID_SET [, TIMEOUT])
当GTID_SUBSET(GTID_SET, @@global.gtid_executed)成立时，即指定的GTID是gtid_executed的子集时，返回0表示成功，否则返回1，表示失败。
例如：
root@(none) 07:46:32>select @@global.gtid_executed;
+——————————————-+
| @@global.gtid_executed |
+——————————————-+
| 46293b73-58db-11e4-8b9c-38eaa78f3a78:1-32 |
+——————————————-+
1 row in set (0.00 sec)
root@(none) 07:48:56>select WAIT_FOR_EXECUTED_GTID_SET(‘46293b73-58db-11e4-8b9c-38eaa78f3a78:1-6′,64) as status;
+——–+
| status |
+——–+
| 0 |
+——–+
1 row in set (0.00 sec)
如下则需要等待，如果一直不满足，就会超时返回…
root@(none) 07:47:32>select WAIT_FOR_EXECUTED_GTID_SET(‘46293b73-58db-11e4-8b9c-38eaa78f3a78:1-37′,64);
老规矩，我们继续来看看代码的相关实现。另外该补丁也可能引入一个性能问题（待证实）
0.background
Mutex_cond_array：
Mutex_cond_array::wait 需要判断线程是否被kill来结束等待
增加新接口函数，等待指定sidno的condion.
inline int wait(const THD* thd, int sidno, struct timespec* abstime)
Gtid_state
增加接口函数Gtid_state::wait_for_gtid_set
Owned_gtids
sql/item_create.cc
Create_func_executed_gtid_set_wait 为新的函数增加接口类定义，解取参数item，然后创建对象Item_wait_for_executed_gtid_set
以后要增加新的函数接口，可以按照这个典型又简单的套路来实现；
文件sql/item_func.cc， sql/item_func.h新增：
类Item_wait_for_executed_gtid_set
Item_wait_for_executed_gtid_set::itemize
Item_wait_for_executed_gtid_set::val_int
{
…
result= gtid_state->wait_for_gtid_set(thd, gtid, timeout);
…
}
sql/item_func.h
Item_executed_gtid_set_wait
Item_wait_for_executed_gtid_set::itemize
Item_wait_for_executed_gtid_set::val_int
1.等待
堆栈：
mysql_select —> JOIN::exec —-> select_send::send_data —-> Protocol::send_result_set_row—> Item::send —> Item_wait_for_executed_gtid_set::val_int —> Gtid_state::wait_for_gtid_set —> Gtid_state::wait_for_gtid
Gtid_state::wait_for_gtid_set
检查请求的GTID集合 是否包含了当前的executed_gtid。如果不满足，则找出不满足的gtid的sidno (根据uuid 进行map后的整数)，进入condition wait.
2.通知
在事务提交时，会发送broadcast.
Gtid_state::update_on_commit —-> Gtid_state::broadcast_owned_sidnos
不过很显然，每次commit事务都需要做一次broadcast , 不管有没有线程在等待。感觉这部分应该可以被优化掉。
3.存在的问题
在之前版本中，如下逻辑：
开始刷Binlog cache时, gtid被加入到gtid_executed，在完成commit后，从gtid_owned移除；
在5.7.5版本里，加入到gtid_executed集合的操作被转移到完成commit后。由于在finish_commit中，各个线程是并发执行的，因此产生大量的锁竞争； 而在之前版本中,flush binlog cache总是只有一个线程进行，因此锁竞争很小。
当然这只是个人猜测，还没有回滚代码去证实，不过5.7.5的GTID改动确实引发了极大的性能退化，已经report了Bug并被verified了，感兴趣的可以看看这个bug:
http://bugs.mysql.com/bug.php?id=74328
4.代码
http://bazaar.launchpad.net/~mysql/mysql-server/5.7/revision/8460
