聚集索引和非聚集索引简析与对比

聚集(clustered)索引,也叫聚簇索引 定义:数据行的物理顺序与列值(一般是主键的那一列)的逻辑顺序相同,一个表中只能拥有一个聚集索引。 注:第一列的地址表示该行数据在磁盘中的物理地址,后面三列才是我们SQL里面用的表里的列,其中id是主键,建立了聚集索引。 结合上面的表格就可以理解这句话了吧:数据行的物理顺序与列值的顺序相同,如果我们查询id比较靠后的数据,那么这行数据的地址在磁盘中的物理地址也会比较靠后。而且由于物理排列方式与聚集索引的顺序相同,所以也就只能建立一个聚集索引了。 从上图可以看出聚集索引的好处了,索引的叶子节点就是对应的数据节点(MySQL的MyISAM除外,此存储引擎的聚集索引和非聚集索引只多了个唯一约束,其他没什么区别),可以直接获取到对应的全部列的数据, »

基于Canal和Kafka实现MySQL的Binlog近实时同步

前提 近段时间,业务系统架构基本完备,数据层面的建设比较薄弱,因为笔者目前工作重心在于搭建一个小型的数据平台。优先级比较高的一个任务就是需要近实时同步业务系统的数据(包括保存、更新或者软删除)到一个另一个数据源,持久化之前需要清洗数据并且构建一个相对合理的便于后续业务数据统计、标签系统构建等扩展功能的数据模型。基于当前团队的资源和能力,优先调研了Alibaba开源中间件Canal的使用。 这篇文章简单介绍一下如何快速地搭建一套Canal相关的组件。 关于Canal 简介 下面的简介和下一节的原理均来自于Canal项目的README: Canal[kə'næl],译意为水道/管道/沟渠,主要用途是基于MySQL数据库增量日志解析,提供增量数据订阅和消费。早期阿里巴巴因为杭州和美国双机房部署,存在跨机房同步的业务需求, »

理解数据仓库中星型模型和雪花模型

在数据仓库的建设中,一般都会围绕着星型模型和雪花模型来设计表关系或者结构。下面我们先来理解这两种模型的概念。 星型模型 ​ 星型模是一种多维的数据关系,它由一个事实表和一组维表组成。每个维表都有一个维作为主键,所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理,将多个维度集合到一个事实表,形成一个宽表。这也是我们在使用hive时,经常会看到一些大宽表的原因,大宽表一般都是事实表,包含了维度关联的主键和一些度量信息,而维度表则是事实表里面维度的具体信息,使用时候一般通过join来组合数据,相对来说对OLAP的分析比较方便。 雪花模型 ​ 当有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上时,其图解就像多个雪花连接在一起,故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化,原有的各维表可能被扩展为小的事实表, »

来自淘宝的分布式数据层-TDDL

​ 淘宝根据自身业务需求研发了TDDL(Taobao Distributed Data Layer)框架,主要用于解决分库分表场景下的访问路由(持久层与数据访问层的配合)以及异构数据库之间的数据同步,它是一个基于集中式配置的JDBC DataSource实现,具有分库分表、Master/Salve、动态数据源配置等功能。 就目前而言,许多大厂也在出一些更加优秀和社区支持更广泛的DAL层产品,比如Hibernate Shards、Ibatis-Sharding等。TDDL位于数据库和持久层之间,它直接与数据库建立交道,如图所示: ​ 淘宝很早就对数据进行过分库的处理,上层系统连接多个数据库,中间有一个叫做DBRoute的路由来对数据进行统一访问。 »

MySQL的执行计划与代价模型详细解析

背景 为了后续的沟通方便,在20200213的早上创建了一个《简栈-Java技术交流群》,也方便大家通过扫二维码积极的参与进来。 如果是二维码已经过期,大家可以添加简栈文化-小助手的微信号(lastpass4u),然后让他拉大家进群进群。我们保持着小而美的精神,宁缺毋滥。 然后早上群里就有人提了一个问题: 执行计划里面的扫描函数跟执行时间不匹配,比如查询优化器发现,扫描a索引行数更多,所以更慢,因此优化器选择了索引b, 但实际上走b索引的时候比a更慢,走a索引大概是4秒左右,b是8秒。 这个问题激发起了大家的讨论,有的人建议说: 1、这种可以强制指定索引执行的吧 2、这个扫描行数都是预估的不一定准的, »

KeepAlived保证Mysql主从自动切换

环境准备 前面有几篇文章对于MySQL主从搭建做了一些铺垫: 文章一:MySQL中Binlog的常用设置 文章二:MySQL主从同步-原理&实践篇 先启动Master与Slave的2台mysql服务器,具体信息如下: ➜ ~ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 8f31266d08fc docker-mysql-master:v1 "/usr/sbin/ »

MySQL主从同步-原理&实践篇

什么是mysql的主从复制? MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式,这样从节点不用一直访问主服务器来更新自己的数据,数据的更新可以在远程连接上进行,从节点可以复制主数据库中的所有数据库或者特定的数据库,或者特定的表。 Mysql复制原理 原理: (1)Master服务器将数据的改变记录二进制Binlog日志,当Master上的数据发生改变时,则将其改变写入二进制日志中; (2)Slave服务器会在一定时间间隔内对Master二进制日志进行探测其是否发生改变,如果发生改变,则开始一个I/OThread请求Master二进制事件 (3)同时主节点为每个I/O线程启动一个Dump线程,用于向其发送二进制事件,并保存至从节点本地的中继日志中,从节点将启动SQL线程从中继日志中读取二进制日志, »

MySQL Binlog设置

获取mysql镜像 ➜ ~ docker pull mysql ➜ ~ docker images REPOSITORY TAG IMAGE ID CREATED SIZE mysql latest d435eee2caa5 3 weeks ago 456MB 启动mysql ➜ ~ docker run -itd --name docker-mysql-master -v »

MySQL锁

MySQL锁分类 每次在听别人说锁的时候,是不是会有点儿晕?(一会儿排它锁,一会儿GAP锁...)因为你站在不同的角度来说,它的名字就会不同。根据我们DB的引擎、隔离级别不同,导致的锁的情况也会不同。 下面根据几种不同的类型对锁做一个划分: 力度划分: 表级锁:表级锁是MySQL中锁定粒度最大的一种锁,表示对当前操作的整张表加锁,它实现简单,资源消耗较少,被大部分MySQL引擎支持。最常使用的MYISAM与INNODB都支持表级锁定,开销小,加锁快,粒度大,锁冲突概率大,并发度低,适用于读多写少的情况。 页级锁: »

Ten MySQL performance tuning settings after installation-安装完 MySQL 后必须调整的 10 项配置

这是一篇关于MySQL配置非常好的文章,原文地址:https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/ 然后,翻译我是转载的OSC的一篇:http://www.oschina.net/translate/10-mysql-settings-to-tune-after-installation 正文 当我们被人雇来监测MySQL性能时,人们希望我们能够检视一下MySQL配置然后给出一些提高建议。许多人在事后都非常惊讶,因为我们建议他们仅仅改动几个设置,即使是这里有好几百个配置项。这篇文章的目的在于给你一份非常重要的配置项清单。 »