精华内容
下载资源
问答
  • mysql插入数据变慢的原因
    千次阅读
    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性能瓶颈排查定位的方法。分享给大家供大家参考,具体如下: 导读 从一个现场说起,全程解析如何定位性能瓶颈。 排查过程 收到线上某业务后端的MySQL实例负载比较高的告警信息,于是登入服务器...
  • MySQL允许重定位数据目录或其中的成员,这里就来介绍重定位MySQL数据目录的方法,对此方面感兴趣的朋友不妨看一下。 重定位MySQL数据目录 MySQL数据目录结构是缺省配置,所有数据库和状态文件均包含其中,然而,你有...
  • 开发的一款网站防护产品中出现了一个客户端上安装后Mysql每隔一段时间就出现问题,这个问题是客户反馈的,所以需要去复现和定位
  • 我们在做SQL优化的时候,应该从哪几方面定位SQL执行慢的原因呢?是索引设计的问题?参数配置的问题?还是需要扩容了呢? 本文介绍了比较常用的三种工具来定位和分析慢SQL,本文主要内容如下: 通过慢查询日志定位...

    一、前言

    我们在做SQL优化的时候,应该从哪几方面定位SQL执行慢的原因呢?是索引设计的问题?参数配置的问题?还是需要扩容了呢?

    本文介绍了比较常用的三种工具来定位和分析慢SQL,本文主要内容如下:

    1. 通过慢查询日志定位执行慢的 SQL;
    2. 使用 EXPLAIN 分析该 SQL 语句是否使用到了索引,以及具体的数据表访问方式;
    3. 使用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 UNIONUNION中的第二个或后续的查询语句,使用了外面查询结果
    UNION RESULTUNION的结果
    SUBQUERYSELECT子查询语句

    平时我们最常见的查询类型是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表最多有一个匹配行,因为只有一行,所以这一行中列的值可以被优化器视为常量
    systemsystem 类型一般用于 MyISAMMemory 表,属于 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_orderuser_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;
    

    在这里插入图片描述

    通过上面的结果,我们可以弄清楚每一步骤的耗时,以及在不同部分,比如 CPUblock 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

    展开全文
  • 死锁的产生有双重原因:有些是因为真正的数据冲突,这种情况通常很难避免,但有些则完全是由于存储引擎的实现方式导致的。 死锁发生以后,只有部分或者完全回滚其中一个事务,才能打破死锁。对于事务型的系统,这是...

    什么是死锁

    死锁是指两个或者多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环的现象。当多个事务试图以不同的顺序锁定资源时,就可能会产生死锁。多个事务同时锁定同一个资源时,也会产生死锁。例如,设想下面两个事务同时处理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目前处理死锁的方法是,将持有最少行级排他锁的事务进行回滚(这是相对比较简单的死锁回滚算法)。

    锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句,有些存储引擎会产生死锁,有些则不会。死锁的产生有双重原因:有些是因为真正的数据冲突,这种情况通常很难避免,但有些则完全是由于存储引擎的实现方式导致的。

    死锁发生以后,只有部分或者完全回滚其中一个事务,才能打破死锁。对于事务型的系统,这是无法避免的,所以应用程序在设计时必须考虑如何处理死锁。大多数情况下只需要重新执行因死锁回滚的事务即可。

    如何避免死锁

    1. 类似的业务逻辑以固定的顺序访问表和行(基本上是可以解决大部分的问题,比如转账,所有的功能接口都是先减钱再加钱)
    2. 大事务拆小,大事务更倾向于死锁,如果业务允许,将大事务拆小
    3. 在同一个事务中,尽可能做到一次锁定所需要的所有资源,减少死锁概率
    4. 降低隔离级别,如果业务允许,将隔离级别调低也是较好的选择(有点扯淡,但是也管用.)
      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死锁事故:如何避免死锁?》

    展开全文
  • 从这段内容中在找到产生死锁的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提供了EXPLAIN关键字。可以与SELECT、DELETE、INSERT、REPLACE、UPDATE语句一起使用。只需要如下一样添加到查询
  • Mysql性能瓶颈深度定位分析

    万次阅读 多人点赞 2020-06-10 10:22:37
    我们在性能测试过程中,经常会遇到Mysql出现性能瓶颈的情况,对于数据库来说,所谓的性能瓶颈无非是慢SQL、CPU高、IO高(有人会说内存高也算,说的对,比如发生比较严重的swap,由于我没遇到过,没有案例来说明),...
  • 日志文件是MySQL数据库的重要组成部分,包括有6种不同的日志文件:错误日志: -log-err查询日志: -log慢查询日志: -log-slow-queries更新日志: -log-update二进制日志: -log-bin这些日志可以帮助我们定位 mysqld ...
  • 数据库优化——慢查询MySQL定位优化流程

    万次阅读 多人点赞 2021-05-19 11:07:25
    如何定位并优化慢查询SQL?如何使用慢查询日志?本文带来慢查询例子演示,新手都能看懂!那查询语句慢怎么办?explain带你分析sql执行计划!当主键索引、唯一索引、普通索引都存在,查询优化器如何选择?本文带你一...
  • 背景 自从把我手上的任务全部转换成docker运行和...定位mysql镜像过大 查看容器占用的空间 ```docker system df``` 查看详细信息 Local Volumes space usage: VOLUME NAME LINKS SIZE 3e764b0633ea2c3f3dc5b0bf79d
  • 【问题描述】 我们生产环境有一组集群的多台MySQL服务器(MySQL 5.6.21),不定期的会crash,但error log中只记录了重启信息,未记录...为定位crash的原因,首先开启mysql core dump的功能。 下面是开启core dump的步骤
  • 前言 我们之前讲了MySQL索引的底层数据结构,以及索引的失效原理等知识点。那么索引在硬盘上到底是怎么...这是 MySQL 将默认存储引擎从 MyISAM 变成 InnoDB 的重要原因之一。 外键方面 InnoDB 支持外键,而 MyISAM
  • •导致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原理; MySQL的innodb_autoinc_lock_mode参数说明; MySQL的AUTO-INC锁原理; 自增主键出现间隙不连续现象的定位
  • mysql查询缓慢原因和解决方案

    千次阅读 2019-10-24 10:18:50
    mysql查询缓慢原因和解决方案 查询速度慢的原因很多,常见如下几种: 1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2、I/O吞吐量小,形成了瓶颈效应。 3、没有创建计算列导致查询不...
  • 今天收到运维同事短信,说有个线上业务"可能是数据库DB堵塞了,导致mysql链接过多,让我看一下"。回家后赶紧用家里vpn登录数据库服务器,show processlist看了以下,发现我的那个业务的DB确实有很多sleep链接没有...
  • 今天重新安装mysql时遇到“mysql服务无法启动”问题从Mysql官网下载mysql installer(https://cdn.mysql.com//Downloads/MySQLInstaller/mysql-installer-community-5.7.18.1.msi),一路安装下来。安装完成后,在CMD中...
  • mysql数据库cpu飙升800%,基本上就两种原因:访问量大,大到你8核cpu都承受不了;慢查询,数据库执行sql语句操作(查询数据、修改数据)会产生大量的逻辑读,将读出来的数据维护到临时表中(内存),系统需要消耗较多的...
  • MySQL CPU使用率高情况的原因和解决

    千次阅读 2021-01-18 22:51:34
    1. 问题原因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...
  • 索引合并一定程度上可以使用多个单列索引定位指定的行,然而这种策略弊端很大,所带来的优化有时并不符合预期,因此尽量不要用这个机制来作为设计方案,如果EXPLAIN中的type列为index_merge,Extra列为:Using ...
  • mysql查询慢的原因和解决方案

    千次阅读 2020-12-24 11:19:17
    查询速度慢的原因很多,常见如下几种:1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷)2、I/O吞吐量小,形成了瓶颈效应。3、没有创建计算列导致查询不优化。4、内存不足5、网络速度慢6、...
  •    有时候不知道小伙伴有没有跟我一样的情况,明明已经建立了索引,但是通过explain发现语句并没有使用上索引,这可能是某些原因导致了我们的索引失效。所以本篇主要介绍的是索引失效的常见原因和如何用好索引,给...
  • 墨墨导读:本文来自墨天轮用户投稿,详述MySQL 数据库崩溃(crash)的常见原因和解决办法,希望对大家有帮助。数据技术嘉年华,十周年盛大开启,点我立即报名!大会以“自研·智能·新基建...
  • mysql中有大量sleep进程的原因与解决办法 mysql服务器中有大量的sleep进程,本文分析下mysql出现大sleep进程原因分析与解决方法。可能的原因: 造成睡眠连接过多的原因?1. 使用了太多持久连接(个人觉得,在高并发...
  • 定位并优化慢查询SQL.png为什么要学习定位并优化慢查询 SQL日常开发中,在数据量比较小的表中,SQL 的执行效率可能没什么问题,但是随着表数据量的增加,慢 SQL 可能就会慢慢浮现,因此学习如何定位并优化慢 SQL ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 63,259
精华内容 25,303
热门标签
关键字:

怎么定位mysql原因

mysql 订阅