一条sql的具体执行过程
连接
我们怎么查看MySQL当前有多少个连接？
可以用show status命令，模糊匹配Thread，
Show global status like "Thread%"
show global variables like 'wait timeout';—非交互式超时时间，如JDBC程序
show global variables like 'interactive timeout';"交互式超时时间，如数据库工具默认都是28800秒，8小时。
既然连接消耗资源，MySQL服务允许的最大连接数（也就是并发数）默认是多少呢？在5.7版本中默认是151个，最大可以设置成100000
MySQL中的参数（变量）分为session和global级别，分别是在当前会话中生效和 全局生效,但是并不是每个参数都有两个级别，比如max_connections就只有全局级别。当没有带参数的时候，默认是session级别，包括查询和修改。比如修改了一个参数以后，在本窗口査询已经生效，但是其他窗口不生效：所以，如果只是临时修改，建议修改session级别。如果需要在其他会话中生效，必须显式地加上global参数。
缓存
缓存没有生效，为什么？MySQL的缓存默认是关闭的。show variables like “query_cache%”!;
主要是因为MySQL自带的缓存的应用场景有限，第一个是它要求SQL语句必须一 模一样，中间多一个空格，字母大小写不同都被认为是不同的的SQL。第二个是表里面任何一条数据发生变化的时候，这张表所有缓存都会失效，所以对 于有大量数据更新的应用，也不适合。
词法解析与语法解析
词法分析
就是把一个完整的SQL语句打碎成一个个的单词。
select name from user where id = 1;
它会打碎成8个符号，每个符号是什么类型，从哪里开始到哪里结束。
语法分析
语法分析会对SQL做一些语法检查，比如单引号有没有闭合,然后根据MySQL定义的语法规则，根据SQL语句生成一个数据结构。这个数据结构我 们把它叫做解析树
预处理器
实际上还是在解析的时候报错，解析SQL的环节里面有个预处理器。它会检査生成的解析树，解决解析器无法解析的语义。
它会检査表和列名是否存在，检査名字和别名，保证没有歧义。预处理之后得到一个新的解析树。
査询优化器
査询优化器的模块(Optimizer)。
査询优化器的目的就是根据解析树生成不同的执行计划(Execution Plan),然后选择一种最优的执行计划，MySQL里面使用的是基于开销(cost)的优化器，那种执行计划开销最小，就用哪种。可以使用这个命令査看査询的开销：
show status like 'Last_query_cost';
error 1040: Too many connections的错误。这个是超
过了服务端设置的最大并发连接数。
优化的思路
1、从服务端来说，我们可以增加服务端的可用连接数。
如果有多个应用或者很多请求同时访问数据库，连接数不够的时候，我们可以:
(1)增加可用连接数，修改max connections的大小:
show variables like max_connections; ・・修改最大连接数，当有多个应用连接的时候
(2)或者，或者及时释放不活动的连接。交互式和非交互式的客户端的默认超时时
间都是28800秒，8小时，我们可以把这个值调小。
show global variables like ‘wait_timeout’
引入连接池，实现对连接重用
2 缓存层面
使用缓存 redis
集群
主从复制
（1）master服务器将数据的改变记录二进制binlog日志，当master上的数据发生改变时，则将其改变写入二进制日志中；
（2）slave服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/OThread请求master二进制事件
（3）同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至从节点本地的中继日志中，从节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最后I/OThread和SQLThread将进入睡眠状态，等待下一次被唤醒。
也就是说：
- 从库会生成两个线程,一个I/O线程,一个SQL线程;
- I/O线程会去请求主库的binlog,并将得到的binlog写到本地的relay-log(中继日志)文件中;
- 主库会生成一个log dump线程,用来给从库I/O线程传binlog;
- SQL线程,会读取relay log文件中的日志,并解析成sql语句逐一执行;
修改配置
修改配置的工作一般由专业的DBA完成。也有一些工具可以给出
推荐值。
慢日志查询
1 打开慢日志开关
因为开启慢查询日志是有代价的（跟binlog—样），所以它默认
是关闭的：
show variables like ‘slow_query’
除了这个开关，还有一个参数，控制执行超过多长时间的SQL才记录到慢日志，默
认是10秒。如果改成0秒的话就是记录所有的SQL。
show variables like ‘%long_query%’;
set @@global.slow_query_log=l;・.1开启，0关闭，重启后失效
set @@global.long_query_time=3;-默认10秒，另开一个窗口后才会查到最新值 show variables like ,%long_queiy%1; show variables like '%slow_query%‘;
修改配置文件my.cnfo
以下配置定义了慢査询日志的开关、慢査询的时间、日志文件的存放路径。
slowquerylog = ON long_qu eiy_time=2 slowqueiylogfile =/var/lib/mysql/localhost-slow.log
模拟慢査询：
慢日志分析 1、日志内容
less /var/lib/mysql/localhost-slow.log
MySQL提供了 mysqldumpslow的工具，在MySQL的bin目录下。
Mysqldumpslow – help
show engine存储引擎运行信息
show engine用来显示存储引擎的当前运行信息，包括事务持有的表锁、行锁信息;
事务的锁等待情况；线程信号量等待；文件IO请求；buffer pool统计信息。
