[MySQL 5.7.7] 拆分LOCK_grant读写锁

Lock_grant锁实际上是一个读写锁，每执行一条sql都要读取执行check_grant来检查权限是否匹配，这时候加的是读锁，而读锁是可以并发的。大多数情况下加锁开销是很不明显的，但是在MySQL将大多数只读场景下的锁都消除掉后，LOCK_grant开始变的比较突出了。

5.7里主要消除掉了几种会影响到只读性能的锁：

#为InnoDB表消除THR_LOCK

#MDL LOCK维护改成LOCK FREE的算法

#为AUTO-COMMIT的SELECT缓存Read View来减少trx_sys->mutex冲突

Stewart Smith report了一个Bug#72829 来描述LOCK_grant在power机型的影响，在他的测试中，LOCK_grant去除掉后，居然有50的性能提升。我相信这是和平台相关的。。。因为我的机器上很难达到这样的提升。。。。

我也在bug上跟着吐槽啦，MySQL 5.7.5的只读测试中，LOCK_grant直接排到第一位了：

root@performance_schema 05:37:18>SELECT COUNT_STAR, SUM_TIMER_WAIT, AVG_TIMER_WAIT, EVENT_NAME FROM events_waits_summary_global_by_event_name where COUNT_STAR > 0 and EVENT_NAME like 'wait/synch/%' order by SUM_TIMER_WAIT desc limit 20;
+------------+----------------+----------------+---------------------------------------------------+
| COUNT_STAR | SUM_TIMER_WAIT | AVG_TIMER_WAIT | EVENT_NAME                                        |
+------------+----------------+----------------+---------------------------------------------------+
|   26086077 | 17068952969200 |         654000 | wait/synch/rwlock/sql/LOCK_grant                  |
|   78512461 | 16715117127344 |         212768 | wait/synch/sxlock/innodb/hash_table_locks         |
|  130770402 | 15605301433540 |         119028 | wait/synch/mutex/sql/THD::LOCK_query_plan         |
|   52314260 | 12553580466128 |         239800 | wait/synch/mutex/sql/LOCK_table_cache             |
|   78446571 |  9825008327284 |         125132 | wait/synch/mutex/sql/THD::LOCK_thd_data           |
|   26175928 |  6455036525220 |         246340 | wait/synch/sxlock/innodb/index_tree_rw_lock       |
|   52299088 |  5974745787424 |         114232 | wait/synch/mutex/sql/THD::LOCK_thd_query          |
|       7568 |     1095036672 |         144316 | wait/synch/mutex/innodb/flush_list_mutex          |
|       7656 |      885055584 |         115540 | wait/synch/mutex/innodb/buf_pool_mutex            |
|       7603 |      638888240 |          83712 | wait/synch/mutex/sql/LOCK_global_system_variables |
|        242 |      354649376 |        1465396 | wait/synch/sxlock/innodb/dict_operation_lock      |
|       3445 |      351421232 |         101588 | wait/synch/mutex/innodb/dict_sys_mutex            |
|       1602 |      339106848 |         211460 | wait/synch/mutex/innodb/innobase_share_mutex      |
|       1602 |      321693008 |         200560 | wait/synch/mutex/sql/LOCK_open                    |
|       2672 |      315876768 |         118156 | wait/synch/mutex/sql/LOCK_plugin                  |
|       1050 |      308335712 |         293428 | wait/synch/mutex/sql/LOCK_connection_count        |
|       1602 |      235623120 |         146932 | wait/synch/mutex/innodb/file_format_max_mutex     |
|       1281 |      217084400 |         169168 | wait/synch/mutex/sql/LOCK_thd_list                |
|        983 |      209930512 |         213204 | wait/synch/mutex/sql/LOCK_status                  |
|       1380 |      199285136 |         144316 | wait/synch/mutex/sql/LOCK_user_conn               |
+------------+----------------+----------------+---------------------------------------------------+

由于只加的LOCK_grant读锁，该锁的并发开销主要来自Cache失效以及原子操作。

解决：

解法也比较简单：创建32个读写锁，当需要加读锁时，根据当前线程的thread_id，模到对应的读写锁对象，加上读锁； 当需要加写锁时，则把32个读写锁对象的写锁都加上。

显然加写锁的代价提升了，但是谁会没事儿把类似GRANT语句作为主要的负载呢。

在我的优化版本的5.6分支上，加了该改进后，可以将只读QPS从10w推进到10.5w QPS

Patch:  https://github.com/mysql/mysql-server/commit/75fd4b3defc68176e3f38407fe9f6aa538424562