MySQL之KEY分区引发的血案
需求背景业务表tb_image部分数据如下所示,其中id唯一,image_no不唯一。image_no表示每个文件的编号,每个文件在业务系统中会生成若干个文件,每个文件的唯一ID就是字段id:业务表t
一次慢查询暴露的隐蔽的问题
最近解决了一个生产 SQL 慢查询的问题,排查问题之后发现一些比较隐匿且容易忽略的问题。 业务背景介绍最近业务上需要上线一个预警功能,需要查出一段时间内交易,求出当前交易成功率。当成功率低于设定阈值时
一个让人惊讶的排序导致的死循环问题
首先重现问题--表中的数据大概是这样的:```java+----------+---------------------+| image_no | create_time |+----
一种探究 InnoDB 的存储格式的新方式
文件的存储结构包含了系统大量的实现细节,比如 java 的 class 文件结构,rocksdb 的存储结构。MySQL InnoDB 的存储格式比较复杂,但确实我们理解 MySQL 技术内幕不必可少
MySQL 死锁套路:一次诡异的批量插入死锁问题分析
线上最近出现了批量insert的死锁,百思不得解。死锁记录如下:```2018-10-26T11:04:41.759589Z 8530809 [Note] InnoDB: (1) TRANSACTI
如何在 Mac 下用 Clion 调试 MySQL 源码
前面写了几篇文章来通过调试 MySQL 源码来分析死锁问题,有读者问如何用 IDE 调试源码,这篇文章简单介绍一下如何在 Mac 下调试。之所以使用调试的方式来分析死锁问题是因为在解决 MySQL 死
一个诡异的MySQL查询超时问题,居然隐藏着存在了两年的BUG
这一周线上碰到一个诡异的BUG。线上有个定时任务,这个任务需要查询一个表几天范围内的一些数据做一些处理,每隔十分钟执行一次,直至成功。通过日志发现,从凌晨5:26分开始到5:56任务执行了三次,三次都
Mysql的sql优化方法
1、选择最合适的字段属性 2、尽量把字段设置为NOT NULL 3、使用连接(JOIN)来代替子查询(Sub-Queries) 4、使用联合(UNION)来代替手动创建的临时表 5、事务 6、锁定表 7、使用外键 8、使用索引 9、优化de的查询语句
掉坑了!GROUP_CONCAT函数引发的线上问题
本文分享一篇在工作遇到的一个问题,关于MySQL GROUP_CONCAT函数导致的问题。希望能帮忙到你。 业务场景在说遇到的坑之前,先描述一下大致的业务场景。系统有一个排班的功能,一个医生一天可以排
MySQL 死锁套路:再来看一例走不同索引更新的例子
前面有文章介绍了利用调试MySQL源码的方式来调试锁相关的信息,这里利用这个工具来解决一个比较简单的问题,线上的表字段较多,这里简单成为了一个表:```CREATE TABLE `t3` ( `id
MySQL 死锁套路:唯一索引下批量插入顺序不一致
死锁的本质是资源竞争,批量插入如果顺序不一致很容易导致死锁,我们来分析一下这个情况。为了方便演示,把批量插入改写为了多条 insert。先来做几个小实验,简化的表结构如下:```CREATE TABL
空中楼阁之纸上谈兵 mysql的dbcp的配置
maxWait=-1 最大等待时间:当没有可用连接时,连接池等待连接被归还的最大时间(以毫秒计数),超过时间则抛出异常,如果设置为-1表示无限等待testOnBorrow=true指明是否在从池中取出
实践了5千万的数据表和重建索引,学到了!
项目中有一张历史记录表,主要用于记录一些接口调用流水,因为该表的地位不是那么重要,当初的创建者并未对核心字段创建索引。不知不觉这张表的数据已经有5千万数据了,由于没有索引,在排查问题时,发现这种表根本查不动。于是决定下手进行分表并建立索引。这张表在系统中只负责插入,影响范围极小,正好拿来练手
由一次 UPDATE 过慢 SQL 优化而总结出的经验
如果再遇到这种执行很慢但是实际上更新命中很少数据并且该有的索引都有的情况,可以先在一个数据量很少的测试环境,看看在进入统计数据分析前,SQL 改写转换是否有问题
Mysql高并发下重复插入问题排查和优化
前言最近测试给我提了一个bug,说我之前提供的一个批量复制商品的接口,产生了重复的商品数据。追查原因之后发现,这个事情没想象中简单,可以说一波多折。正文1、需求产品有个需求:用户选择一些品牌,点击确定按钮之后,系统需要基于一份默认品牌的商品数据,复制出一批新的商品。拿到这个需求时觉得太简单了
盘点MySQL慢查询的12个原因
前言大家好,我是捡田螺的小男孩。日常开发中,我们经常会遇到数据库慢查询。那么导致数据慢查询都有哪些常见的原因呢?今天田螺哥就跟大家聊聊导致MySQL慢查询的12个常见原因,以及对应的解决方法。 正文1. SQL没加索引很多时候,我们的慢查询,都是因为没有加索引。如果没有加索引
3000帧动画图解MySQL为什么需要binlog、redo log和undo log
MySQL最初搭载的存储引擎是自研的只支持简单查询的MyISAM的前身ISAM,后来与Sleepycat合作研发了Berkeley DB引擎,支持了事务。江山代有才人出,技术后浪推前浪,MySQL在持续的升级着自己的存储引擎的过程中,遇到了横空出世的InnoDB。
HeapDump性能社区专题系列一:了解数据库性能优化
数据库性能优化的目标是通过充分利用系统资源来最小化查询的响应时间。对这些资源的最佳利用包括最大限度地减少网络流量、磁盘 I/O 和 CPU 时间。
MySQL全面瓦解25:构建高性能索引(案例分析篇)
所有的这些案例都只是一些经验积累,只有熟悉查询优化器、索引的内部原理,了解索引优化的策略,才能定位这些问题的原因并加以解决。
发生即看见,一切可回溯 | TiDB 故障诊断与性能排查探讨
在刚刚发布的 TiDB 5.3 版本中,PingCAP 率先在数据库领域推出 “持续性能分析”(Continuous Profiling)功能(目前为实验特性),跨越分布式系统可观测性的鸿沟,为用户带来数据库源码水平的性能洞察,彻底解答每一个数据库问题。
​Mysql数据库查询好慢,除了索引,还能因为什么?
我熟练应用ctrl c和ctrl v 开发curd代码好多年了。mysql查询为什么会慢,关于这个问题,在实际开发经常会遇到,而面试中,也是个高频题。遇到这种问题,我们一般也会想到是因为索引。那除开索引之外,还有哪些因素会导致数据库查询变慢呢?有哪些操作,可以提升mysql的查询能力呢
从节点崩了,还怎么「主从读写分离」?
本篇通过一次 MySQL 从节点崩了的事件,引出了如何对从节点做高可用,然后从实践的角度详细讲解了如何去配置 keepalived 来保证从节点的高可用。
【全网首发】关于一张 5 亿数据表之我与 DBA 的 battle
你好,我是yes。事情是这样的,最近公司需要统一更改一些老表的主键类型,以前表的主键都是 int 类型,这次要改成 bigint。然后我整理的时候发现一张表,里面竟然有 5 亿的数据,之前排查问题优化过几条慢 sql,这个表的查询竟然没进慢 sql 名单,有点突破我的认知,平日使用也没啥问题。
【全网首发】总结 mysql 的所有 buffer,一网打尽就这篇了!
大家好,我是yes。今天填一下之前的坑,盘一盘 mysql 相关的 buffer。我们来看一下官网的一张图:图片这张图画的是 mysql innodb 的架构,从图中可以看到有很多 buffer,这篇我们就一个一个盘过去。发车!(文档基于mysql8.0,以下描述的存储引擎基于 mysql
Cobar提出的一种在分库场景下对Order By / Limit 的优化
Cobar 虽然是一款“古老”的数据库中间件,但目前不少公司仍然在用它,且它包含了不少有意思的算法和实现,今天就来分享 Cobar 提出的一种在分库场景下对 Order By / Limit 的优化。原算法描述参考:https://github.com/alibaba
15个必知的Mysql索引失效场景,别再踩坑了!
背景无论你是技术大佬,还是刚入行的小白,时不时都会踩到Mysql数据库不走索引的坑。常见的现象就是:明明在字段上添加了索引,但却并未生效。前些天就遇到一个稍微特殊的场景,同一条SQL语句,在某些参数下生效,在某些参数下不生效,这是为什么呢?另外,无论是面试或是日常,Mysql索引失效的通常情况都
案例|MySQL OOM排查之旅
一 背景微盟是中小企业云端商业及营销解决方案提供商,客户营销活动天天有,7月17日是某客户的超级营销日,老板要求全力护航,不允许任何故障。而营销活动前几天陆续收到几条腾讯云CDB实例OOM的短信报警。因为用云数据库,处理这个报警对于DBA来说太easy,腾讯DBA团队接管了。腾讯DBA大神们拿
基于MySQL和DynamoDB的强一致性分布式事务实践
在单体应用向微服务架构转型的过程中,本地事务已不再满足系统一致性需求,为了解决这一问题,前人在对性能和数据一致性反复权衡的过程中总结了许多典型的协议和算法,各有优劣。本文我们将深入探讨 Freewheel 如何实现无单点故障的可扩展分布式事务实现模型。
【全网首发】(大表小技巧)有时候 2 小时的 SQL 操作,可能只要 1 分钟
大家好,我是yes。上篇文章 关于一张 5 亿数据表之我与 DBA 的 battle 发了之后,有好几个小伙伴来问我 SQL 是怎么拆的。这篇我们来简单盘下,其实拆 SQL 是因为涉及大表删除的问题。比如,你现在需要删除一张一共有 5 亿数据的表里面的 2021 年数据,假设这张表叫 yes
【译】如何使用MySQL来设计分布式锁?
为什么我们需要分布式锁?我们中的许多人可能遇到或听说过这些问题:重试导致的数据损坏:从应用程序UI提交数据,该应用程序用户界面在引擎盖下将数据插入后端MySQL数据库。偶尔用户界面没有响应,因此用户单击了几次提交按钮,这损坏了数据库中的数据。缓存过期:使用Redis作为读透缓存,缓存中的密钥
【全网首发】一个月后,我们又从 MySQL 双主切换成了主-从!
你好,我是悟空。一、遇到的坑一个月前,我们在测试环境部署了一套 MySQL 高可用架构,也就是 MySQL 双主 + Keepalived 的模式。详情看这篇:实战 MySQL 高可用架构在这一个月遇到了很多坑:因为两个 MySQL 节点都可以写入,极其容易造成主键重复,进而导致主从同步
刚线上又出现一个问题。。。热乎的
大家好,我是yes。我又来送线上排查经历啦!事情是这样的,今天同事给我反馈了一个问题。因为我们的应用需要从第三方那边同步订单的信息,如果用户有一段时间未进入订单页面,则再次进入之后会自动进行一次全量的从第三方拉取订单的操作,这样能可及时更新订单信息,防止用户操作过期的订单。近期,这个同事发现
终于做了一把MySQL调参boy
本文通过笔者经历的一个真实案例来介绍一个MySQL中的重要参数innodb_buffer_pool_size,希望能给大家带来些许收获,当遇到类似性能问题时可以多一种思考方式。
MySQL 千万数据量深分页优化, 拒绝线上故障!
优化项目代码过程中发现一个千万级数据深分页问题,缘由是这样的库里有一张耗材 MCS_PROD 表,通过同步外部数据中台多维度数据,在系统内部组装为单一耗材产品,最终同步到 ES 搜索引擎MySQL 同步 ES 流程如下:1、通过定时任务的形式触发同步,比如间隔半天或一天的时间频率2、同步的形
抛砖系列之-MySQL中的数据类型JSON
今天介绍一个MySQL中的数据类型-JSON,相信大家对JSON都不陌生,在日常工作中使用到的频率也很高
索引失效的这10种场景,把我坑惨了
我之前写的一篇文章《聊聊sql优化的15个小技巧》,自发表之后,在全网广受好评,被很多大佬转载过,说明了这类文章的价值。今天我接着上一期数据库的话题,更进一步聊聊索引的相关问题,因为索引是大家都比较关心的公共话题,确实有很多坑。不知道你在实际工作中,有没有遇到过下面的这两种情况:明明在
MySQL全面瓦解21(番外):一次深夜优化亿级数据分页的奇妙经历
作者:翁智华,转载已获授权原文链接:https://www.cnblogs.com/wzh2010/p/14316920.html 背景1月22号晚上10点半,下班后愉快的坐在在回家的地铁上,心里想着
【全网首发】数据库系列:MySQL索引优化与性能提升总结(综合版)
1 背景作为一个常年在一线带组的Owner以及老面试官,我们面试的目标基本都是一线的开发人员。从服务端这个技术栈出发,问题的范围主要还是围绕开发语言(Java、Go)等核心知识点、数据库技术、缓存技术、消息中间件、微服务框架的使用等几个方面来提问。MySQL作为大厂的主流数据存储配置,当然是被问
MySQL全面瓦解9:查询的排序、分页相关
数据库中的数据直接呈现出来一般不是我们想要的,所以我们上两节演示了如何对数据进行过滤的方法。除了对数据进行过滤, 我们可能还需要对数据进行排序,比如想从列表中了解消费最高的项,就可能需要对金额字段做降序排序,想看年龄从小到大的分布情况,就可能需要对user表的age字段进行升序排序。
MySQL全面瓦解16:存储过程相关
大多数SQL语句都是针对一个或多个表的单条语句。但并非所有业务都这么简单,经常会有复杂的操作需要多条语句才能完成。 比如用户购买一个商品,要删减库存表,要生成订单数据,要保存支付信息等等,他是一个批量的语句执行行为。
一次 MySQL 误操作导致的事故,「高可用」都顶不住了!
你好,我是悟空。上次我们项目不是把 MySQL 高可用部署好了么,MySQL 双主模式 + Keepalived,来保证高可用。简单来说就是有两个 MySQL 主节点,分别有两个 Keepalived 安装在宿主机上监控 MySQL 的状态,一旦发现有问题,就重启 MySQL,而客户端也会自动连
【译】SQL性能优化:关于查找慢查询的几种方法分享
SQL Server的查询运行太慢了,以至于大家都不太喜欢,介绍几种方法可以快速跟踪它们,以便处理这些查询!
数据库性能实战干货!MySQL 高可用架构实践
你好,我是悟空。业界流传一句话:没有做过运维的程序员不是好架构师。不知是真是假。前言对于 MySQL 数据库作为各个业务系统的存储介质,在系统中承担着非常重要的职责,如果数据库崩了,那么对于读和写数据库的操作都会受到影响。如果不能迅速恢复,对业务的影响是非常大的。之前 B 站不是出过
我说MySQL联合索引遵循最左前缀匹配原则,面试官让我回去等通知
面试官: 我看你的简历上写着精通MySQL,问你个简单的问题,MySQL联合索引有什么特性?心想,这还不简单,这不是问到我手心里了吗?听我给你背一遍八股文!我: MySQL联合索引遵循最左前缀匹配原则,即最左优先,查询的时候会优先匹配最左边的索引。例如当我们在 (a,b,c) 三个字段上创
聊聊sql优化的15个小技巧
大家好,我是苏三,又跟大家见面了。前言sql优化是一个大家都比较关注的热门话题,无论你在面试,还是工作中,都很有可能会遇到。如果某天你负责的某个线上接口,出现了性能问题,需要做优化。那么你首先想到的很有可能是优化sql语句,因为它的改造成本相对于代码来说也要小得多。那么,如何优化sql
面对MySQL千万级别大表,你要如何优化?
前言数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷. 正文1. 优化一览图2. 优化笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数
MySQL-Seconds_behind_master 的精度误差
前言Seconds_behind_master 是我们观察主从延迟的一个重要指标。但任何指标所能表示的精度都是有限的。例如用精度只能到秒的指标去衡量毫秒级的表现就会产生非常大的误差。如果再以此误差去分析问题,就会让思维走上弯路。例如用 Seconds_behind_master 去评估 1s 内的
我说HashMap初始容量是16,面试官让我回去等通知
众所周知HashMap是工作和面试中最常遇到的数据类型,但很多人对HashMap的知识止步于会用的程度,对它的底层实现原理一知半解,了解过很多HashMap的知识点,却都是散乱不成体系,今天一灯带你一块深入浅出的剖析HashMap底层实现原理。看下面这些面试题,你能完整的答对几道?1. Hash
【全网首发】数据库系列:覆盖索引和避免回表
1 介绍在MySQL数据库查询过程中,索引覆盖和避免不必要的回表,是减少检索步骤,提高执行效率的有效手段。下面从这两个角度分析如何进行MySQL检索提效。2 数据准备模拟一个500w数据容量的部门表 emp,表结构如下,并通过工具模拟500w的数据:CREATE TABLE `emp` (

有开始,就会有进​步!

在追求性能的道路上,记录每一刻的成长!源码解读,编程技巧,外文翻译,技术实践,线上案例等等,记录自己,启发他人!

专家作者推荐

巡山小汪

关注微信公众号《解Bug之路》,有问题请在公众号中咨询:) 无论多么艰苦的时刻,都不要忘记,辉煌的未来,在你的眼中闪耀!

飞哥开发内功

《深入理解Linux网络》作者,腾讯搜狗十年工程师,公众号「开发内功修炼」作者!

踩刀诗人

聊聊技术,唠唠段子,偶尔做菜写诗,欢迎关注我的公众号 踩刀诗人

Brand

搜索关注微信公众号【架构与思维】:撰稿者为bat、字节的几位高阶研发/架构,专注技术分享。

专题推荐

本专题精选了HeapDump性能社区中的8篇数据库性能优化相关文章,这些文章内不仅包含了影响数据库性能的因素,数据库性能评估标准、优化方法的内容,还介绍了一些数据库设计原则和编程技巧,并且记录了一些或大或小的实战案例,帮助大家快速了解数据库性能优化,掌握一些实操技能。
8篇文章14789阅读量
相比于后端遇到的各种复杂性能问题,前端的性能相对简单,但是简单不代表容易,前端的技术更新迭代快,那么针对性能问题自然也会出现各种变种,需要各种新的工具和思路。
HeapDump性能社区将引进更多前端相关大佬,来给大家分享前端性能的那些事儿。本期先从前端性能基础开始:
5篇文章7197阅读量