[背景]  某业务数据库load 报警异常,cpu usr 达到30-40 ,居高不下.使用工具查看数据库正在执行的sql ,排在前面的大部分是: SELECT id, cu_id, name, info, biz_type, gmt_create, gmt_modified,start_time, end_time, market_type, back_leaf_category,item_status,picuture_url FROM relation where biz_type ='0

其实在我们的工作中类似,select * from your_table order by id desc limit 2000000,20会经常遇见,比如在分页中就很常见. 如果我们的sql中出现这样的查询(比如:点击查看“末页”),那是相当恐怖的(等待时间会很长).该sql是一个非常典型的排序+分页查询:order by col limit N,OFFSET M, MySQL 执行此类sql时需要先扫描到N行,然后再去取 M行.对于此类大数据量的排序操作,取前面少数几行数据会很快,但是越靠后

最近在生产上遇见一个分页查询特别慢的问题,数据量大概有200万的样子,翻到最后一页性能很低,差不多得有4秒的样子才能出来整个页面,需要进行查询优化. 第一步,找到执行慢的sql,如下: SELECT         shotel_id as hotelId, mroom_type_id as mroomTypeId, available_date as availableDate, result_status as resultStatus, create_time as createTime,

[提出问题] 从数据表t通过分页查询的方式读取数据,读取时要根据a1排序.t有80万行记录,当OFFSET很大时,读取速度很慢.优化后查询速度提升很快. 下图是表的定义,一共有几十个字段,RowLength大概500字节.除了主键,没有其他索引. CREATE TABLE `t` ( `a0` ) NOT NULL, `a1` ) NOT NULL, `a2` ,) NOT NULL DEFAULT '0.000000000', `a3` ,) NOT NULL DEFAULT '0.00000

[背景]  某业务数据库load 报警异常,cpu usr 达到30-40 ,居高不下.使用工具查看数据库正在执行的sql ,排在前面的大部分是: SELECT id, cu_id, name, info, biz_type, gmt_create, gmt_modified,start_time, end_time, market_type, back_leaf_category,item_status,picuture_url FROM relation where biz_type ='0

对于web后台报表导出是一种常见的功能点,实际对应服务后端即数据库的排序分页查询.如下示例为公司商户积分报表导出其中一个sql ,当大批量的导出请求进入时候,mysql的cpu急剧上升瞬间有拖垮库的风险. SELECT * FROM coupons.cp_score_log WHERE `m_shopid` ORDER BY add_time DESC LIMIT , ; 报表导出功能存在几个问题: 1.时间跨度太大,数据量剧增.(可以结合业务需求,限制一定时间范围,比如只能导出3个月以内数据)

延迟关联:通过使用覆盖索引查询返回需要的主键,再根据主键关联原表获得需要的数据.   为什innodb的索引叶子节点存的是主键,而不是像myisam一样存数据的物理地址指针? 如果存的是物理地址指针不就不需要二次查找了吗,根据myisam和innodb数据存储方式的差异去想 Imyisam索引文件和数据文件是分离的,索引文件仅保存数据记录的地址. 而在InnoDB中,表数据文件本身就是按B+Tree组织的一个索引结构,这棵树的叶节点data域保存了完整的数据记录. 这个索引的key是数据表的主键

理想的索引,高效的索引建立考虑: :查询频繁度(哪几个字段经常查询就加上索引) :区分度要高 :索引长度要小 : 索引尽量能覆盖常用查询字段(如果把所有的列都加上索引,那么索引就会变得很大) : 索引长度直接影响索引文件的大小,影响增删改的速度,并间接影响查询速度(占用内存多). 针对列中的值,从左往右截取部分,来建索引 : 截的越短, 重复度越高,区分度越小, 索引效果越不好 : 截的越长, 重复度越低,区分度越高, 索引效果越好,但带来的影响也越大--增删改变慢,并间影响查询速度. 所以,

目录 1.   InnoDB表的索引的几个概念 2.   覆盖索引和回表 3.   分页查询 4.   延迟关联优化 写在前面 下面的介绍均是在选用MySQL数据库和Innodb引擎的基础开展.我们先来学习索引的几个概念,帮助我们理解延迟关联优化的加快分页查询速度的原因. 一.Innodb表的索引的几个概念 InnoDB表是基于聚簇索引建立的. 索引一般分为主键索引和普通索引(辅助索引),聚簇索引并不是主键索引这样的单独的索引类型,而是一种数据存储方式.通俗的来说,单独的索引是存储了索引信息的B

前言 上周新系统改版上线,上线第二天就出现了较多的线上慢sql查询,紧接着dba 给出了定位及解决方案,这里较多的是使用延迟关联去优化. 而我对于这个延迟关联也是第一次听说(o(╥﹏╥)o),所以今天一定要学习并产出一篇学习笔记.(^▽^) 回表 我们都知道InnoDB采用的B+ tree来实现索引的,索引又分为主键索引(聚簇索引)和普通索引(二级索引). 那么我们就来看下基于主键索引和普通索引的查询有什么区别? 如果语句是select * from T where ID=500,即主键查询方式

Mysql多表表关联查询 inner Join left join right join

MySQL中‘关联(join)’ 一词包含的意义比一般意义上理解的要更广泛.总的来说,MySQL认为任何一个查询都是一次‘关联’ --并不仅仅是一个查询需要到两个表的匹配才叫关联,索引在MySQL中,每一个查询,每一个片段(包括子查询,设置基于表单的select)都可能是关联. 所以,理解MySQL如何执行关联查询至关重要.我们先来看一个union 查询的例子.对于union查询,MySQL先将一系列的单个查询结果放到一个临时表中,然后再重新读出临时表数据来完成union查询.在MySQL的概念

最近开发中遇到的一个MySQL主从延迟的坑,记录并总结,避免再次犯同样的错误. 情景 一个活动信息需要审批,审批之后才能生效.因为之后活动要编辑,编辑后也可能触发审批,审批中展示的是编辑前的活动内容,考虑到字段比较多,也要保存审批活动的内容,因此设计采用了一张临时表,审批中的活动写进审批表(activity_tmp),审批通过之后才把真正的活动内容写进活动表(activity).表的简要设计如下,这里将活动内容字段合并为content展示: activity_tmp() id status //

本文同时发表在https://github.com/zhangyachen/zhangyachen.github.io/issues/51 当前mysql执行的策略很简单:mysql对任何关联都执行嵌套循环操作,即mysql先在一个表中循环取出单条数据,然后再嵌套循环到下一个表中寻打匹配的行,依次下去,直到描述到所表表中匹配的行为止.然后根据各个表匹配的行,返回查询中需要的各个列.mysql会尝试在最后一个关联表中打到所有匹配的行,如果最后一个关联表无法找到更多的行以后,mysql返回到上一层次

mysql如何执行关联查询与优化 一.前言 在数据库中执行查询(select)在我们工作中是非常常见的,工作中离不开CRUD,在执行查询(select)时,多表关联也非常常见,我们用的也比较多,那么mysql内部是如何执行关联查询的呢?它又做了哪些优化呢?今天我们就来揭开mysql关联查询的神秘面纱. 二.mysql如何执行关联查询 mysql关联执行的策略很简单:mysql对任何关联都执行嵌套循环关联操作.即:mysql先在一个表中循环取出单条数据,然后再嵌套循环到下一个表中寻找匹配的行,依次

1.1.1故障1:从库数据与主库冲突 1 2 3 4 5 6 show slave status; 报错:且show slave status\G Slave_I/O_Running:Yes Slave_SQL_Running:No Seconds_Behind_Master:NULL Last_error:Error 'Can't create database 'xiaoliu'; database exists' on query. Default   database:'xiaoliu'

MySQL主从复制延迟的问题 #M1002# https://mp.weixin.qq.com/s/NwFGER-qn2xQ5TnG-php1Q 更为糟糕的是,MySQL主从复制在大事务下的延迟.同样假设1个大事务在主服务器上执行了1个小时,则需要在最后的提交时间传送到从服务器.主从延迟的时间至少为1个小时,若从服务器执行还需1个小时,则主从复制延迟的最坏情况可能是2个小时.物理复制则不存在这样的限制,原因还是如前所述,事务提交过程中,日志已经在传输和回放. 一个执行了一个小时的大事务,事务提交

浅谈mysql主从复制延迟 1 概念解读 需要知道以下几点 1 mysql的主从同步上是异步复制,从库是串行化执行 2 mysql 5.7的并行复制能加速从库重做的速度,进一步缓解 主从同步的延迟问题 3 mysql的Seconds_Behind_Master代表延迟的状态 0为无延迟 4 mysql的Slave_SQL_Running_State:状态在异常时会有所表现,延迟出现的时候要尤为注意 5  Master_Log_File = Relay_Master_Log_File,Read_M

一.如何监控发生了主从延迟? 在从库机器上,执行show slave status,查看Seconds_Behind_Master值,代表主从同步从库落后主库的时间,单位为秒,若同从同步无延迟,这个值为0. Mysql主从延迟一个重要的原因之一是:mysql是以单线程串行执行. 主从复制数据时,在从服务器上的mysql,是一个线程在同步数据. 串行的方式,它是指,执行一个后才继续执行下一个.如果一个卡住了,要等待时间,才会继续下一个.串行与并行是相反的. 二.同步延迟发生的场景 当主库的TPS并

我们知道生产环境中经常会遇到MySQL主从延迟问题,从原理上也能看出主库的事务提交是并发模式,而从库只有一个SQL线程负责解析,所以本身上就可能存在延迟. 延迟的主要原因在于: 1.从库的配置往往没有主库的配置高2.主库支持并发写入,而5.7之前的版本上从库只有单线程SQL来完成任务. 3.MySQL主从之间的同步,并不是完全的实时同步,而是主库提交事务之后,从库才再来执行一遍 4.主库上的表的某个列没有索引,然后对这个列进行delete或update操作 5.网络问题,往返时延RTT较大. 解