Browsed by
标签:MySQL

去阿里面试被问:如果是MySQL引起的CPU消耗过大,你会如何优化?

去阿里面试被问:如果是MySQL引起的CPU消耗过大,你会如何优化?

閱讀本文約花費: 4 (分鐘) 链接:https://www.cnblogs.com/YangJiaXin/p/10933458.html 目录 谁在消耗cpu?祸首是谁? 用户 IO等待 产生影响 如何减少CPU消耗? 减少等待 减少计算 升级cpu 谁在消耗cpu? 用户+系统+IO等待+软硬中断+空闲 image image 祸首是谁? 用户 用户空间CPU消耗,各种逻辑运算 正在进行大量tps函数/排序/类型转化/逻辑IO访问… 用户空间消耗大量cpu,产生的系统调用是什么?那些函数使用了cpu周期? IO等待 等待IO请求的完成 此时CPU实际上空闲 如vmstat中的wa 很高。但IO等待增加,wa也不一定会上升(请求I/O后等待响应,但进程从核上移开了) image image 产生影响 用户和IO等待消耗了大部分cpu 吞吐量下降(tps) 查询响应时间增加 慢查询数增加 对mysql的并发陡增,也会产生上诉影响 image 如何减少CPU消耗? 减少等待 减少IO量 SQL/index,使用合适的索引减少扫描的行数(需平衡索引的正收益和维护开销,空间换时间) 提升IO处理能力 加cache/加磁盘/SSD image 减少计算 减少逻辑运算量 避免使用函数,将运算转移至易扩展的应用服务器中如substr等字符运算,dateadd/datesub等日期运算,abs等…

Read More Read More

我是如何一步一步监控公司MySQL的每一个操作?

我是如何一步一步监控公司MySQL的每一个操作?

閱讀本文約花費: 11 (分鐘)作为一个程序员,闲下来还是喜欢学习钻研一些新奇的技术,canal就成了很好的研究对象,一不小心就监控了公司MySQL的一举一动的 一、canal是个啥? canal是阿里开发的一款基于数据库增量日志解析,提供增量数据订阅与消费的框架,整个框架纯JAVA开发,目前仅支持Mysql和MariaDB(和mysql类似)。 那什么是数据库增量日志? MySQL的日志种类是比较多的,主要包含:错误日志、查询日志、慢查询日志、事务日志、二进制日志。而MySQL数据库所发生的数据变更(DML(data manipulation language)数据操纵语言,也就是我们熟悉的增删改),都会以二进制日志(binary log)形式存储。 二、canal原理 在介绍canal原理之前,我们先来回顾一下MySQL主从同步的原理,这或许会让你更好的理解canal的工作机制。 1、MySQL主从同步原理: MySQL主从同步也叫读写分离,可以提升数据库的负载和容错能力,实现数据库的高可用 先来分析一张MySQL主从同步原理图: image 以上图片源自网络,如有侵权联系删除 master节点操作过程: 当master节点数据发生更改后(delete、update、insert,还是创建函数、存储过程等操作),向binary log中写入记录日志,这些记录又叫做二进制日志事件…

Read More Read More

无语,我差点被面试官怼坏了,又给我问到MySQL索引

无语,我差点被面试官怼坏了,又给我问到MySQL索引

閱讀本文約花費: 23 (分鐘)前一阵子,又跑出去搞了一场面试,心态算是崩了,关于MySQL索引的原理及使用被面试官怼的体无完肤,立志要总结一番,然后一直没有时间(其实是懒……),准备好了吗? image 一、MySQL中索引的语法 创建索引 在创建表的时候添加索引 在创建表以后添加索引 注意: 1、索引需要占用磁盘空间,因此在创建索引时要考虑到磁盘空间是否足够 2、创建索引时需要对表加锁,因此实际操作中需要在业务空闲期间进行 根据索引查询 删除索引 查看表中的索引 查看查询语句使用索引的情况 二、索引的优缺点 优势:可以快速检索,减少I/O次数,加快检索速度;根据索引分组和排序,可以加快分组和排序; 劣势:索引本身也是表,因此会占用存储空间,一般来说,索引表占用的空间的数据表的1.5倍;索引表的维护和创建需要时间成本,这个成本随着数据量增大而增大;构建索引会降低数据表的修改操作(删除,添加,修改)的效率,因为在修改数据表的同时还需要修改索引表; 三、索引的分类 常见的索引类型有:主键索引、唯一索引、普通索引、全文索引、组合索引 1、主键索引:即主索引,根据主键pk_clolum(length)建立索引,不允许重复,不允许空值; 2、唯一索引:用来建立索引的列的值必须是唯一的,允许空值 3、普通索引:用表中的普通列构建的索引,没有任何限制 4、全文索引:用大文本对象的列构建的索引(…

Read More Read More

Kubernetes 下日志采集、存储与处理技术实践

Kubernetes 下日志采集、存储与处理技术实践

閱讀本文約花費: 25 (分鐘) 本文介绍了“Logtail + 日志服务 + 生态”架构,介绍了:Logtail客户端在Kubernetes日志采集场景下的优势. 日志服务作为基础设施一站式解决实时读写、HTAP两大日志强需求;日志服务数据的开放性以及与云产品、开源社区相结合,在实时计算、可视化、采集上为用户提供的丰富选择。 Kubernetes日志处理的趋势与挑战 Kubernetes的serveless化 Kubernetes容器技术促进了技术栈的去耦合,通过引入栈的分层使得开发者可以更加关注自身的应用程序和业务场景。从Kubernetes本身来看,这个技术解耦也在更进一步发展,容器化的一个发展的趋势是:这些容器都将会在无服务器的基础设施上运行。 谈到基础设施,首先可以联想到云,目前在AWS、阿里云、Azure的云上都提供了无服务器化的Kubernetes服务。在serverless Kubernetes上,我们将不再关心集群与机器,只需要声明容器的镜像、CPU、内存、对外服务方式就可以启动应用。 如上图,左右两边分别是经典Kubernetes、serverless Kubernetes的形态。在从左向右发展的过程中,日志采集也变得复杂: 1.在一个Kubernetes node上,可能会运行更大规模量级的pod,每个pod上都可能有日志或监控指标采集需求,意味着单node上…

Read More Read More

深入学习MySQL事务:ACID特性的实现原理

深入学习MySQL事务:ACID特性的实现原理

閱讀本文約花費: 23 (分鐘) 本文主要介绍了MySQL事务的基础知识,它的原子性,持久性,隔离性,一致性等方面内容。 事务是MySQL等关系型数据库区别于NoSQL的重要方面,是保证数据一致性的重要手段。本文将首先介绍MySQL事务相关的基础概念,然后介绍事务的ACID特性,并分析其实现原理。 MySQL博大精深,文章疏漏之处在所难免,欢迎批评指正。 一、基础概念 事务(Transaction)是访问和更新数据库的程序执行单元;事务中可能包含一个或多个sql语句,这些语句要么都执行,要么都不执行。作为一个关系型数据库,MySQL支持事务,本文介绍基于MySQL5.6。 首先回顾一下MySQL事务的基础知识。 1. 逻辑架构和存储引擎 图片来源:csdn 如上图所示,MySQL服务器逻辑架构从上往下可以分为三层: (1)第一层:处理客户端连接、授权认证等。 (2)第二层:服务器层,负责查询语句的解析、优化、缓存以及内置函数的实现、存储过程等。 (3)第三层:存储引擎,负责MySQL中数据的存储和提取。MySQL中服务器层不管理事务,事务是由存储引擎实现的。MySQL支持事务的存储引擎有InnoDB、NDB Cluster等,其中InnoDB的使用最为广泛;其他存储引擎不支持事务,如MyIsam、Memory等。 如无特殊说明,后文中描述的内容都是基于InnoDB。 2. 提交和回…

Read More Read More

甲骨文:有史以来最伟大的25个Java应用程序

甲骨文:有史以来最伟大的25个Java应用程序

閱讀本文約花費: 22 (分鐘)作者 | Alexa Morales译者 | 刘雅梦策划 | TinaJava 的故事始于 1991 年,当时 Sun Microsystems 试图将其在计算机工作站市场的领先地位扩展到新兴且发展迅速的个人电子产品市场。几乎没有人预料到 Sun 即将创建的编程语言会使计算大众化,激发了一个全球范围的社区,并成为了一个由语言、运行时平台、SDK、开源项目以及许多工具组成的持久软件开发生态系统的平台。经过 James Gosling 领导的数年秘密开发之后,Sun 于 1995 年发布了具有里程碑意义的“一次编写,随处运行” 的 Java 平台,并将重点从最初的交互式电视系统设计转到了新兴的万维网应用程序上。在本世纪初,Java 就已经开始为从智能卡到太空飞行器的一切制作动画了。 如今,数以百万计的开发人员在使用 Java 编程,Java 仍然在以越来越快的步伐向前发展。在 Java 诞生 25 周年之际,Java Magazine(Oracle 的双月刊)联合 Oracle Java 开发团队,共同撰文回顾 Java 是如何塑造我们这个星球的。 以下是迄今为止,最具创意和影响力的 25 个 Java 应用程序, 包含了从 Wikipedia Search 到美国国家安全局的 Ghidra 等。这些应用包罗万象,覆盖了包括:太空探索、视频游戏…

Read More Read More

Zookeeper典型应用场景介绍

Zookeeper典型应用场景介绍

閱讀本文約花費: 13 (分鐘) 本文主要通过几个例子来具体的说明Zookeeper在特定场景下的使用方式 ,希望对您的学习有所帮助。 1.前言 之前自己写了一些关于Zookeeper的基础知识,Zookeeper作为一种协调分布式应用高性能的调度服务,实际的应用场景也非常的广泛,这里主要通过几个例子来具体的说明Zookeeper在特定场景下的使用方式(下面的这些功能估计consul和etcd也能实现,以后学到了再说吧)。 2.具体应用 2.1.一致性配置管理 我们在开发的时候,有时候需要获取一些公共的配置,比如数据库连接信息等,并且偶然可能需要更新配置。如果我们的服务器有N多台的话,那修改起来会特别的麻烦,并且还需要重新启动。这里Zookeeper就可以很方便的实现类似的功能。 2.1.1.思路 将公共的配置存放在Zookeeper的节点中 应用程序可以连接到Zookeeper中并对Zookeeper中配置节点进行读取或者修改(对于写操作可以进行权限验证设置),下面是具体的流程图: 2.1.2.事例 数据库配置信息一致性的维护 配置类: public class CommonConfig implements Serializable{// 数据库连接配置private String dbUrl;private String username;private String pas…

Read More Read More

面试官邪魅一笑:MySQL千万级别大表,你要如何优化?

面试官邪魅一笑:MySQL千万级别大表,你要如何优化?

閱讀本文約花費: 23 (分鐘)当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑、部署、运维的各种复杂度,一般以整型值为主的表在千万级以下,字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间,甚至能正常支撑千万级以上的数据量: 字段 尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT,如果非负则加上UNSIGNED VARCHAR的长度只分配真正需要的空间 使用枚举或整数代替字符串类型 尽量使用TIMESTAMP而非DATETIME, 单表不要有太多字段,建议在20以内 避免使用NULL字段,很难查询优化且占用额外索引空间 用整型来存IP 索引 索引并不是越多越好,要根据查询有针对性的创建,考虑在WHERE和ORDER BY命令上涉及的列建立索引,可根据EXPLAIN来查看是否用了索引还是全表扫描 应尽量避免在WHERE子句中对字段进行NULL值判断,否则将导致引擎放弃使用索引而进行全表扫描 值分布很稀少的字段不适合建索引,例如”性别”这种只有两三个值的字段 字符字段只建前缀索引 字符字段最好不要做主键 不用外键,由程序保证约束 尽量不用UNIQUE,由程序保证约…

Read More Read More

如何设计可以动态扩容缩容的分库分表方案?

如何设计可以动态扩容缩容的分库分表方案?

閱讀本文約花費: 7 (分鐘)面试题 如何设计可以动态扩容缩容的分库分表方案? 面试官心理分析 对于分库分表来说,主要是面对以下问题: 选择一个数据库中间件,调研、学习、测试; 设计你的分库分表的一个方案,你要分成多少个库,每个库分成多少个表,比如 3 个库,每个库 4 个表; 基于选择好的数据库中间件,以及在测试环境建立好的分库分表的环境,然后测试一下能否正常进行分库分表的读写; 完成单库单表到分库分表的迁移,双写方案; 线上系统开始基于分库分表对外提供服务; 扩容了,扩容成 6 个库,每个库需要 12 个表,你怎么来增加更多库和表呢? 这个是你必须面对的一个事儿,就是你已经弄好分库分表方案了,然后一堆库和表都建好了,基于分库分表中间件的代码开发啥的都好了,测试都 ok 了,数据能均匀分布到各个库和各个表里去,而且接着你还通过双写的方案咔嚓一下上了系统,已经直接基于分库分表方案在搞了。 那么现在问题来了,你现在这些库和表又支撑不住了,要继续扩容咋办?这个可能就是说你的每个库的容量又快满了,或者是你的表数据量又太大了,也可能是你每个库的写并发太高了,你得继续扩容。 这都是玩儿分库分表线上必须经历的事儿。 面试题剖析 停机扩容(不推荐) 这个方案就跟停机迁移一样,步骤几乎一致,唯一的一点就是那个导数的工具,是把现有库表的数据抽出来慢慢倒入到新的库和表里去。但是最好别这么玩儿,有点不太…

Read More Read More

线程池运用不当的一次线上事故

线程池运用不当的一次线上事故

閱讀本文約花費: 11 (分鐘)在高并发、异步化等场景,线程池的运用可以说无处不在。线程池从本质上来讲,即通过空间换取时间,因为线程的创建和销毁都是要消耗资源和时间的,对于大量使用线程的场景,使用池化管理可以延迟线程的销毁,大大提高单个线程的复用能力,进一步提升整体性能。 今天遇到了一个比较典型的线上问题,刚好和线程池有关,另外涉及到死锁、jstack命令的使用、JDK不同线程池的适合场景等知识点,同时整个调查思路可以借鉴,特此记录和分享一下。 01 业务背景描述 该线上问题发生在广告系统的核心扣费服务,首先简单交代下大致的业务流程,方便理解问题。 绿框部分即扣费服务在广告召回扣费流程中所处的位置,简单理解:当用户点击一个广告后,会从C端发起一次实时扣费请求(CPC,按点击扣费模式),扣费服务则承接了该动作的核心业务逻辑:包括执行反作弊策略、创建扣费记录、click日志埋点等。 02 问题现象和业务影响 12月2号晚上11点左右,我们收到了一个线上告警通知:扣费服务的线程池任务队列大小远远超出了设定阈值,而且队列大小随着时间推移还在持续变大。详细告警内容如下: 相应的,我们的广告指标:点击数、收入等也出现了非常明显的下滑,几乎同时发出了业务告警通知。其中,点击数指标对应的曲线表现如下: 该线上故障发生在流量高峰期,持续了将近30分钟后才恢复正常。 03 问题调查和事故解决过程 下面…

Read More Read More