这里的深度优化是指,除了建索引、左匹配索引等等其他的优化手段。
文章涉及到操作系统连接数、IO、Mysql本身的某些参数设置,值得记录下来。
innodb_thread_concurrency=32
表示SQL经过解析后,允许同时有32个线程去innodb引擎取数据,如果超过32个,则需要排队;
值太大会产生热点数据,global锁争用严重,影响性能
query_cache_type=0
query_cache_size=0
缓存查询,5.6默认关闭,在应用层实现,比如MC、redis
root@master 12:51: [(none)]> show global status like '%log_wait%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| Innodb_log_waits | 0 |
+------------------+-------+
1 row in set (0.00 sec)
root@master 12:54: [(none)]> show global status like '%Innodb_os_log_written%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Innodb_os_log_written | 1024 |
+-----------------------+-------+
1 row in set (0.00 sec)
#此参数大小可作为设置日志文件size大小参考值
syn_queue取64和tcp_max_sync_backlog最大者,默认是1024,当瞬时很多连接进来这个参数会进行限制,否则太大容易消耗资源
accept queue取back_log和somaxconn最小者,用来防止丢包,当瞬时很多连接进来达到上限后,后来连接将超时触发重传机制
当有3000个连接进来,将队列accept queue占满,应用还没来得及将请求从队列中取出,剩下的2700个连接将被拒绝,每取走一个请求(一个连接,mysql一个线程一个连接),将创建一个thread线程
net.ipv4.tcp_max_sync_backlog= 8192 类似活动场所
sync接收队列的长度,默认是1024,当mysql在很短时间内得到很多的请求,需要增加,太大会消耗资源,太小的话会在show processlist出现未认证错误
net.core.somaxconn=1024 类似活动场所中的座位数
尽可能防止丢包,超过这个值会触发超时或者重传,限制在net.ipv4.ip_local_port_range这个范围之内
如果一个用户的请求数据超过64MB(比如排序),就会申请临时空间,放到硬盘上
如果3000个用户同时连上mysql,最小需要内存3000256KB=750M,最大需要内存300064MB=192G,如果innodb_buffer_pool_size是80GB,可用内存不到48G,192GB>48GB,将会产生SWAP,此时将会影响性能
连接数过高,不一定带来吞吐量的提高,而且可能占用更多的系统资源
一个DB 3W QPS计算,前端有100个web服务器,每个web服务器需要300个QPS,每个QPS占用时间=网络来回时间+SQL执行时间,以20ms计算,需要6个连接数(300/1000/20ms=6)
示例1:有100台web服务器,PHP/JAVA的最大连接数可设置为:3000/100=30
示例2:有30台web服务器,要扩容到60台,web服务器连接数怎么配置?web服务器最大连接数:之前是3000/30=100,现在3000/60=50即可
root@master 14:44: [(none)]> show variables like '%table_open_cache';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| table_open_cache | 1024 |
+------------------+-------+
1 row in set (0.00 sec)
root@master 14:46: [(none)]> show global status like 'open%tables%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 19 |
| Opened_tables | 113 |
+---------------+-------+
2 rows in set (0.00 sec)
可以考虑设置为max_connections或者max_connections*查询同时用到的表个数或者
1.innodb_flush_log_at_trx_commit=1
0,不管有没有提交,每秒钟都写到binlog日志里
1,每次提交事务,都会把log buffer的内容写到磁盘里去,对日志文件做到磁盘刷新,安全最好
2,每次提交事务,都写到操作系统缓存,由OS刷新到磁盘,性能最好
https://blog.csdn.net/zengxuewen2045/article/details/51476186
2.sync_binlog=1
0,事务提交后,mysql不做fsync之类的刷盘,由文件系统来决定什么落盘
n,多少次提交,每n次提交持久化磁盘
生产设为1
3.日志写盘过程
1)三个update会话,三个线程都会产生的操作日志
2 )commit后提交到公共的cache中,三个进程之间不能相互看到对方的操作内容
3)经过write写入到标准I/O cache中,也就是文件系统句柄,线程缓存
4)如果需要让其他线程看到文件句柄内容,就需要通过flush刷新到全局可见文件系统缓存
5)最后最重的一步是将内存数据sync落盘
https://www.cnblogs.com/jenvid/p/8994831.html