它的建议是机器核数乘以 2 加 1。也就是说，4 核的机器，连接池维护 9 个连接就够了。
这个公式从一定程度上来说对其他数据库也是适用的。
为什么有的情况下，减少连接数反而会提升吞吐量呢？
为什么建议设置的连接池大小要跟 CPU 的核数相关呢？
每一个连接，服务端都需要创建一个线程去处理它。连接数越多，服务端创建的线程数就越多。
CPU的核数是有限的，执行多个线程，频繁切换（线程）上下文会造成比较大的性能开销。
不管是数据库本身的配置，还是按照这个数据库服务的操作系统的配置，
对配置进行优化，最终的目的都是使硬件本身的性能更好发挥，包括CPU、内存、磁盘、网络。
在之前的内容中也接触了很多的MySQL和InnoDB的配置参数，包括各种开关和数值的配置，
大多数参数都提供了一个默认值，比如默认的buffer_pool_size，默认的页大小，InnoDB的并发线程数等等。
这些默认配置可以瞒住大部分情况的需求，除非有特殊的需求，在清楚参数的含义时再去修改它。
修改配置的工作一般由专业的DBA完成。
这是官网系统的参数列表，需要时再做参考：
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html
除了合理设置服务端连接数和客户端连接池大小外，还有哪些减少客户端和数据库服务端的连接数的方案呢？
可以引入缓存。
三、缓存——架构优化
3.1 缓存
在应用的并发数非常大的情况下，如果没有缓存，会造成两个问题：
一是会给数据库带来很大压力，二是对于应用来说操作数据的速度也会受影响。
可以采用第三方缓存来解决这个问题，比如 Redis。
运行独立的缓存服务，属于架构层面的优化
为了减少单台数据库服务器的读写压力，在架构层面还可以做哪些其他优化措施？
还可以采取主从复制、分库分表等方案。
四、优化器——SQL语句分析优化
优化器就是对我们的 SQL 语句进行分析，生成执行计划。
4.1 慢查询日志(slow query log)
我们可以通过慢查询日志知道服务中哪些SQL语句比较慢。
因为开启慢查询日志是有代价的（和bin log、optimizer-trace一样），所以默认关闭。
show variables like '%slow_query%';
除了这个开关，还有一个参数，控制执行多久的SQL才被记录到慢日志，默认是10秒：
show variables like '%long_query%';
可以直接动态修改参数（重启后失效）：
set @@global.slow_query_log=1; -- 慢查询日志开关 1 开启，0 关闭，重启后失效
set @@global.long_query_time=3; -- mysql 默认的慢查询时间是 10 秒，另开一个窗口后才会查到最新值
或者修改配置文件 my.cnf，让配置永久生效。
以下配置定义了慢查询日志的开关、慢查询的时间、慢日志文件的存放路径。
slow_query_log = ON
long_query_time=2
slow_query_log_file =/var/lib/mysql/localhost-slow.log
show global status like 'slow_queries'; -- 查看有多少慢查询
show variables like '%slow_query%'; -- 获取慢日志目录
虽然有了慢日志，但是慢日志记录了所有超过设定值的慢查询，如何统计分析呢？总不能一条一条数。
MySQL提供了mysqldumpslow的工具，在MySQL的bin目录下。
例如:查询用时最多的20条慢SQL:
mysqldumpslow -s t -t 20 -g 'select' /var/lib/mysql/localhost-slow.log
Count：代表这条SQL被执行了多少次；
Time：代表执行的时间，括号内是累计时间；
Lock：代表锁定的时间，括号是累计锁定时间；
Rows：代表返回的记录数，括号是累计；
4.2 show profile
除了慢查询日志，还有show profile工具可以使用
https://dev.mysql.com/doc/refman/5.7/en/show-profile.html
show profile可以查看SQL语句执行的时使用的资源，比如CPU、IO的消耗情况。
查看是否开启：
select @@profiling;
若未开启则手动开启：
set @@profiling=1;
查看 profile 统计
show profiles;（命令最后带一个 s）
查看最后一个 SQL 的执行详细信息，从中找出耗时较多的环节（没有 s）。
show profile;
此处时间6.2E-5表示小数点左移 5 位，代表 0.000062 秒。
也可以根据 ID 查看执行详细信息，在后面带上 for query + ID。
show profile for query 1;
除了慢日志和 show profile，如果要分析出当前数据库中执行的慢的 SQL，还可以
通过查看运行线程状态和服务器运行信息、存储引擎信息来分析。
其他系统命令
show processlist 运行线程
show processlist;
用于显示用户运行线程。可以根据 id 号 kill 线程。
也可以查表，效果一样：
select * from information_schema.processlist;
Id : 线程的唯一标志，可以根据它 kill 线程
User : 启动这个线程的用户，普通用户只能看到自己的线程
db : 操作的数据库
show status 服务器运行状态
SHOW STATUS 用于查看 MySQL 服务器运行状态（重启后会清空），有 session 和 global 两种作用域，格式：参数-值。
可以用 like 带通配符过滤。
SHOW GLOBAL STATUS LIKE 'com_select'; -- 查看 select 次数
show engine 存储引擎运行信息
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;
其实很多开源的慢查询日志监控工具，他们的原理其实也都是读取的系统的变量和状态。
那么，现在我们已经知道哪些 SQL 慢了，为什么慢呢？慢在哪里？
MySQL 提供了一个执行计划的工具，
通过 EXPLAIN 我们可以模拟优化器执行 SQL 查询语句的过程，来知道 MySQL 是
怎么处理一条 SQL 语句的。通过这种方式我们可以分析语句或者表的性能瓶颈。
4.3 EXPLAIN 执行计划
先创建三张表。一张课程表，一张老师表。
先创建如下三张表以供测试。三张表没有任何索引。
CREATE TABLE `course` (
`cid` int(3) DEFAULT NULL,
`cname` varchar(20) DEFAULT NULL,
`tid` int(3) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `teacher` (
`tid` int(3) DEFAULT NULL,
`tname` varchar(20) DEFAULT NULL,
`tcid` int(3) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
CREATE TABLE `teacher_contact` (
`tcid` int(3) DEFAULT NULL,
`phone` varchar(200) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
1）id
执行计划中id不同
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 = 'java'
)
);
-- 查询 java 课程的老师手机号
SQL执行结果：
可以看到执行计划中的id值不同，在id 值不同的时候，会先查询 id 值大的（先大后小）。
查询顺序：course c——teacher t——teacher_contact tc。
子查询只能以这种方式进行，只有拿到内层的结果之后才能进行外层的查询。
执行计划中id相同
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 为 2，或者联系表 ID 为 3 的老师
id 值相同时，表的查询顺序是从上往下顺序执行。
例如这次查询的 id 都是 1，查询的顺序是 teacher t（3 条）——teacher_contact tc（3 条）——course c（4 条）。
尝试对 teacher 表插入 3 条数据后：
INSERT INTO `teacher`
VALUES
(4, 'John', 4);
INSERT INTO `teacher`
VALUES
(5, 'Tyler', 5);
INSERT INTO `teacher`
VALUES
(6, 'David', 6);
COMMIT;
id 也都是 1，但是从上往下查询顺序变成了：teacher_contact tc（3 条）——course c（4 条）——teacher t（6 条）。
注意，为什么和插入三条数据前的执行顺序不同了？
这是mysql因为对笛卡尔积的处理。
假如有 a、b、c 三张表，分别有 2、3、4 条数据，如果做三张表的联合查询，
当查询顺序是 a→b→c 的时候，它的笛卡尔积是：2*3*4 = 6*4 = 24。
如果查询顺序是 c→b→a，它的笛卡尔积是 4*3*2 = 12*2 = 24。
因为 MySQL 要把查询的结果，包括中间结果和最终结果都保存到内存，
所以 MySQL会优先选择中间结果数据量比较小的顺序进行查询。
所以最终联表查询的顺序是 a→b→ c。
这就是插入数据影响的执行顺序的原因。（小表驱动大表的思想）
既有相同也有不同
如果 ID 有相同也有不同，就是 ID 不同的先大后小，ID 相同的从上往下。
2）select type 查询类型
SIMPLE ：简单查询，不包含子查询，不包含关联查询 union。
PRIMARY
子查询 SQL 语句中的主查询，也就是最外面的那层查询。
SUBQUERY
子查询中所有的内层查询都是 SUBQUERY 类型的。
DERIVED
衍生查询，表示在得到最终查询结果之前会用到临时表。
UNION
用到了 UNION 查询。
UNION RESULT
主要是显示哪些表之间存在 UNION 查询。<union2,3>代表 id=2 和 id=3 的查询存在 UNION。
3）type 连接类型
https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain-join-types
在常用的链接类型中（效率高低排序）：system > const > eq_ref > ref > range > index > all
这 里 并 没 有 列 举 全 部 （ 其 他 ： fulltext 、 ref_or_null 、 index_merger 、unique_subquery、index_subquery）。
除了all，都能用到索引。
const
条件为主键索引或者唯一索引，且只能查到一条数据的 SQL。
system 是 const 的一种特例，只有一行满足条件。例如：只有一条数据的系统表。不过在我们开发应用时基本不会去查系统表。
eq_ref
通常出现在多表的 join 查询，表示对于前表的每一个结果,，都只能匹配到后表的一行结果。
一般是唯一性索引的查询（UNIQUE 或 PRIMARY KEY）。
eq_ref 是除 const 之外最好的访问类型。
DELETE FROM teacher where tid in (4,5,6);
commit; -- 删除多余的三条记录
ALTER TABLE teacher_contact ADD PRIMARY KEY(tcid);
-- 为 teacher_contact 表的 tcid 创建主键索引。
ALTER TABLE teacher ADD INDEX idx_tcid (tcid);
-- 为 teacher 表的 tcid 创建普通索引。
以上三种 system，const，eq_ref，都是可遇而不可求的，基本上很难优化到这个状态。
ref
查询用到了非唯一性索引，或者关联操作只使用了索引的最左前缀。
例如：使用 tcid 上的普通索引查询：
range
索引范围扫描。
如果 where 后面是条件是索引，且范围为 between and 或 <或 > 或 >= 或 <=或 in 这些，type 类型就为 range。
注意 没有索引type就是ALL 全表扫描了。
index
Full Index Scan，查询全部索引中的数据（比不走索引要快）。
all
Full Table Scan，如果没有索引或者没有用到索引，type 就是 ALL。代表全表扫描。
NULL
不用访问表或者索引就能得到结果，例如：
EXPLAIN select 1 from dual where 1=1;
小结：
一般来说，需要保证查询至少达到 range 级别，最好能达到 ref。
ALL（全表扫描）和 index（查询全部索引）都是需要优化的。
4) possible_key、key
possible_key : 可能用到的索引
key : 实际用到的索引
如果是 NULL 就代表没有用到索引。
possible_key 可以有一个或者多个，可能用到索引并不代表一定用到索引。
possible_key 为空，key 可能有值吗？
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);--为name和phone建立联合索引
explain select phone from user_innodb where phone='126'; --以索引为条件查询建立了索引的字段
因此，是有可能的，这是使用到了覆盖索引的情况（无需回表）。
如果优化时，通过分析发现没有用到索引，就要检查 SQL 或者创建索引。
5）key_len
索引的长度（使用的字节数）。跟索引字段的类型、长度有关。
6）rows
MySQL 认为扫描多少行才能返回请求的数据，是一个预估值。一般来说行数越少越好。
7）filtered
这个字段表示存储引擎返回的数据在 server 层过滤后，剩下多少满足查询的记录数量的比例，它是一个百分比。
8）ref
使用哪个列或者常数和索引一起从表中筛选数据。
9）Extra
执行计划给出的额外的信息说明。
using index：
用到了覆盖索引，不需要回表。
using where：
使用了 where 过滤，表示存储引擎返回的记录并不是所有的都满足查询条件，
需要在 server 层进行过滤（跟是否使用索引没有关系）。
Using index condition（索引条件下推）：使用到了第二篇中提到的索引条件下推
using filesort：不能使用索引来排序，用到了额外的排序（跟磁盘或文件没有关系）。需要优化。
using temporary ：用到了临时表。
比如：
distinct 非索引列：
EXPLAIN select DISTINCT(tid) from teacher t;
group by 非索引列：
EXPLAIN select tname from teacher group by tname;
使用 join 的时候，group 任意列：
EXPLAIN select t.tid from teacher t join course c on t.tid = c.tid group by t.tid;
总结一下，模拟优化器执行 SQL 查询语句的过程，来知道 MySQL 是怎么处理一条 SQL 语句的。
通过这种方式我们可以分析语句或者表的性能瓶颈。
分析出问题之后，就是对 SQL 语句进行针对性的具体优化。
五、存储引擎
5.1 存储引擎的选择
为不同的业务表选择不同的存储引擎。比如查询插入操作多或事物一致性要求低的用MyISAM,临时数据用Memory，常规的并发大更新多的表用InnoDB。
5.2 分区或者分表
分区不推荐。
交易历史表：在年底为下一年度建立12个分区，每个月一个分区。
渠道交易表：分成当日表；当月表；历史表，历史表再做分区。
5.3 字段定义
原则：使用可以正确存储数据的最小数据类型，为每一列选择合适的字段类型。
5.3.1 整数类型
INT有8种类型，不同类型的最大存储范围是不一样的。
性别？用TINYINT，因为ENUM也是整形存储。
5.3.2 字符类型
变长情况下，varchar更节省时间，但是对于varchar字段，需要一个字节来记录长度。
固定长度的用char，不要用varchar。
5.3.3 非空
非空字段尽量定义成NOT NULL，提供默认值，或者使用特殊值、控制代替null。
NULL类型的存储、优化、使用都会存在问题。
5.3.4 不要用外键、触发器、视图
降低了可读性；
影响数据库性能，应该把计算的事交给程序，数据库只做存储；
数据的完整性应该在程序中检查。
5.3.5 大文件存储
不要用数据库存储图片（比如base64）或者大文件；
把文件放在NAS上，数据库只存储URI，在应用中配置NAS服务器地址。
5.3.6 表拆分
将不常用的字段拆分出去，避免列数过多和数据量过大。
比如在业务系统中，要记录所有接收和发送的消息，这个消息是XML格式的，用blob或者text存储，用来追踪和判断重复，可以建立一张表专门用来存储报文。
六、总结：优化体系
如图，对于优化的方向，优化难度从上到下是依次增加的，但是优化得到的效益却不一定。
因此我们优化的方向选择尽量从上而下开始。
除了对于代码、SQL 语句、表定义、架构、配置优化之外，业务层面的优化也不能忽视。举几个例子：
1）双十一时，为什么在凌晨精致查询今天之外的账单？
这是一种降级措施，用来保证当前最核心的业务。
2）为什么在双十一之前，提前一个多星期就已经有双十一的预售价格了？
这是通过预售的手段实现了分流。
在应用层面同样有很多其他的方案来优化，达到尽量减轻数据库的压力的目的，比
如限流，或者引入 MQ 削峰，等等。
