【七天深入MySQL实战营】答疑汇总Day2 MySQL 高并发场景实战

【开营第二课，MySQL 高并发场景实战】
讲师： 凌洛，阿里云数据库解决方案专家。
课程内容：高并发场景下MySQL数据库的技术挑战；如何用RDS MySQL支撑高并发业务；高并发场景数据库运维最佳实践。
答疑汇总：特别感谢班委@李敏 同学

1. Mysql 一年应该是什么水平？需要知道哪些知识？
   A：个人学习/接触 Mysql 一年的话，最主要的还是学习基础知识，如果你接触的项目够多的话，你会在实际的项目当中，获得实际的一些和业务、技术结合的经验，一年的话，最开始还是要从基础知识开始学

2. 最大连接数1000，高并发指多大的活跃连接数？最大连接数是 1000 的话，根据 rds 的规格来说的话，还是比较低的。在高并发的情况下，指多大的活跃连接数？
   A：活跃连接数，和 CPU 的核数是相关的，建议将最大活跃连接数不超过 CPU 核数 3 ～ 4，这个时候它的性能是比较高的。经常有用户会混淆“最大连接数”和“活跃会话数”这两个概念，最大连接数是指你的应用 应用连接池 * 实例上有多少个 DB，不超过最大的连接数的数量（这句话不太好整理），活跃会话数是指正在干活的数量，这个数量不是越多越好，我们要保证活跃会话要尽可能少，这样的话，mysql 才能提供最高的一个性能（理解各种连接数：https://developer.aliyun.com/article/683460）

3. Mysql 中分表时，需要组合表查询时，如何做到高效？
   A：是不是想问多维查询的概念啊？通常分表了以后。。。（中断，调试了一下连麦）mysql 在分表时，如何做到组合表查询，neng zuodao 高效，其实对于一张单表上面来说的话，它比较容易控制，比如说有主键、唯一键，在一张表上就不会出现，和其他表的关联，就不说了，如果一张表有超过1亿条的记录，就要考虑分库分表了，在分库分表的时候，如果两张表都超过一亿，这位同学，是不是想问多维查询的概念啊？如果想避免多维查询的话，这个时候还是要做数据冗余的，不是说数据表设计符合三范式越好，如果分库分表了以后，尽量还是要避免组合表的查询，特别是在分裤分表了之后，避免不了的话，那两个表join的时候，在关联的字段上面还是要建索引的。在两个表查询的时候，如果查询关联字段不太多的话，还是要做适当的字段冗余）。还有一个巧思是说，比如淘宝系统买家库和卖家库，因为只能按照一个维度来分表，如果按买家分表，但是按照卖家来查询，其实是用不上分库分表的字段，如果你是要用卖家的数据的话，它其实有几种方式，一种方式是做数据冗余，还有另一种方式是在现有表的基础上，相当于是存一个映射的表，相当于你还是要做数据冗余，但是数据冗余是用的不同的的方式，你可以全量地把买家表的数据同步到卖家表，它的数据是一样的（买家表的数据和卖家表一样），只不过你是以另外一种维度（卖家）来分表，这以空间换时间的概念；另一种方式就是，你可以没有，另外一个以卖家维度分表的那一份完整的冗余数据，但是你可以冗余它的 ID，在现有表的基础上，只需要买家表和卖家表对应的id就可以了，这是一个比较轻量级的数据冗余，如果要是用 drds 的话，可以用全局二级索引，我刚才说的那个概念其实也类似于全局二级索引，drds 里面是有这个概念的，你在 drds 创建索引的时候，官方文档是有的。（Polar-X 2.0的全局二级索引 https://help.aliyun.com/document_detail/182180.html?spm=a2c4g.11186623.2.2.1bb148c1p28A4b ；）

4. Mysql 5.7 使用 MHA 无损复制，是否有丢数据的可能？
   A：还是要看 5.7 使用的架构，三节点的企业版本，双节点的开源社区版本，如果是双节点，以双1的参数（innodb_flush_log_at_trx_commit=，sync_binlog=1）启动的话，原生的社区版是有丢一个事务（数据）的可能的，如果是用 rds 企业版或者金融版，这种的话是不会丢数据的。

5. Mysql 中单表大约一亿行数据，只有首列（自增列）为主键，这种设计是因为高并发吗？高并发在表设计上有哪些需要注意呢？
   A：如果只有自增的列为主键，这种方式，如果是只有自增的列作为主键，是有助于高并发的，但又不完全是因为这个。还有哪几种可能会影响高并发的，最主要是内存的缓存命中率，就是 buffer pool 的命中率，如何才能在有限的 buffer pool 里面，存储足够多的数据，那就需要我们在数据库设计的时候注意，因为 buffer pool 里面缓存了索引和数据，buffer pool 的命中率是一个方面，还有一个方面，是在磁盘空间里面，mysql 的 innodb 表是索引组织表，如果是换做一个字符串为主键的话，相当于每个二级索引上都要挂一个这样的叶子结点，不管是它的磁盘空间的使用会增长，buffer pool 里面存储的数据并不是那么多。首列作为主键只是一个参考，我们需要从那几个方面去考虑高并发，最主要的还是要考虑缓存命中率，还有就是底层的数据结构，无论是做查找的时候，还有是在缓存命中率的时候，是否有助于...。为什么会涉及缓存，一级一级来，刚才提到过的 redis，其实也是提升缓存的命中率，对于mysql 来说，buffer pool 也是一个缓存，内存的命中率，怎样才能提升内存的命中率，也是从设计的时候考虑的一个问题。（buffer pool 的大小是可以配置的，内存空间在启动的时候立即分配完成了，老师所说的更多的数据，有时候需要按照更多的记录之类的去理解）

6. Mysql 的读写锁怎么使用更好？读写锁的使用场景？
   A：如果是单个语句来查询的话，数据库内部自己就控制了，对于应用来说，就不用单独来控制，如果涉及到事务，比如事务，我见过事务最多的是，一个事务里面有一千条语句，那在写事务的时候就要注意了，特别是在核心的事务里面，特别是在减库存的场景里面，你的行锁的释放时间和事务的释放时间是有关系的，我们在使用事务的时候，还是要尽量地减少行锁持有的时间，如果事务里面有读的话，如果业务上允许的话，把它移到外面，尽量地使这个事务足够的少，这个就是事务里面的控制。

7. 高并发的时候，频繁 crud，容易读到旧数据应该怎么办？
   A：对于数据库来说，底层的 MVCC 已经保证了数据一致性，你问的应该是缓存里面，比如 redis、memcache，从缓存读到旧数据应该怎么办？基于这个问题，我们还是要基于实际的应用场景出发，比如减库存，涉及到交易这种场景的话，以哪个（数据）为准？以缓存的为准，然后把它同步到数据库里面；还是以数据库里面的数据为准，到数据库执行的时候，还是要做一个判断的，如果是想要严格一点的话，还是要以数据库为准；如果要是以数据库为准的话，相当于是你从缓存里面读到既有的数据，你的缓存怎样才能保证100%命中？群里同学也有提到说，redis 那个链路更新的延迟，我们可以算一下，如果要