-
2021-01-27 05:10:57
最近的项目需要导入大量的数据,插入的过程中还需要边查询边插入。插入的数据量在100w左右。一开始觉得100w的数据量不大,于是就插啊插,吃了个饭,回来一看,在插入了50多w条数据后,每秒就只能插10条了。。觉得很奇怪,为啥越插越慢呢? 于是就开始分析插入的时间损耗,想到了如下的解决方案:(mysql使用的INNODB引擎)
1.分析是否是由主码,外码,索引造成的插入效率降低
主码:由于主码是每张表必须有的,不能删除。而mysql会对主码自动建立一个索引,这个索引默认是Btree索引,因此每次插入数据要额外的对Btree进行一次插入。这个额外的插入时间复杂度约为log(n)。这个索引无法删除,因此无法优化。但是每次插入的时候,由于主码约束需要检查主码是否出现,这又需要log(n),能否减少这个开销呢?答案是肯定的。我们可以设置主码为自增id AUTO_INCREMENT ,这样数据库里会自动记录当前的自增值,保证不会插入重复的主码,也就避免了主码的重复性检查。
外码:由于我的项目的插入表中存在外码,因此每次插入时需要在另一张表检测外码存在性。这个约束是与业务逻辑相关的,不能随便删除。并且这个时间开销应当是与另一张表大小成正比的常数,不应当越插入越慢才对。所以排除。
索引:为了减少Btree插入的时间损耗,我们可以在建表时先不建索引,先将所有的数据插入。之后我们再向表里添加索引。该方法确实也降低了时间的开销。
经过以上的折腾,再进行测试,发现速度快了一点,但是到了50w条后又开始慢了。看来问题的关键不在这里。于是继续查资料,又发现了个关键问题:
更多相关内容 -
MySQL性能瓶颈排查定位实例详解
2020-12-15 07:37:15本文实例讲述了MySQL性能瓶颈排查定位的方法。分享给大家供大家参考,具体如下: 导读 从一个现场说起,全程解析如何定位性能瓶颈。 排查过程 收到线上某业务后端的MySQL实例负载比较高的告警信息,于是登入服务器... -
MySQL重定位数据目录的方法
2020-12-15 06:52:12MySQL允许重定位数据目录或其中的成员,这里就来介绍重定位MySQL数据目录的方法,对此方面感兴趣的朋友不妨看一下。 重定位MySQL数据目录 MySQL数据目录结构是缺省配置,所有数据库和状态文件均包含其中,然而,你有... -
mysql 无法连接问题的定位和修复过程分享
2020-09-10 22:04:18开发的一款网站防护产品中出现了一个客户端上安装后Mysql每隔一段时间就出现问题,这个问题是客户反馈的,所以需要去复现和定位 -
MySQL性能分析工具——如何快速定位SQL执行慢的原因?
2022-01-22 14:44:03我们在做SQL优化的时候,应该从哪几方面定位SQL执行慢的原因呢?是索引设计的问题?参数配置的问题?还是需要扩容了呢? 本文介绍了比较常用的三种工具来定位和分析慢SQL,本文主要内容如下: 通过慢查询日志定位...本文目录
一、前言
我们在做
SQL
优化的时候,应该从哪几方面定位SQL执行慢的原因呢?是索引设计的问题?参数配置的问题?还是需要扩容了呢?本文介绍了比较常用的三种工具来定位和分析慢SQL,本文主要内容如下:
- 通过慢查询日志定位执行慢的 SQL;
- 使用
EXPLAIN
分析该 SQL 语句是否使用到了索引,以及具体的数据表访问方式; - 使用
SHOW PROFILE
进一步分析SQL的每一步执行时间以及CPU、IO等资源使用情况。
二、慢查询日志定位执行慢的 SQL
慢查询日志是MySQL提供的一种日志记录,它用来记录所有执行时间超过
long_query_time
参数值的SQL。long_query_time
的默认值为10秒,默认情况下执行超过10s的SQL语句,会被记录到慢查询日志中。2.1.开启慢查询日志
在使用前,我们需要先看下慢查询是否已经开启,使用下面这条命令查看是否开启:
show variables like '%slow_query_log%';
slow_query_log=OFF
,表示未开启。slow_query_log=ON
表示慢查询已经开启,如果未开启,通过以下命令开启:set global slow_query_log='ON';
开启后,使用
show variables like '%slow_query_log%'
再来看下是否开启
slow_query_log_file
是慢查询日志文件目录。Mysql支持文件和数据库表两种日志存储方式,默认将日志存储在文件中,使用下面这条命令查看存储方式:
show variables like '%log_output%';
可以修改为存储到数据库表,这样日志信息就会被写入到
mysql.slow_log
表中set global log_output='TABLE';
MySQL数据库同时支持两种日志存储方式,配置的时候以逗号隔开即可
set global log_output='TABLE,FILE';
日志记录到系统的专用日志表中,要比记录到文件耗费更多的系统资源,因此对于需要启用慢查询日志,又需要能够获得更高的系统性能,那么建议优先记录到文件。
2.2.设置慢查询的时间阈值
long_query_time
的默认值为10秒,通过以下命令可以查看慢查询的时间阈值show variables like '%long_query_time%';
如果我们想修改
long_query_time
参数值,通过以下命令即可,假如我们把long_query_time
值设置为1。set global long_query_time = 1;
注意:修改完再次执行show variables like ‘%long_query_time%’,发现还是默认的10S,是不是没有修改成功呢?其实已经修改成功了,此时只需要关闭当前连接,再重新连接就可以了。
使用
set global slow_query_log=1
开启了慢查询日志只对当前数据库生效,如果MySQL重启后则会失效。如果要永久生效,需要修改my.cnf
配置文件,配置文件如下:[mysqld] slow_query_log = 1 # 开启慢查询 slow_query_log_file = /data/mysql/logs/slow.log # 慢查询日期路径 long_query_time = 1 # 慢查询时间阈值 log_timestamps = SYSTEM log_output = FILE
2.3. 慢查询日志介绍
模拟慢查询
如果自己mysql上没有慢查询,可以通过
sleep(N)
函数来模拟慢查询操作,比如下面这条模拟慢查询的语句SELECT *, sleep(3) FROM tb_user WHERE id<4
注意:
sleep(N)
函数表示,每返回一行数据经过WHERE条件判断后,都会触发Sleep函数,比如上面的SQL
语句,返回3条数据,每条阻塞3秒,查询时间总共是9秒。
慢查询日志
有了慢查询日志,可以使用以下命令获取有多少条日志
show global status like '%Slow_queries%';
可以看到现在有两条慢查询,接下来我们来看下慢查询日志具体记录哪些内容
# Time: 2022-01-22T12:56:00.070149Z # User@Host: root[root] @ localhost [] Id: 8 # Query_time: 4.006927 Lock_time: 0.000074 Rows_sent: 4 Rows_examined: 4 SET timestamp=1642856160; SELECT *, sleep(1) FROM tb_user WHERE id<5;
第一行记录的是该条 SQL 语句执行的时间;
第二行记录的是执行该SQL语句的用户和 IP 以及链接 id;
第三行的几个字段解释如下:
- Query_time: duration 语句执行时间,以秒为单位。
- Lock_time: duration 获取锁的时间(以秒为单位)。
- Rows_sent: 发送给 Client 端的行数。
- Rows_examined: 服务器层检查的行数(不计算存储引擎内部的任何处理)
第四行记录是此SQL语句执行时候的时间戳;
第五行就是具体的慢SQL。也是我们需要优化的SQL。
2.4.日志分析工具mysqldumpslow
MySQL 提供了
mysqldumpslow
工具统计慢查询日志。mysqldumpslow
命令的参数如下:- -s:采用 order 排序的方式,排序方式可以有以下几种。分别是 c(访问次数)、t(查询时间)、l(锁定时间)、r(返回记录)、ac(平均查询次数)、al(平均锁定时间)、ar(平均返回记录数)和 at(平均查询时间)。其中 at 为默认排序方式。
- -t:返回前 N 条数据 。
- -g:后面可以是正则表达式,对大小写不敏感。
比如我们想要按照查询时间排序,查看前3条 SQL 语句,这样写即可:
mysqldumpslow -s r -t 3 /var/lib/mysql/a7bb95cee15a-slow.log
得到访问次数最多的5个SQL
mysqldumpslow -s c -t 5 /var/lib/mysql/a7bb95cee15a-slow.log
得到按照时间排序的前5条里面含有左连接的查询语句。
mysqldumpslow -s t -t 10 -g “left join” /var/lib/mysql/a7bb95cee15a-slow.log
另外建议在使用这些命令时结合 | 和more 使用 ,否则有可能出现刷屏的情况。
mysqldumpslow -s r -t 5 /var/lib/mysql/a7bb95cee15a-slow.log | more
三、查询优化神器EXPLAIN命令
MySQL 提供的
EXPLAIN
命令,它可以对SELECT
语句进行分析,并输出 SELECT 执行的详细信息,开发人员可以根据输出的信息对SQL进行有针对性的优化。EXPLAIN
可以帮助我们了解数据表的读取4,l;’]m np[ohfg]'顺序、SELECT 子句的类型、数据表的访问类型、可使用的索引、实际使用的索引、使用的索引长度、上一个表的连接匹配条件、被优化器查询的行的数量olhb.;/及额外的信息(比如是否使用了外部排序,是否使用了临时表等)等。EXPLAIN
使用方式如下,EXPLAIN 命令的输出内容如下:下面对
EXPLAIN
命令的输出各个字段进行说明3.1. id字段
select查询的序列号,表示查询中执行select子句或操作表的顺序。
SQL
执行的顺序是根据 id 从大到小执行的,也就是 id 越大越先执行,当 id 相同时,从上到下执行。比如下面这个
SQL
语句id一样,执行顺序按照从上到下执行。EXPLAIN SELECT u.name,o.title FROM tb_user u JOIN tb_order o ON u.id=o.user_id
下面的这条
SQL
语句,可以看到子查询的id为2,所以这条语句先执行是子查询EXPLAIN SELECT * FROM tb_order WHERE user_id = (SELECT id FROM tb_user WHERE id=1)
3.2. select_type字段
表示查询的类型。常用的值如下表:
select_type字段值 说明 SIMPLE 表示查询语句不包含子查询或union PRIMARY 表示此查询是最外层的查询 UNION 表示此查询是UNION的第二个或后续的查询 DEPENDENT UNION UNION中的第二个或后续的查询语句,使用了外面查询结果 UNION RESULT UNION的结果 SUBQUERY SELECT子查询语句 平时我们最常见的查询类型是
SIMPLE
,表示我们的查询没有子查询也没用到UNION查询。3.3. table字段
输出行所引用的表的名称。
3.4. partitions字段
该列显示的为分区表命中的分区情况。非分区表该字段为空(null)。
3.5. type字段
type字段表示存储引擎查询数据时采用的方式。这个也是我们平时做
SQL
优化重点关注的信息,通过它可以判断出查询是全表扫描还 是基于索引的部分扫描。type 常用属性值如下表所示:type字段值 说明 ALL
全表扫描,性能最差。 index
表示基于索引的全表扫描,先扫描索引再扫描全表数据。 range
表示使用索引范围查询。使用>、>=、<、<=、in等等。 ref
表示采用了非唯一索引,或者是唯一索引的非唯一性前缀 eq_ref
一般情况下出现在多表join查询,表示前面表的每一个记录,都只能匹配后面表的一 行结果。 const
表最多有一个匹配行,因为只有一行,所以这一行中列的值可以被优化器视为常量 system
system 类型一般用于 MyISAM
或Memory
表,属于const
类型的特例上面的这些
type
字段值,执行效率从上至下依次增强。效率从低到高依次为all < index < range < index_merge < ref < eq_ref < const/system
。下面对type字段常用的类型做详细的说明
-
all
是最坏的情况,因为采用了全表扫描的方式。 -
index
和 all 差不多,只不过index
对索引表进行全扫描,这样做的好处是不再需要对数据进行排序,但是开销依然很大。如果我们在 extra 列中看到 Using index,说明采用了索引覆盖,也就是索引可以覆盖所需的 SELECT 字段,就不需要进行回表,这样就减少了数据查找的开销。下面通过一个例子,来对index进行说明:
比如我们有个
tb_user
表,对name和phone字段建立联合索引:CREATE INDEX name_phone_index on tb_user(`name`,phone)
然后对数据表中的 name、phone 字段进行查询,EXPLAIN 执行计划如下:
从EXPLAIN执行结果中可以看到,这条
SQL
使用了index的方式,key列采用了联合索引(name_phone_index),进行了全表扫描。Extral
列为 Using index,告诉我们索引可以覆盖 SELECT 中的字段,也就不需要回表查询了。-
range
表示采用了索引范围扫描。比如下面这条SQL语句select * from tb_user where id>=1 and id<=5;
从
range
这一级别开始,索引的作用会越来越明显,因此我们需要尽量让SQL
查询可以使用到 range 这一级别及以上的 type 访问方式。-
ref
类型表示采用了非唯一索引,或者是唯一索引的非唯一性前缀。比如我们对
tb_order
表user_id
字段创建索引CREATE INDEX user_id_index on tb_order(user_id)
然后查询user_id等于1的订单信息,EXPLAIN 执行计划如下:
EXPLAIN SELECT title,order_datetime FROM tb_order WHERE user_id=1
这里
user_id
为普通索引,因此采用的访问类型是 ref,同时在 ref 列中显示const
,表示连接匹配条件是常量,用于索引列的查找。-
eq_ref
类型是使用主键或唯一索引时产生的访问方式,通常使用在多表联查中。比如我们对
tb_order
表和tb_user
进行join关联查询EXPLAIN SELECT o.title,o.order_datetime,u.name FROM tb_order o JOIN tb_user u ON o.user_id=u.id
EXPLAIN 执行计划如下:
-
const
类型表示我们使用了主键或者唯一索引(所有的部分)与常量值进行比较。比如根据主键id查找某一个用户
在做优化的时候,最好可以使用到 range 这一级别及以上的 type 访问方式,如果只使用到了
all
或者index
这一级别的访问方式,我们可以从SQL
语句和索引设计的角度上进行改进。3.6. possible_keys字段
表示查询时可能能使用到的索引。实际并不一定会真正使用。
3.7. key字段
表示查询时真正使用到的索引,显示的是索引名称。
3.8. rows字段
MySQL
查询优化器会根据统计信息,估算SQL
要查询到结果需要扫描多少行记录。原则上rows是 越少效率越高,可以直观的了解到SQL
效率高低。3.9. key_len字段
表示查询使用了索引的字节数量。可以判断是否全部使用了组合索引。
key_len的计算规则如下:
-
字符串类型
字符串长度跟字符集有关,常见编码长度:gbk=2、utf8=3、utf8mb4=4
char(n):n*字符集长度
varchar(n):n * 字符集长度 + 2字节 -
数值类型
TINYINT
:1个字节
SMALLINT
:2个字节
MEDIUMINT
:3个字节
INT、FLOAT
:4个字节
BIGINT、DOUBLE
:8个字节 -
时间类型
DATE
:3个字节TIMESTAMP
:4个字节DATETIME
:8个字节
3.10. Extra字段
Extra表示很多额外的信息,各种操作会在Extra提示相关信息,常见几种如下:
- Using where 表示查询需要通过索引回表查询数据。
- Using index 表示查询需要通过索引,索引就可以满足所需数据。
- Using filesort 表示查询出来的结果需要额外排序,数据量小在内存,大的话在磁盘,因此有
Using filesort
建议优化。 Using temprorary
查询使用到了临时表,一般出现于去重、分组等操作。
总结
在使用
EXPLAIN
分析慢SQL的时候,我们主要关注type
字段,最好可以使用到 range 这一级别及以上的 type 访问方式,如果只使用到了all
或者index
这一级别的访问方式,我们可以从SQL
语句和索引设计的角度上进行改进。其次关注
rows
字段,绝大部分rows
小的语句执行一定很快,所以优化语句基本上都是在优化rows。四、SQL性能分析show profile命令
show profile
相比EXPLAIN
能看到更进一步的执行解析,包括 SQL 都做了什么、所花费的时间等。默认情况下,
show profile
是关闭的,使用下面的命令查看状态mysql> show variables like 'profiling';
通过设置
profiling='ON’
来开启 show profile:mysql > set profiling = 'ON';
show profile命令只是在本会话内起作用,即无法分析本会话外的语句。开启分析功能后,所有本会话中的语句都被分析(甚至包括执行错误的语句),除了SHOW PROFILE和SHOW PROFILES两句本身。
查看当前会话都有哪些 profiles,使用下面这条命令:
mysql > show profiles;
使用下面的命令我们可以查看上一个查询的开销:
mysql > show profile;
可以给show profile 指定一个 for query id 来查看指定 id 的语句,比如查看Query_ID为4的SQL信息
mysql> show profile for query 4;
还可以给输出添加新的列,取值范围可以如下:
- ALL 显示所有性能信息
- BLOCK IO 显示块IO操作的次数
- CONTEXT SWITCHES 显示上下文切换次数,不管是主动还是被动
- CPU 显示用户CPU时间、系统CPU时间
- IPC 显示发送和接收的消息数量
- PAGE FAULTS 显示页错误数量
- SOURCE 显示源码中的函数名称与位置
- SWAPS 显示SWAP的次数
比如:
mysql> show profile cpu,block io,swaps for query 4;
通过上面的结果,我们可以弄清楚每一步骤的耗时,以及在不同部分,比如
CPU
、block io
的执行时间,这样我们就可以判断出来SQL
到底慢在哪里。五、总结
本文介绍了MySQL性能分析常用的三种工具(还有很多性能分析工具),通过慢查询日志定位执行慢的 SQL,然后通过 EXPLAIN 分析该 SQL 语句是否使用到了索引和具体的数据表访问方式是怎样的。如果有需要最后再使用
SHOW PROFILE
进一步了解 SQL 每一步的执行时间,包括CPU 、I/O 等资源的使用情况。通过上面介绍的这三种工具我们可以快速的定位和分析慢SQL,然后做出相应的优化。
参考文档:
《高性能MySQL》
-
https://dev.mysql.com/doc/refman/8.0/en/explain-output.html
-
https://dev.mysql.com/doc/refman/8.0/en/show-profile.html
-
https://www.cnblogs.com/kerrycode/p/5593204.html
-
MySQL死锁原理及如何定位和解决?
2021-02-12 15:25:41死锁的产生有双重原因:有些是因为真正的数据冲突,这种情况通常很难避免,但有些则完全是由于存储引擎的实现方式导致的。 死锁发生以后,只有部分或者完全回滚其中一个事务,才能打破死锁。对于事务型的系统,这是...什么是死锁
死锁是指两个或者多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时,就可能会产生死锁。多个事务同时锁定同一个资源时,也会产生死锁。例如,设想下面两个事务同时处理StockPrice表:
事务1
START TRANSACTION; UPDATE StockPrice SET close = 45.50 WHERE stock_id = 4 and date = '2002-05-01'; UPDATE StockPrice SET close = 19.80 WHERE stock_id = 3 and date = '2002-05-02'; COMMIT;
事务2
START TRANSACTION; UPDATE StockPrice SET high = 20.12 WHERE stock_id = 3 and date = '2002-05-02'; UPDATE StockPrice SET high = 47.20 WHERE stock_id = 4 and date = '2002-05-01'; COMMIT;
如果凑巧,两个事务都执行了第一条UPDATE语句,更新了一行数据,同时也锁定了该行数据,接着每个事务都尝试去执行第二条UPDATE语句,却发现该行已经被对方锁定,然后两个事务都等待对方释放锁,同时又持有对方需要的锁,则陷入死循环。除非有外部因素介入才可能解除死锁。
为了解决这种问题,数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统,比如InnoDB存储引擎,越能检测到死锁的循环依赖,并立即返回一个错误。这种解决方式很有效,否则死锁会导致出现非常慢的查询。还有一种解决方式,就是当查询的时间达到锁等待超时的设定后放弃锁请求,这种方式通常来说不太好。InnoDB目前处理死锁的方法是,将持有最少行级排他锁的事务进行回滚(这是相对比较简单的死锁回滚算法)。
锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句,有些存储引擎会产生死锁,有些则不会。死锁的产生有双重原因:有些是因为真正的数据冲突,这种情况通常很难避免,但有些则完全是由于存储引擎的实现方式导致的。
死锁发生以后,只有部分或者完全回滚其中一个事务,才能打破死锁。对于事务型的系统,这是无法避免的,所以应用程序在设计时必须考虑如何处理死锁。大多数情况下只需要重新执行因死锁回滚的事务即可。
如何避免死锁
- 类似的业务逻辑以固定的顺序访问表和行(基本上是可以解决大部分的问题,比如转账,所有的功能接口都是先减钱再加钱)
- 大事务拆小,大事务更倾向于死锁,如果业务允许,将大事务拆小
- 在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁概率
- 降低隔离级别,如果业务允许,将隔离级别调低也是较好的选择(有点扯淡,但是也管用.)
5 为表添加合理的索引,可以看到如果不走索引将会为表的每一行记录添加上锁(或者说是表锁)
不加索引的事务语句拿到的锁都是表锁,表锁级别大,死锁概率就高了.
查看死锁日志
死锁场景:
事务A操作 select * from table where id =1 for update
事务B操作 select * from table where id =2 for update
事务A操作 select * from table where id =2 for update
事务B操作 select * from table where id =1 for update
此时就卡住了事务A等着事务B释放锁,事务B等着事务A释放锁.
解决办法很简单,就是找DBA看一下死锁日志就可以了,然后根据对应的SQL,找到对应的代码去改一下就可以了.
show engine innodb status 命令是可以查看死锁的信息的如何阅读MySQL的死锁日志
https://www.yuque.com/docs/share/016b2375-68b1-4ad8-92e8-62eb71b24792?# 《MySQL如何阅读死锁日志》
死锁详细介绍
https://www.yuque.com/docs/share/e437b034-6813-4171-be8b-712279d7865c?# 《记一次线上SQL死锁事故:如何避免死锁?》
-
mysql5.7执行SQL死锁问题的定位方法
2021-12-31 17:01:55从这段内容中在找到产生死锁的SQL语句(比如:replace into 和delete语句),以及产生死锁时直接原因,以及哪一个事务被回滚了。 2、手动复现死锁的场景:(记得将操作该表的程序都停掉,只有手动执行SQL) (1)...1、先登陆数据库mysql -uroot -p,然后使用命令:show engine innodb status;
在命令的输出结果中,找到“LATEST DETECTED DEADLOCK”。
从这段内容中在找到产生死锁的SQL语句(比如:replace into 和delete语句),以及产生死锁时直接原因,以及哪一个事务被回滚了。2、手动复现死锁的场景:(记得将操作该表的程序都停掉,只有手动执行SQL)
(1)打开3个MYSQL登陆shell界面,并且登陆。mysql -uroot -p
(2)在2个shell界面中,分别设置为手动提交:set autocommit=0;
(3)在2个shell界面,按出现死锁场景的语句执行顺序,手动在2个shell界面上执行SQL语句。
(4)在第3个shell界面中,使用命令:select * from information_schema.innodb_locks; 可查看到当前锁等待的信息。3、查看锁等待的信息,分析定位出死锁产生原因。解决死锁的方法有:
(1)replace into冲突时:并行操作数据库,修改为串行操作数据库。
(2)repalce into+delete死锁时:调整事务中的SQL语句执行顺序,把delete放前面。确保第1个SQL语句申请到更多的锁,避免第1个SQL语句申请少量锁,第2个SQL语句申请更多锁。
(mysql5.7)
查询隔离级别:
select @@tx_isolation;自动提交关闭:mysql> set autocommit=0;
查询自动提交:mysql> select @@autocommit;
锁等待信息查询命令:
select * from information_schema.innodb_locks;死锁产生的4个必要条件,参考文档:https://blog.csdn.net/guaiguaihenguai/article/details/80303835
-
如何将MySQL查询速度提升300倍?
2020-12-14 21:22:31在进行性能分析前,需要先定位耗时查询。... 一旦定位这些烦人的查询,可以探究慢的原因。MySQL提供了EXPLAIN关键字。可以与SELECT、DELETE、INSERT、REPLACE、UPDATE语句一起使用。只需要如下一样添加到查询 -
Mysql性能瓶颈深度定位分析
2020-06-10 10:22:37我们在性能测试过程中,经常会遇到Mysql出现性能瓶颈的情况,对于数据库来说,所谓的性能瓶颈无非是慢SQL、CPU高、IO高(有人会说内存高也算,说的对,比如发生比较严重的swap,由于我没遇到过,没有案例来说明),... -
如何快速定位MySQL 的错误日志(Error Log)?
2021-01-18 18:55:49日志文件是MySQL数据库的重要组成部分,包括有6种不同的日志文件:错误日志: -log-err查询日志: -log慢查询日志: -log-slow-queries更新日志: -log-update二进制日志: -log-bin这些日志可以帮助我们定位 mysqld ... -
数据库优化——慢查询MySQL定位优化流程
2021-05-19 11:07:25如何定位并优化慢查询SQL?如何使用慢查询日志?本文带来慢查询例子演示,新手都能看懂!那查询语句慢怎么办?explain带你分析sql执行计划!当主键索引、唯一索引、普通索引都存在,查询优化器如何选择?本文带你一... -
Mysql导入导出时遇到的问题解决
2021-01-21 15:00:02背景 自从把我手上的任务全部转换成docker运行和...定位mysql镜像过大 查看容器占用的空间 ```docker system df``` 查看详细信息 Local Volumes space usage: VOLUME NAME LINKS SIZE 3e764b0633ea2c3f3dc5b0bf79d -
MySQL实例crash的案例详细分析
2020-12-16 10:51:21【问题描述】 我们生产环境有一组集群的多台MySQL服务器(MySQL 5.6.21),不定期的会crash,但error log中只记录了重启信息,未记录...为定位crash的原因,首先开启mysql core dump的功能。 下面是开启core dump的步骤 -
Mysql数据库是如何通过索引定位数据
2020-12-12 09:33:45前言 我们之前讲了MySQL索引的底层数据结构,以及索引的失效原理等知识点。那么索引在硬盘上到底是怎么...这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一。 外键方面 InnoDB 支持外键,而 MyISAM -
Mysql数据库高CPU问题定位和优化
2020-05-30 19:33:37•导致mysql数据库CPU高的常见原因 •常见定位问题的方法 •一般定位步骤 •数据库注意事项 导致mysql数据库CPU高的常见原因 占用CPU过高,可以做如下考虑: 1)一般来讲,排除高并发的因素,还是要找到导致你... -
mysql索引失效的常见9种原因详解
2022-04-22 09:39:13目录 前言: 1.最佳左前缀法则 2.主键插入顺序 3.计算、函数、类型转换(自动或手动)导致索引失效 4.范围条件右边的列索引失效 ...6.is null可以使用索引,is...MySQL中提高性能的一个最有效的方式是对数据表设计合... -
MySQL自增主键auto_increment原理 与 自增主键出现间隙不连续现象的定位
2021-06-05 17:33:50MySQL自增主键auto_increment原理; MySQL的innodb_autoinc_lock_mode参数说明; MySQL的AUTO-INC锁原理; 自增主键出现间隙不连续现象的定位; -
mysql查询缓慢原因和解决方案
2019-10-24 10:18:50mysql查询缓慢原因和解决方案 查询速度慢的原因很多,常见如下几种: 1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2、I/O吞吐量小,形成了瓶颈效应。 3、没有创建计算列导致查询不... -
mysql sleep链接过多的原因及解决办法
2021-01-14 16:28:49今天收到运维同事短信,说有个线上业务"可能是数据库DB堵塞了,导致mysql链接过多,让我看一下"。回家后赶紧用家里vpn登录数据库服务器,show processlist看了以下,发现我的那个业务的DB确实有很多sleep链接没有... -
Mysql服务无法启动问题
2021-01-19 07:15:58今天重新安装mysql时遇到“mysql服务无法启动”问题从Mysql官网下载mysql installer(https://cdn.mysql.com//Downloads/MySQLInstaller/mysql-installer-community-5.7.18.1.msi),一路安装下来。安装完成后,在CMD中... -
mysql数据库cpu飙升800%,如何故障定位及优化?
2021-01-21 07:00:39mysql数据库cpu飙升800%,基本上就两种原因:访问量大,大到你8核cpu都承受不了;慢查询,数据库执行sql语句操作(查询数据、修改数据)会产生大量的逻辑读,将读出来的数据维护到临时表中(内存),系统需要消耗较多的... -
MySQL CPU使用率高情况的原因和解决
2021-01-18 22:51:341. 问题原因1.1 应用负载(QPS)高1.2. 查询执行成本(查询访问表数据行数 avg_lgc_io)高2. 解决方法2.1 应用负载(QPS)高2.2 查询语句执行成本(查询访问表数据行数)高3. 避免出现 CPU 使用率达到 100% 影响业务的一般... -
MySQL数据库面试题(2020最新版)
2020-03-10 17:20:40数据库三大范式是什么mysql有关权限的表都有哪几个MySQL的binlog有有几种录入格式?分别有什么区别?数据类型mysql有哪些数据类型引擎MySQL存储引擎MyISAM与InnoDB区别MyISAM索引与InnoDB索引的区别?InnoDB引擎的4... -
MySQL造成更新死锁及插入死锁的几种常见原因
2022-02-18 15:58:32索引合并一定程度上可以使用多个单列索引定位指定的行,然而这种策略弊端很大,所带来的优化有时并不符合预期,因此尽量不要用这个机制来作为设计方案,如果EXPLAIN中的type列为index_merge,Extra列为:Using ... -
mysql查询慢的原因和解决方案
2020-12-24 11:19:17查询速度慢的原因很多,常见如下几种:1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷)2、I/O吞吐量小,形成了瓶颈效应。3、没有创建计算列导致查询不优化。4、内存不足5、网络速度慢6、... -
【第三篇】MySQL 索引失效的常见原因【重点】
2022-03-03 15:35:45有时候不知道小伙伴有没有跟我一样的情况,明明已经建立了索引,但是通过explain发现语句并没有使用上索引,这可能是某些原因导致了我们的索引失效。所以本篇主要介绍的是索引失效的常见原因和如何用好索引,给... -
MySQL 数据库崩溃(crash)的常见原因和解决办法
2020-11-20 14:04:12墨墨导读:本文来自墨天轮用户投稿,详述MySQL 数据库崩溃(crash)的常见原因和解决办法,希望对大家有帮助。数据技术嘉年华,十周年盛大开启,点我立即报名!大会以“自研·智能·新基建... -
mysql中有大量sleep进程的原因与解决办法
2021-01-18 19:59:49mysql中有大量sleep进程的原因与解决办法 mysql服务器中有大量的sleep进程,本文分析下mysql出现大sleep进程原因分析与解决方法。可能的原因: 造成睡眠连接过多的原因?1. 使用了太多持久连接(个人觉得,在高并发... -
MySQL 索引——定位并优化慢 SQL
2021-01-27 16:40:08定位并优化慢查询SQL.png为什么要学习定位并优化慢查询 SQL日常开发中,在数据量比较小的表中,SQL 的执行效率可能没什么问题,但是随着表数据量的增加,慢 SQL 可能就会慢慢浮现,因此学习如何定位并优化慢 SQL ...