开发者学堂课程【MySQL 实战进阶：MySQL 高并发场景实战】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/83/detail/1306
MySQL 高并发场景实战
四．实例调优
1.弹性扩容
弹性扩容是其中的一步
2.参数调优
影响性能的几个主要参数
连接、 IO 、内存相关。
（1）和连接相关的几个参数：
back_log（标记 MySQL 的并发连接数，在短时间内有大量连接请求的时候会涉及，主线程会在一段时间内或瞬间检查连接数并启动新连接）、 table_open_cache （所有线程打开表的数量，这个性能较小的时候会导致性能下降，但是也不能设置地过大，过大时可能会造成 OOM ，当 thread_cache_size 中出现大量的这个参数时，就需要检查其变量是否需要调整）、thread_cache_size、loose_thread_pool_enabled
（2）和 IO 相关的几个参数
sync_binlog（每年双十一都会把它调度最优的状态）、innodb_flush_logs_at_trx_commit、innodb_io_capacity、innodb_io_capacity_max （后两个参数是和 IO 能力有关的重要参数）
（3）和内存相关的几个参数
innodb_buffer_pool_instances（在5.6版本之前，相对来说这个参数只有一个。
当只有这一个的时候，内存越大，性能越不稳定，因为它要锁一把大锁，当有 buffer_pool_instances 之后，会把 buffer_pool 开到好几个， buffer_pool_instances 一除就会拆到好几个内存的 list 里面，在这种情况下，每一个内存都会维护自己的 list 、自己的锁结构，相当于把这个锁拆分掉了，它的性能会提升很多）、join_buffer_size、tmp_table_size
此外，还有和几个连接相关的，比如 join_buffer 以及我们的临时表这样的一个参数。
这几个参数可以自己单独设置。但是我们把对性能影响比较大的参数调整到高性能模板里面，应用的时候找到对应的参数应用到对应的实例就可以了。
参数调优
路径：参数模板->系统参数模板->找到对应的参数模板->应用到实例
如图为根据普通的模板和高性能的模板做的对比，我们可以看到普通模板要比高性能模板低25%左右的性能。
五．内核调优
1.版本升级
官方维护的是5.6，5.7和8.0版本的 MySQL ，每一个大版本的升级会带来新的特性，同时性能也会上升。
如图，8.0版本的性能最强，但是升级的时候也会踩到一些坑，比如指令计划和原来的版本不太兼容，后面会有相关的专题。
2.AliSQL 特性
我们讲过了高并发场景下面临的挑战，会针对这些挑战提供解决方案。那么，针对高并发的场景以及热点库存的场景， AliSQL 提供了4个补丁，3个都是针对热点库存更新的，其中1个是库存注释。
库存注释：在秒杀等业务场景中，减库存是一个常见的高并发，串行化比较严重的模型，对数据库的吞吐能力产生巨大的挑战， AliSQL 使用排队和事务性 hint 来控制并发控制和快速提交或者回滚事务，一方面控制并发，另一方面快速结束事务释放事务锁，来提高减库存的吞吐能力。减库存：拍下减库存和付款减库存。拍下减库存即客户在拍下商品的时候把库存减掉，业务逻辑比较简单。付款减库存的业务逻辑比较复杂，它在用户付完款后才减库存。因为这个逻辑比较复杂，不能在一条语句中完成，是在事务里面完成的。
（1）如何提升事务的性能
在这个事物里面就是行索，冲突本来就已经比较严重了，如何才能提升事物里面的这个性能？
通常情况下，释放事物、开启事物和结束事物都是由应用来完成，如果是应用处理的过慢，或者是网络交互的时间过慢，或者是网络拥堵，它就会增加行所持有的时间，所以，库存注释是把这个持有行锁的时间行所释放，交给数据库自己来做，
也就是 commit on success robot on be ，就是这两个的意思，加上这个 pi 之后，成功就提交失败就回滚，他把这个控制权交给 MySQL 库内核，这样的话就可以减少行锁持有的时间，快速的结束事物，进而提升简库存的吞吐能力。
在简库存的场景里面还有一个特性是什么？
就是 MySQL ，它是分为引擎层和 server 层的。在高并发的场景下，同一行的行锁，会在 server 层和引擎层来回切换。 InnoDB ，它的事务锁是最新力度的行锁。
在语句对相同行进行并发操作的情况下，冲突比较严重，所以，AliSQL 就把这个冲突放在 server 层来进行排队，对于相同行的冲突，让它在一个层内，这样就会减少冲突检测的一个开销，进而就会减少引擎层和 server层上下文切换带来的消耗。
第三个是语句的语句返回，这个特性在 PG 和 Oracle 里面都存在，即returning，就是更新完了之后直接把结果返回。但是 MySQL 是没有的，AliSQL 把这个特性吸纳进来之后，也带有这个特性，即如果在一个事物里面更新完一行记录后，应用再发请求 select 这一条结果再返回给应用，我们就可以看到它会多一次网络交互。如果直接把update 的结果返回，就可以减少这一次网络交互，有多次的时候，它的性能提升可以节省多次的网络交互和应用判断的时间，所以这个也可以带来事物的性能的提升以及应用的性能的提升。
（2）对于高并发场景下， AliSQL 是怎么解决的呢？
是用线程池来解决的，线程池就是在有大量线程来进行并发访问的时候，线程池会自动地调节并发的线程数量，在合理的范围内避免线程池因为过多造成的大量缓存失效。
还有一个是在高并发的场景下，线程池会把语句和事物分为不同的优先级，分别控制语句和事物的并发数量，减少资源竞争，线程池也会根据不同语句的复杂性来管理控制它的优先级。所以，使用线程池，可以将不同的circle控制在一个合理的最佳的连接数的范围，使数据库在干部印发的场景下也保持一个比较高的性能。
如图，这是用我们的库存注释语句对列做的一个性能的对比。我们可以看到和原生的相比已经翻了40倍。
六．监控报警
监控报警系统调优必不可少监控。有 RDS 自带的监控、资源层面的监控、引擎层的监控、慢日志的监控，对于收费的来说，又包括审计日志以及自制服务会基于上面的 RDS 自带的以及审计日志会做一些分析，以及在这个基础上做的一些报警。此外，还有分布式的监控，它可以监控，在不同的组件里面它的瓶颈在哪里。
七．流程管理和生态工具
基于生态工具的这个保障，我们可以从变更流程、稳定性相关、数据恢复这几个方面来介绍。
1. 增加审批节点
DDL、DML、 数据导出可按需批量修改严格审批流程，严控执行
路径：系统管理-安全管理-安全规则/审批流程
2.设置超时时间（通用）
查询超时时间由日常的60 s 调整为5 s
路径：左侧实例导航-右键-编辑实例，查询超时时间设置
在大促期间，我们可以有很好的流程来提升稳定性，增加在审批环节中审批的流程、稳定性相关的。我们可以不用因为人为因素来给系统造成压力，就可以设置通过 DMS 来执行的这些 SQL ，不能让它超过一定的时间。因为超过一定的时间之后会自动的 Q 掉。
3.禁用部分语法（企业版）
针对 DDL、DML 可设置部分语法不允许在大促期间执行
路径：系统管理-安全管理-安全规则
可以针对某一类的 DDL， 或者是 DML 不允许执行，可以设置安全规则内核的特性。有的用户会在业务高峰的时候进行大文件的删除。在大文件删除的时候，会造成文件系统的 hang ，进而影响数据库的稳定性，可能会造成数据库的抖动。针对这一个特点，我们AliSQL 会创建、提供一个这样的补丁，可以提供小批量的异步删除，减缓删除速度来减少，甚至没有，这个取决于每一次设置的清理大小。
4.突发 SQL 访问控制
（1）内核特性--并发控制
当业务流量突然暴涨，或出现 Bad SQL 时， DBA 要考虑做限流，止损恢复业务。 AliSQL 设计了基于语句规则的并发控制， Statement Concurrency Control， 简称 CCL。
（2）DAS 限流
为防止数据库压力过大，一般都会在应用端做优化和控制。但在以下场景，也需要在数据库端做优化控制。如：
l 某类 SQL 并发急剧上升
l 有数据倾斜 SQL
l 未创建索引 SQL
并发的访问，这个我们在挑战里也讲了一些。当有数据失效或者有数据倾斜，或者是未创建所有的 circle ，在执行的时候，这种会造成数据库压力过大。
AliSQL针对这一类的 SQL 做了一个并发控制的补丁，即根据关键词识别出来之后，就可以控制这一类的 SQL 的并发度，并发执行。通过允许执行多少个，来防止某一类的 SQL 把系统打化的这种风险。
5.数据恢复
DMS数据追踪
使用场景
l MySQL 5.5/5.6/5.7/8.0
l DELETE/UPDATE/INSERT
l 少量
功能
l 在线搜索日志内容，无需手工下载Binlog
l 支持数据的插入/更新/删除日志搜索，无需手工解析 Binlog
l 支持逐条数据恢复，无需手工生成回滚语句
支持的 Binlog
l OSS Binlog （RDS 会定时将 Binlog 备份到 OSS 上）
l 本地热 Binlog （数据库服务器上 Binlog）
从数据恢复上面来说呢，一般常在河边走，哪有不湿鞋。一般大促的情况下，有的用户甚至在高峰的时候会人肉来做一些数据的变更。对于数据变更，在条件写错的情况下，也可以通过数据恢复将数据最终恢复回来。恢复最快可以在五分钟之内将误修改的数据恢复回来。
DMS数据追踪
数据恢复
控制台克隆实例/库表级别恢复
路径： RDS 管理控制台->实例列表->单击实例 ID ->备份恢复
数据恢复还可以通过备份来恢复，备份是可以分为克隆实例、整个实例级别的恢复以及库级别的恢复，还可以通过我们的 DBS 数据库备份来恢复。
八．总结
总结讲的内容，最主要的是我们的系统调优方面的一个工作，系统调优，从我们的容量评估、性能评测以及针对性能验证出来的这些问题来进行调优。
实例级别的调优、内核级别的调优来做对应的优化工作。我们可以借助于监控报警来发现这些问题。
