它的建议是机器核数乘以 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 削峰,等等。