第一个环节是客户端连接到服务端，连接这一块有可能会出现什么样的性能问题？ 有可能是服务端连接数不够导致应用程序获取不到连接。
1、从服务端来说，我们可以增加服务端的可用连接数。
（1）修改配置参数增加可用连接数，修改 max_connections 的大小：
show variables like 'max_connections'; -- 修改最大连接数，当有多个应用连接的时候（2）或者，或者及时释放不活动的连接。交互式和非交互式的客户端的默认超时时 间都是 28800 秒，8 小时，我们可以把这个值调小。
show global variables like 'wait_timeout'; -- 及时释放不活动的连接，注意不要释放连接池还在使用的连接2、从客户端来说，可以减少从服务端获取的连接数，如果我们想要不是每一次执行 SQL 都创建一个新的连接，应该怎么做？
这个时候我们可以引入连接池，实现连接的重用。
它的建议是机器核数乘以 2 加 1。也就是说，4 核的机器，连接池维护 9 个连接就 够了。这个公式从一定程度上来说对其他数据库也是适用的。这里面还有一个减少连接 池大小实现提升并发度和吞吐量的案例。
在应用系统的并发数非常大的情况下，如果没有缓存，会造成两个问题：一方面是 会给数据库带来很大的压力。另一方面，从应用的层面来说，操作数据的速度也会受到 影响。
运行独立的缓存服务，属于架构层面的优化。
如果单台数据库服务满足不了访问需求，那我们可以做数据库的集群方案。
集群的话必然会面临一个问题，就是不同的节点之间数据一致性的问题。如果同时 读写多台数据库节点，怎么让所有的节点数据保持一致？
这个时候我们需要用到复制技术（replication），被复制的节点称为 master，复制 的节点称为 slave。slave 本身也可以作为其他节点的数据来源，这个叫做级联复制。
主从复制是怎么实现的呢？更新语句会记录 binlog，它是一种逻辑日志。
有了这个 binlog，从服务器会获取主服务器的 binlog 文件，然后解析里面的 SQL 语句，在从服务器上面执行一遍，保持主从的数据一致。
这里面涉及到三个线程，连接到 master 获取 binlog，并且解析 binlog 写入中继日 志，这个线程叫做 I/O 线程。
Master 节点上有一个 log dump 线程，是用来发送 binlog 给 slave 的。
从库的 SQL 线程，是用来读取 relay log，把数据写入到数据库的。
所以，基于主从复制的原理，我们需要弄明白，主从复制到底慢在哪里？
在早期的 MySQL 中，slave 的 SQL 线程是单线程。master 可以支持 SQL 语句并执行。配置了多少的最大连接数就是最多同时多少个 SQL 并行执行。
而 slave 的 SQL 却只能单线程排队执行，在主库并发量很大的情况下，同步数据肯 定会出现延迟。
在主从复制的过程中，MySQL 默认是异步复制的。也就是说， 对于主节点来说，写入 binlog，事务结束，就返回给客户端了。对于 slave 来说，接收 到 binlog，就完事儿了，master 不关心 slave 的数据有没有写入成功。
如果要减少延迟，是不是可以等待全部从库的事务执行完毕，才返回给客户端呢。这样的方式叫做全同步复制。从库写完数据，主库才返会给客户端。
这种方式虽然可以保证在读之前，数据已经同步成功了，但是带来的副作用大家应 该能想到，事务执行的时间会变长，它会导致 master 节点性能下降。
介于异步复制和全同步复制之间，还有一种半同步复制的方式。
主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库 接收到 binlog 并写到 relay log 中才返回给客户端。master 不会等待很长的时间，但是 返回给客户端的时候，数据就即将写入成功了，因为它只剩最后一步了：就是读取 relay log，写入从库。
使用插件执行该方案：
-- 主库执行
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
set global rpl_semi_sync_master_enabled=1;
show variables like '%semi_sync%';
-- 从库执行
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
set global rpl_semi_sync_slave_enabled=1;
show global variables like '%semi%';相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延 迟，它需要等待一个 slave 写入中继日志，这里多了一个网络交互的过程，所以，半同步 复制最好在低延时的网络中使用。
这个是从主库和从库连接的角度，来保证 slave 数据的写入。
所以，我们可以把那些在主库上并行执行的事务，分为一个组，并且给他们编号， 这一个组的事务在从库上面也可以并行执行。这个编号，我们把它叫做 GTID（Global Transaction Identifiers），这种主从复制的方式，我们把它叫做基于 GTID 的复制。
如果我们要使用 GTID 复制，我们可以通过修改配置参数打开它，默认是关闭的：
show global variables like 'gtid_mode'无论是优化 master 和 slave 的连接方式，还是让从库可以并行执行 SQL，都是从数 据库的层面去解决主从复制延迟的问题。
我们在做了主从复制之后，如果单个 master 节点或者单张表存储的数据过大的时 候，比如一张表有上亿的数据，单表的查询性能还是会下降，我们要进一步对单台数据 库节点的数据分型拆分，这个就是分库分表。
垂直分库，减少并发压力。水平分表，解决存储瓶颈。 垂直分库的做法，把一个数据库按照业务拆分成不同的数据库：
水平分库分表的做法，把单张表的数据按照一定的规则分布到多个数据库。
传统的 HAProxy + keepalived 的方案，基于主从复制。
基于 NDB 集群存储引擎的 MySQL Cluster。
一种多主同步复制的集群方案。
MMM 和 MHA 都是对外提供一个虚拟 IP，并且监控主节点和从节点，当主节点发 生故障的时候，需要把一个从节点提升为主节点，并且把从节点里面比主节点缺少的数 据补上，把 VIP 指向新的主节点。
MySQL 5.7.17 版本推出的 InnoDB Cluster，也叫 MySQL Group Replicatioin （MGR），这个套件里面包括了 mysql shell 和 mysql-route。
总结一下： 高可用 HA 方案需要解决的问题都是当一个 master 节点宕机的时候，如何提升一个 数据最新的 slave 成为 master。如果同时运行多个 master，又必须要解决 master 之间 数据复制，以及对于客户端来说连接路由的问题。
因为开启慢查询日志是有代价的（跟 bin log、optimizer-trace 一样），所以它默 认是关闭的：
show variables like 'slow_query%';除了这个开关，还有一个参数，控制执行超过多长时间的 SQL 才记录到慢日志，默 认是 10 秒。
set @@global.slow_query_log=1; -- 1 开启，0 关闭，重启后失效
set @@global.long_query_time=3; -- mysql 默认的慢查询时间是 10 秒，另开一个窗口后才会查到最新值
show variables like '%long_query%';
show variables like '%slow_query%';或者修改配置文件 my.cnf。 以下配置定义了慢查询日志的开关、慢查询的时间、日志文件的存放路径。
slow_query_log = ON
long_query_time=2
slow_query_log_file =/var/lib/mysql/localhost-slow.log模拟慢查询:
select sleep(10);查询 user_innodb 表的 500 万数据（检查是不是没有索引）。
SELECT * FROM `user_innodb` where phone = '136';show global status like 'slow_queries'; -- 查看有多少慢查询
show variables like '%slow_query%'; -- 获取慢日志目录cat /var/lib/mysql/ localhost-slow.logMySQL 提供了 mysqldumpslow 的工具，在 MySQL 的 bin 目录下。
mysqldumpslow --help
select @@profiling;
set @@profiling=1;show profiles;
查看最后一个 SQL 的执行详细信息，从中找出耗时较多的环节（没有 s）。
show profile;
how profile for query 1;除了慢日志和 show profile，如果要分析出当前数据库中执行的慢的 SQL，还可以 通过查看运行线程状态和服务器运行信息、存储引擎信息来分析。
show processlist;
这是很重要的一个命令，用于显示用户运行线程。可以根据 id 号 kill 线程。
SHOW STATUS 用于查看 MySQL 服务器运行状态（重启后会清空），有 session 和 global 两种作用域，格式：参数-值。
可以用 like带通配符过滤。
SHOW GLOBAL STATUS LIKE 'com_select'; -- 查看 select 次数show engine 用来显示存储引擎的当前运行信息，包括事务持有的表锁、行锁信息； 事务的锁等待情况；线程信号量等待；文件 IO 请求；buffer pool 统计信息。
show engine innodb status;如果需要将监控信息输出到错误信息 error log 中（15 秒钟一次），可以开启输出。
show variables like 'innodb_status_output%'; -- 开启输出：
SET GLOBAL innodb_status_output=ON;
SET GLOBAL innodb_status_output_locks=ON;DROP TABLE IF EXISTS course;
CREATE TABLE `course` (
`cid` int(3) DEFAULT NULL, `cname` varchar(20) DEFAULT NULL, `tid` int(3) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
DROP TABLE IF EXISTS teacher;
CREATE TABLE `teacher` (
`tid` int(3) DEFAULT NULL, `tname` varchar(20) DEFAULT NULL, `tcid` int(3) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
DROP TABLE IF EXISTS teacher_contact;
CREATE TABLE `teacher_contact` (
`tcid` int(3) DEFAULT NULL, `phone` varchar(200) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
INSERT INTO `course` VALUES ('1', 'mysql', '1');
INSERT INTO `course` VALUES ('2', 'jvm', '1');
INSERT INTO `course` VALUES ('3', 'juc', '2');
INSERT INTO `course` VALUES ('4', 'spring', '3');
INSERT INTO `teacher` VALUES ('1', 'qingshan', '1');
INSERT INTO `teacher` VALUES ('2', 'jack', '2');
INSERT INTO `teacher` VALUES ('3', 'mic', '3');
INSERT INTO `teacher_contact` VALUES ('1', '13688888888');
INSERT INTO `teacher_contact` VALUES ('2', '18166669999');
INSERT INTO `teacher_contact` VALUES ('3', '17722225555');id 值不同的时候，先查询 id 值大的（先大后小）
-- 查询 mysql 课程的老师手机号
EXPLAIN SELECT tc.phone
FROM teacher_contact tc
WHERE tcid = (
SELECT tcid
FROM teacher t
WHERE t.tid = (
SELECT c.tid
FROM course c
WHERE c.cname = 'mysql' )
);查询顺序：course c——teacher t——teacher_contact tc。
先查课程表，再查老师表，最后查老师联系方式表。子查询只能以这种方式进行， 只有拿到内层的结果之后才能进行外层的查询。
-- 查询课程 ID 为 2，或者联系表 ID 为 3 的老师
EXPLAIN
SELECT t.tname,c.cname,tc.phone
FROM teacher t, course c, teacher_contact tc
WHERE t.tid = c.tid
AND t.tcid = tc.tcid
AND (c.cid = 2
OR tc.tcid = 3)
id 值相同时，表的查询顺序是从上往下顺序执行。例如这次查询的 id 都是 1，查询 的顺序是 teacher t（3 条）——course c（4 条）——teacher_contact tc（3 条）。
INSERT INTO `teacher` VALUES (4, 'james', 4);
INSERT INTO `teacher` VALUES (5, 'tom', 5);
INSERT INTO `teacher` VALUES (6, 'seven', 6);
COMMIT;
-- （备份）恢复语句
DELETE FROM teacher where tid in (4,5,6);
COMMIT;id 也都是 1，但是从上往下查询顺序变成了：teacher_contact tc（3 条）——teacher t（6 条）——course c（4 条）。
如果 ID 有相同也有不同，就是 ID 不同的先大后小，ID 相同的从上往下。
这里并没有列举全部（其它：DEPENDENT UNION、DEPENDENT SUBQUERY、 MATERIALIZED、UNCACHEABLE SUBQUERY、UNCACHEABLE UNION）。
EXPLAIN SELECT * FROM teacher;
再看一个包含子查询的案例：
-- 查询 mysql 课程的老师手机号
EXPLAIN SELECT tc.phone
FROM teacher_contact tc
WHERE tcid = (
SELECT tcid
FROM teacher t
WHERE t.tid = (
SELECT c.tid
FROM course c
WHERE c.cname = 'mysql' )
);
子查询 SQL 语句中的主查询，也就是最外面的那层查询。
子查询中所有的内层查询都是 SUBQUERY 类型的
-- 查询 ID 为 1 或 2 的老师教授的课程
EXPLAIN SELECT cr.cname
FROM (
SELECT * FROM course WHERE tid = 1
UNION
SELECT * FROM course WHERE tid = 2
) cr衍生查询，表示在得到最终查询结果之前会用到临时表。
对于关联查询，先执行右边的 table（UNION），再执行左边的 table，类型是 DERIVED。
所有的连接类型中，上面的最好，越往下越差。
在常用的链接类型中：system > const > eq_ref > ref > range > index > all
这 里 并 没 有 列 举 全 部 （ 其 他 ： fulltext 、 ref_or_null 、 index_merger 、 unique_subquery、index_subquery）。
以上访问类型除了 all，都能用到索引
DROP TABLE IF EXISTS single_data;
CREATE TABLE single_data(
id int(3) PRIMARY KEY, content varchar(20)
);
insert into single_data values(1,'a');
EXPLAIN SELECT * FROM single_data a where id = 1;
system 是 const 的一种特例，只有一行满足条件。例如：只有一条数据的系统表。
通常出现在多表的 join 查询，表示对于前表的每一个结果,，都只能匹配到后表的 一行结果。一般是唯一性索引的查询（UNIQUE 或 PRIMARY KEY）。
eq_ref 是除 const 之外最好的访问类型。
先删除 teacher 表中多余的数据，teacher_contact 有 3 条数据，teacher 表有 3 条数据。
DELETE FROM teacher where tid in (4,5,6);
commit; -- 备份
INSERT INTO `teacher` VALUES (4, 'james', 4);
INSERT INTO `teacher` VALUES (5, 'tom', 5);
INSERT INTO `teacher` VALUES (6, 'seven', 6);
commit;为 teacher_contact 表的 tcid（第一个字段）创建主键索引
-- ALTER TABLE teacher_contact DROP PRIMARY KEY;
ALTER TABLE teacher_contact ADD PRIMARY KEY(tcid);为 teacher 表的 tcid（第三个字段）创建普通索引。
-- ALTER TABLE teacher DROP INDEX idx_tcid;
ALTER TABLE teacher ADD INDEX idx_tcid (tcid);执行SQL：
select t.tcid from teacher t,teacher_contact tc where t.tcid = tc.tcid
此时的执行计划（teacher_contact 表是 eq_ref）
查询用到了非唯一性索引，或者关联操作只使用了索引的最左前缀。
explain SELECT * FROM teacher where tcid = 3;
索引范围扫描。 如果 where 后面是 between and 或 <或 > 或 >= 或 <=或 in 这些，type 类型就为 range。
不走索引一定是全表扫描（ALL），所以先加上普通索引。
-- ALTER TABLE teacher DROP INDEX idx_tid;
ALTER TABLE teacher ADD INDEX idx_tid (tid);执行范围查询（字段上有普通索引）：
EXPLAIN SELECT * FROM teacher t WHERE t.tid <3; -- 或
EXPLAIN SELECT * FROM teacher t WHERE tid 
IN 查询也是 range（字段有主键索引)
EXPLAIN SELECT * FROM teacher_contact t WHERE tcid in (1,2,3);
Full Index Scan，查询全部索引中的数据（比不走索引要快）。
EXPLAIN SELECT tid FROM teacher;
Full Table Scan，如果没有索引或者没有用到索引，type 就是 ALL。代表全表扫描。
不用访问表或者索引就能得到结果，例如：
一般来说，需要保证查询至少达到 range 级别，最好能达到 ref。 ALL（全表扫描）和 index（查询全部索引）都是需要优化的
可能用到的索引和实际用到的索引。如果是 NULL 就代表没有用到索引。
possible_key 可以有一个或者多个，可能用到索引不代表一定用到索引。
反过来，possible_key 为空，key 可能有值吗?
ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);执行计划（改成 select name 也能用到索引）：
explain select phone from user_innodb where phone='126';
结论：是有可能的（这里是覆盖索引的情况）。 如果通过分析发现没有用到索引，就要检查 SQL 或者创建索引。
索引的长度（使用的字节数）。跟索引字段的类型、长度有关。
MySQL 认为扫描多少行才能返回请求的数据，是一个预估值。一般来说行数越少越 好。
这个字段表示存储引擎返回的数据在 server 层过滤后，剩下多少满足查询的记录数 量的比例，它是一个百分比。
使用哪个列或者常数和索引一起从表中筛选数据。
执行计划给出的额外的信息说明。
用到了覆盖索引，不需要回表。
EXPLAIN SELECT tid FROM teacher ;使用了 where 过滤，表示存储引擎返回的记录并不是所有的都满足查询条件，需要 在 server 层进行过滤（跟是否使用索引没有关系）。
EXPLAIN select * from user_innodb where phone = '13866667777';
不能使用索引来排序，用到了额外的排序（跟磁盘或文件没有关系）。需要优化。
EXPLAIN select * from user_innodb where name ='青山' order by id;
1、distinct (非索引列)
EXPLAIN select DISTINCT(tid) from teacher t;2、group by 非索引列
EXPLAIN select tname from teacher group by tname;3、使用 join 的时候，group 任意列
EXPLAIN select t.tid from teacher t join course c on t.tid = c.tid group by t.tid;
原则：使用可以正确存储数据的最小数据类型。 为每一列选择合适的字段类型：
变长情况下，varchar 更节省空间，但是对于 varchar 字段，需要一个字节来记录长度。
固定长度的用 char，不要用 varchar。
非空字段尽量定义成 NOT NULL，提供默认值，或者使用特殊值、空串代替 null。 NULL 类型的存储、优化、使用都会存在问题。
降低了可读性；
影响数据库性能，应该把把计算的事情交给程序，数据库专心做存储；
数据的完整性应该在程序中检查。
不要用数据库存储图片（比如 base64 编码）或者大文件；
把文件放在 NAS 上，数据库只需要存储 URI（相对路径），在应用中配置 NAS 服 务器地址。
将不常用的字段拆分出去，避免列数过多和数据量过大。
比如在业务系统中，要记录所有接收和发送的消息，这个消息是 XML 格式的，用 blob 或者 text 存储，用来追踪和判断重复，可以建立一张表专门用来存储报文。
