mysql并发ppt_腾讯资深数据库工程师张青林：MySQL大并发量性能优化实战

1. Gdevops 全球敏捷运维峰会 MySQL大并发量性能优化实战 演讲人：张青林 Gdevops.com 全球敏捷运维峰会 上海站

2. mysql_parse mysql_execute_command 简 单 查 execute_sqlcom_select 询 语 open_normal_and_derived_tables 句 的 open_table_get_mdl_lock 执 行 handle_select 过 程 thr_lock engine operation close_open_tables Gdevops.com 全球敏捷运维峰会 上海站 PS 的 影 响 范 围

3. Agenda  metadata_locks_hash_instances 的作用 & 原理 & 实现  table_open_cache_instances 的作用 & 原理 & 实现  performance_schmea 的作用 & 原理 & 实现  INNODB MVCC 的实现 Gdevops.com 全球敏捷运维峰会 上海站

4. MySQL metadata_locks_hash_instances  什么是 MDL Lock ，其主要作用是什么？ MDL Lock (Metadata Lock)，即 Server 层的数据字典锁，是为了保护 DB， table, trigger, procedure 等数据对象而设计的，先看一下一个 bug#989： Gdevops.com 全球敏捷运维峰会 上海站

5. MDL Lock 的实现原理 mysql_execute_command THD -> MDL_context -> MDL_tickets -> MDL_lock ... acquire_lock(...mdl_requests...) try_acquire_lock_impl find_or_insert MDL_map_partition::find_or_insert MDL_map MDL_lock::create .... m_partitions.at(part_id) m_partitions.at(part_id) m_partitions.at(part_id) .... mdl_locks m_mutex ... MDL_key {mdl_namespace, dbname, object_name} 问题：MDL Lock 中存在的瓶颈，MDL Lock 瓶颈的缓解方法， MDL Lock 中在各个版本中的实现方法 Gdevops.com 全球敏捷运维峰会 上海站

6. MySQL table_open_cache_instances  什么是 table_cache，为什么需要 table_cache ? table_cache是缓存 table 对象的容器，table 是MySQL中用户线程操作表对象的内存对象，table 中包括了用 户的相关操作记录，对应的 engine 的文件句柄以及内部对象管理的控制信息等；  MySQL 打开表 & 关闭表的过程  MySQL 打开表的流程中存在的性能瓶颈 当 MySQL 的并发链接数较高的时候，会有多个用户线程被分配到同一个 table_cache 中，造成多个线程竟争 table_cache->m_lock 的问题，引起 thread_running 飙升；  解决 table_cache 问题的方法 对参数 table_open_cache_instances 进行调整，1 -> 64  table_open_cache_instances & table_definition_cache 关系 每一个 table 内存对像中会有一个指象表对像的指针，即 table_share, table_share 也有一个缓存大小的设置， 即 table_definition_cache， 同时， table_definition_cache 也是 innodb 层缓存数据字典的设置，如果没有对 table_definition_cache 进行设置，则会根据 table_open_cache的值进行计算；  table cache 相关问题的状态信息 show status like '%table_cache%'; flush tables; Gdevops.com 全球敏捷运维峰会 上海站

7. table 对象的生命周期 open_and_process_table open_table ... tc= table_cache_manager.get_cache(thd) tc->lock() table= tc->get_table() tc->unlock ... close_thread_table release_table link_unused_table ... el->used_tables.remove(table); el->free_tables.push_front(table); link_unused_table(table); free_unused_tables_if_necessary ...  cache_manager & cache_instance 控制的是 thd 使用表的分区信息；  Table_cache_element table_cache 共同管理 table 缓存对象； Gdevops.com 全球敏捷运维峰会 上海站

8. MySQL performance_schema 什么是 performance_schema，和 information_schmea 有什么区别？ performance schema 是 MySQL 的内部诊断器，用于记录 MySQL 在运行期间的各种信息，如表锁情况、 mutex 竟争情况、执行语句的情况等,和 Information Schema 类似的是拥用的信息都是内存信息，而不是 存在磁盘上的。和 information_schema 有以下不同点：  information_schema 中的信息都是从 MySQL 的内存对象中读出来的，只有在需要的时候才会读取这 些信息，如 processlist, profile, innodb_trx 等，不需要额外的存储或者函数调用，而 performance schema 则是通过一系列的回调函数来将这些信息额外的存储起来，使用的时候进行显示，因此 performance schema 消耗更多的 CPU & memory 资源；  Information_schema 中的表是没有表定义文件的，表结构是在内存中写死的，而 performation_schema 中的表是有表定义文件的；  实现方式不同，Information_schema 只是对内存的 traverse copy, 而 performance_schema 则使用固 定的接口来进行实现；  作用不同，Information_schema 主要是轻量级的使用，即使在使用的时候也很少会有性能影响， performance_schema 则是 MySQL 的内部监控系统，可以很好的定位性能问题，但也很影响性能； Gdevops.com 全球敏捷运维峰会 上海站

9. Performance schema 的作用  对各种资源监控开关进行设置  监控mutex, rw_lock, conds等资源的使用情况  监控内存使用的情况 (5.7)  监控SQL语句的使用情况并对相关的语句进行统计  监控内部运行的线程  监控文件资源的使用情况并对相关的资源进行统计 Gdevops.com 全球敏捷运维峰会 上海站

10. Performance schema 实现过程及问题  创建对应的监控表  实现 performance_schema 引擎的相关接口；  在相应的地方设置回调函数，在相应的操作中添加或减少对应的监控信息；  查询的时候调用相应的接口访问已经额外存储的数据；  由于需要存储一份额外的数据在内存中，所以会有额外的内存消耗；  Perfornamce schema 会加重计算代价，对性能也有一定的影响； Gdevops.com 全球敏捷运维峰会 上海站

11. MySQL MVCC 的实现  MySQL Innodb record 物理结构  MySQL Innodb MVCC 实现原理  MySQL Innodb MVCC 实现过程中存在的问题  MySQL Innodb MVCC 对于问题的解决过程  TDB5.6 Innodb MVCC 解决问题的方案设计 Gdevops.com 全球敏捷运维峰会 上海站

12. MySQL Innodb record 物理结构 Record 格式： 记录头 主键 TRX_ID ROLL_PTR extra_column 变长记录长度数组 NULLABLE_COLUMNS extra info REC_NEW_INFO_BITS REC_NEW_N_OWNED REC_NEW_HEAP_NO REC_NEW_STATUS REC_NEXT Gdevops.com 全球敏捷运维峰会 上海站

13. MySQL Innodb MVCC 实现原理 MVCC 部分调用栈： row_search_for_mysql row_vers_build_for_consistent_read ROLL_PTR  read view 的创建在 RC & RR 隔离级别下的区别 ？  purge 线程 read_view 的创建需要注意的问题 ？  活跃事务的更改对 read_view 创建的影响 ？ trx_undo_prev_version_build low_limit_no, used for purge read_view_sees_trx_id low_limit_id, trx whose trx_id >= low_limit_id is unvisible high_limit_id, trx whose trx_id < high_limit_id is visible Gdevops.com 全球敏捷运维峰会 上海站

14. MySQL Innodb MVCC 存在的问题 参考视图创建函数 read_view_open_now_low，可以看到：  整个创建过程一直持有 trx_sys->mutex 锁；  需要遍历 trx_sys->trx_list (5.5) 或 trx_sys->rw_list (5.6)；  read_view 的内存在每次创建中被分配，事务提交后被释放；  并发较大，活跃事务链表过长时，会在 trx_sys->mutex 上有较大的消耗； 详情见：https://bugs.mysql.com/bug.php?id=49169 Gdevops.com 全球敏捷运维峰会 上海站

15. MySQL Innodb MVCC 对于问题的解决过程 解决过程比较区折，但主要是从几个方面来进行优化，从5.6 ->5.7 的 release note & work log 也可以清晰的 看到，简单介绍如下：  减少 read_view 创建时的事务链表的长度(语法上支持或设置 session 变量)  减少 read_view 创建时的不必要的内存分配  减少遍历 rw_trx_list 链表的次数  减少 read_view 的分配 & 释放 Gdevops.com 全球敏捷运维峰会 上海站

17. CDB 5.6 Innodb MVCC 解决问题的方案设计 结合 percona & MySQL 5.7 两种方案进行实现，主要思想如下：  backport percona 5.6 中对 bug#49169 的修复；  实现 MySQL 5.7 中移除只读链表的想法；  其它在编码 & 测试过程中待改近的地方 经过以上的优化，对于只读性能应该可以有比较大的提升，目前进度在移除只读链表中 Gdevops.com 全球敏捷运维峰会 上海站

18. Gdevops 全球敏捷运维峰会 THANK YOU！ Gdevops.com 全球敏捷运维峰会 上海站