MySQL 建立连接的过程，成本是很高的。除了正常的网络连接三次握手外，还需要做登录权限判断和获得这个连接的数据读写权限
max_connections 参数，用来控制一个 MySQL 实例同时存在的连接数的上限，超过这个值，系统就会拒绝接下来的连接请求，并报错提示“Too many connections”，在机器负载比较高的时候，处理现有请求的时间变长，每个连接保持的时间也更长。这时，再有新建连接的话，就可能会超过 max_connections 的限制，如果我们把它改得太大，让更多的连接都可以进来，那么系统的负载可能会进一步加大，大量的资源耗费在权限验证等逻辑上，结果可能是适得其反，已经连接的线程拿不到 CPU 资源去执行业务的 SQL 请求
如果连接数问题，可以考虑show processlist 的结果里 kill connection 主动踢掉一些不需要保持的连接
wait_timeout 参数表示的是，一个线程空闲 wait_timeout 这么多秒之后，就会被 MySQL 直接断开连接
查 information_schema 库的 innodb_trx 表，trx_mysql_thread_id=4，表示 id=4 的线程还处在事务中，如果是连接数过多，你可以优先断开事务外空闲太久的连接；如果这样还不够，再考虑断开事务内空闲太久的连接
从服务端断开连接使用的是 kill connection + id 的命令， 一个客户端处于 sleep 状态时，它的连接被服务端主动断开后，这个客户端并不会马上知道。直到客户端在发起下一个请求的时候，才会收到这样的报错“ERROR 2013 (HY000): Lost connection to MySQL server during query”
业务代码会在短时间内先大量申请数据库连接做备用，让数据库跳过权限验证阶段，使用–skip-grant-tables 参数启动
一类是由新出现的慢查询(索引没有设计好，查询语句没写好，索引选择错误)导致的，一类是由 QPS（每秒查询数）突增导致的，粗暴断连，业务下线，重写SQL等解决
做好 SQL 审计
事务执行过程中，先把日志写到 binlog cache，事务提交的时候，执行器把 binlog cache 里的完整事务写入到 binlog 中，并清空 binlog cache，每个线程有自己 binlog cache，但是共用同一份 binlog 文件
write，指的就是指把日志写入到文件系统的 page cache
fsync，才是将数据持久化到磁盘的操作
sync_binlog：0 write; 1 fsync; n n个事务后才fsync 设置根据性能和持久性的权衡，n大则可能丢失部分数据
事务在执行过程中，生成的 redo log 先写到 redo log buffer（MySQL 进程内存中） -》write到磁盘-》fsync到硬盘
innodb_flush_log_at_trx_commit 0 log buffer; 1 write 到磁盘; 2 写到page cache
InnoDB 有一个后台线程，每隔 1 秒，就会把 redo log buffer 中的日志，调用 write 写到文件系统的 page cache，然后调用 fsync 持久化到磁盘，或者通过事务提交或buffer容量占比触发
两阶段提交的时候说过，时序上 redo log 先 prepare， 再写 binlog，最后再把 redo log commit，只要 redo log 和 binlog 保证持久化到磁盘，就能确保 MySQL 异常重启后，数据可以恢复
MySQL 的“双 1”配置，指的就是 sync_binlog 和 innodb_flush_log_at_trx_commit 都设置成 1。也就是说，一个事务完整提交前，需要等待两次刷盘，一次是 redo log（prepare 阶段），一次是 binlog
WAL 机制主要得益于两个方面：redo log 和 binlog 都是顺序写，磁盘的顺序写比随机写速度要快；组提交机制，可以大幅度降低磁盘的 IOPS 消耗
