(16)mysql瓶颈 & MGR和一致性读 性能测试

容量： 看硬件

     InnoDB 最大容量64TB ，存储引擎将 InnoDB 表 保存在一个 表空间内（ 原始磁盘分区，由数个文件创建）。这样， 表大小 能超过 单独文件最大容量 。

    MySQL 3.22( MyISAM )限制表大小 4GB ，最大表尺寸增加到65536TB（2567 – 1字节）。最大有效表尺寸通常是由 *** 作系统 对 文件大小限制 决定的， 不是 由MySQL内部限制决定。

最多 20亿个表 ，一个表允许定义1024列，每行的最大长度为8092字节（不包括文本和图像类型的长度）；

阿里《Java 开发手册》提出 单表行>500w 容量>2GB ，才分库分表

与 MySQL 配置及硬件 有关，实际记录的条数无关。因为表 索引 装载 到内存，InnoDB buffer size 足够 ，才能全加载进内存，查没问题。达量级限时，导致 内存无法存储索引 ，产生磁盘 IO，性能下降。增加硬件配置解决。500w算折中

QPS在8400左右 ：400个线程并发，插入100万条记录（4核2.33G、3G内存、SATA硬盘）https://www.iteye.com/blog/wwtang9527-1718292

写： 90-100M/S（机械硬盘，7200转）预计kB_wrtn/s在90M左右

https://www.cnblogs.com/zhiqian-ali/p/6336521.html

show variables like 'max_connections'  mysql当前最大连接数

set global max_connections=1000 设置当前最大连接数为1000；mysql重启时失效,需要长期生效在my.ini 添加 max_connections=1000

从业务使用场景出发，根据RDS套餐类型和线上实际访问流量，来衡量性能指标，以便方便对标实际业务场景。

MySQL 5.7.21 Group Replication

MySQL 5.7.21 Group Replication with Consistent Read

同机房3节点、跨机房3节点

网络异常：长时间延时0.5ms，长时间延时2ms，丢包0.01%

场景1、2的差异可以衡量 跨机房网络 带来的 性能损耗

场景3关注在 网络质量变化 时带来的 性能变化

同机房3节点为 05 06 03    跨机房3节点为 05 06 01

机器部署：同IDC3台（永顺ys 03 05 06），跨IDC1台（广州gz 01）

同IDC RTT（06->05）：RTT min/avg/max/mdev = 0.051/0.059/0.070/0.010 ms

跨IDC RTT（01->05）：RTT min/avg/max/mdev = 0.739/0.749/0.810/0.027

    跨IDC的网络耗时是同 IDC的1.3倍 ，在设置 延迟0.5ms后 的网络质量：

同IDC RTT（06->05）：RTT min/avg/max/mdev = 0.507/0.564/0.617/0.037

跨IDC RTT（01->05）：RTT min/avg/max/mdev = 1.199/1.248/1.315/0.046

    跨IDC的网络耗时是 同IDC的2.2倍 ，在设置 延迟2ms后 的网络质量：

同IDC RTT（06->05）：RTT min/avg/max/mdev = 1.963/2.054/2.161/0.064 ms

跨IDC RTT（01->05）：RTT min/avg/max/mdev = 2.642/2.732/2.835/0.076 ms

参考：http://blog.720ui.com/2019/mysql_why_one_table_500w/?spm=a2c4e.10696291.0.0.26e819a4zY3hrA&aliyun

https://my.oschina.net/u/867417/blog/758690

从explain开始说起吧，很显然第一个sql语句压根没用任何索引（key列内什么都没有）！第二个倒是用到索引，却是主键索引，并非你添加的fulltext索引！接下来，分析下原因：sql1：执行步骤：先s_a和s_a_t两表笛卡尔集，然后筛选满足on条件的，接着在从结果集中筛选满足where字句的；该过程中处理的记录条目为69*105479，并且未用到任何索引，未用到的原因可能是你先定义了一个复合索引a_concent_split（a_title_split，a_content_split），然后又定义了一个a_content_split2（a_content_split），当引擎执行查找优化时候会先用到a_content_split，可是又由于复合索引是从最左边开始（不能跳过第一个字段），而你却忽略了a_title_split字段，故未能正常使用索引。sql2：执行步骤：先调用where字句对s_a表进行筛选形成新的s_a表，然后与s_a_t表笛卡尔积，再利用on字句筛选，最后再次利用where字句形成最终结果集；经过第一个where，该过程处理结果集会大幅少于sql1，并且该过程还用到了主键索引。你所设置的fulltext索引再次没有用到，原因是like字句中开始部分为模糊匹配%时候用不了全文索引，这与fulltext存储机制有关。另，你说的删除速度慢，原因：设置fulltext字段设置太多，fulltext索引在更新删除大量数据时候，需要同步更改索引，你的三个fulltext压力太大！改进方法：1、删除a_content_split索引重试 2、在删除时候打开delay_key_write变量有关fulltext比较复杂，用的时候要谨慎设置，还有很多参数也对其有影响另外sql语句中外连接有关on where字句也是个比较绕的地方，两者你都占了，唉，所以我写的略复杂，前天看到该问题，思忖两天这才作答望有结果了予以回复交流！

---