存储引擎

【摘要】 这是从《MySQL性能调优与架构设计》第六章摘录的一些知识点。 【主题】 Hash索引 B-Tree索引 【内容】 1. Hash索引 Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。 可能很多人又有疑问了，既然 Hash 索引的效率要比 B-Tree 高很多，为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢？任何事物都是有两面性的，Hash 索引也一样，虽然 Hash 索引效率高，但是 Hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。 （1）Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。 由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系，并不能保证和Hash运算前完全一样。 （2）Hash 索引无法被用来避免数据的排序操作。 由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值，而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样

前言 工作的这些年发现一个比较奇怪的现象就是身边无论是工作十多年的老兵，还是初级刚入行的程序员，在高谈阔论技术和趋势的时候都是人工智能，大数据，区块链，各种框架，语言，算法，AI，BI，CI，DI…… 等等，倒是发现很少有人关注数据库，不知道是因为数据库感觉太低端还是太低调，总是不容易被人提起 技术就是这样，不太关注的地方就不会重视，越是不被重视的地方，掉进坑里的概率就会越大，所以就在这里给大家简单聊聊在使用数据库过程中有哪些防掉坑指南，也可以对刚入行的小朋友有一个提醒的作用，万丈高楼平地起，一定要先打好基础再去考虑上层的建筑，不要舍本逐末 本章主要分以下四个小节（预计读完 5 分钟左右）： 数据库为什么重要 数据库有哪些使用技巧 数据库有哪些容易掉进去的坑？ 深入学习数据库的建议 数据库为什么重要 很多人在开发过程中不太关注数据库，对于表结构的设计也没什么讲究大多属于“能用就行”，但是根据作者将近十年的开发经验来看的话，只要你是从事 Web 相关领域开发你就无法避免不和数据库打交道， 在Web开发中大多功能操作本质上都是对数据库进行操作 ，不管你用是 Pythod，Java，Ruby 等语言进行 Web 开发，你其实都是在面向数据库进行编程，很多 Web 框架作者为了避免程序员接触数据库的相关知识甚至还封装了一层 ORM （Object Relational Mapping

1.MySQL整体逻辑架构 mysql 数据库的逻辑架构如下图： 第一层，即最上一层 ，所包含的服务并不是MySQL所独有的技术。它们都是服务于C/S程序或者是这些程序所需要的 ：连接处理，身份验证，安全性等等。 第二层值得关注 。这是MySQL的核心部分。通常叫做 SQL Layer。在 MySQL据库系统处理底层数据之前的所有工作都是在这一层完成的，包括权限判断， sql解析，行计划优化， query cache 的处理以及所有内置的函数(如日期,时间,数学运算,加密)等等。各个存储引擎提供的功能都集中在这一层，如存储过程，触发器，视 图等。 第三层包括了存储引擎 。通常叫做StorEngine Layer ，也就是底层数据存取操作实现部分，由多种存储引擎共同组成。它们负责存储和获取所有存储在MySQL中的数据。就像Linux众多的文件系统 一样。每个存储引擎都有自己的优点和缺陷。服务器是通过存储引擎API来与它们交互的。这个接口隐藏 了各个存储引擎不同的地方。对于查询层尽可能的透明。这个API包含了很多底层的操作。如开始一个事 物，或者取出有特定主键的行。存储引擎不能解析SQL，互相之间也不能通信。仅仅是简单的响应服务器 的请求。 连接管理和安全 在服务器内部，每个client连接都有自己的线程。这个连接的查询都在一个单独的线程中执行。这些线程轮流运行在某一个CPU内核

作为一个程序员，几乎所有人都使用过 SQL 语言，无论是在命令行执行、程序调用，还是在 SQL 工具里，你都做过这样的事：写一个规范的 SQL 语句，然后等待数据库返回的结果，然后再基于结果做各种逻辑处理。但是，你知道这条 SQL 语句是咋执行的吗？我打赌你并不是很清楚，读完全文，你会有完全不同的感受。 我们经常说，看一个事儿千万不要直接陷入细节里，你应该先鸟瞰其全貌，这样能够帮助你从高维度理解问题。同样，对于 MySQL 的学习也是这样。平时我们使用数据库，看到的通常都是一个整体。比如，你有个最简单的表，表里只有一个 ID 字段，在执行下面这个查询语句时： mysql> select * from T where ID=10; 我们看到的只是输入一条语句，返回一个结果，却不知道这条语句在 MySQL 内部的执行过程。 今天我们就把 MySQL 拆解一下，看看里面都有哪些“零件”，希望借由这个拆解过程，让你对 MySQL 有更深入的理解。这样当我们碰到 MySQL 的一些异常或者问题时，就能够直击本质，更为快速地定位并解决问题。 下面我给出的是MySQL的基本架构示意图，从中你可以清楚地看到SQL语句在MySQL的各个功能模块中的执行过程。 MySQL的逻辑架构图 大体来说，MySQL 可以分为 Server 层和存储引擎层两部分。 Server层包括连接器、查询缓存、分析器

最近一段时间都学习mysql，将重要的知识点总结如下： 一、字段、表、索引设计规范相关 二、事务相关 三、锁相关 四、存储引擎相关 五、大表优化相关 六、索引优化相关 七、语句优化相关 一、字段、表、索引设计规范 1、字段设计规范 ① 字段类型优先选择符合存储需要的最小类型 字段类型优先级：整型>date;time >enum>char;varchar>blob 原因：整型，time运算快，节省内存；enum列内部是用整型存储的，char，varchar要考虑字符集的转换和排序的校对集，速度慢；blob无法使用临时表。 ② 够用就行（如smallint，varchar(N)） 原因：大的字段浪费内存，影响速度，如varchar(10),varchar(300),虽然存储的内容一样，但是,在表联查时，varchar(300)要花更多内存 ③ 尽量避免使用允许为null() 原因：null不利于索引，要用特殊的字节标注，在磁盘上占的空间其实更大 例子：建两个相同字段的表，一个允许为null，一个不允许。可以发现为null的索引更大些。 ④ 避免使用ENUM类型 修改ENUM值需要使用ALTER语句 ENUM类型的ORDER BY操作效率低，需要额外操作 禁止使用数值作为ENUM的枚举值 ⑤ 使用TIMESTAMP（4个字节）或DATETIME类型（8个字节）存储时间 TIMESTAMP

MySQL 5.6, 5.7, 8.0的新特性 对于MySQL的历史，相信很多人早已耳熟能详，这里就不要赘述。下面仅从产品特性的角度梳理其发展过程中的里程碑事件。 1995年，MySQL 1.0发布，仅供内部使用。 1996年，MySQL 3.11.1发布，直接跳过了MySQL 2.x版本。 1999年，MySQL AB公司成立。同年，发布MySQL 3.23，该版本集成了Berkeley DB存储引擎。该引擎由Sleepycat公司开发，支持事务。在集成该引擎的过程中，对源码进行了改造，为后续可插拔式存储引擎架构奠定了基础。 2000年，ISAM升级为MyISAM存储引擎。同年，MySQL基于GPL协议开放源码。 2002年，MySQL 4.0发布，集成了后来大名鼎鼎的InnoDB存储引擎。该引擎由Innobase公司开发，支持事务，支持行级锁，适用于OLTP等高并发场景。 2005年，MySQL 5.0发布，开始支持游标，存储过程，触发器，视图，XA事务等特性。同年，Oracle收购Innobase公司。 2008年，Sun以10亿美金收购MySQL AB。同年，发布MySQL 5.1，其开始支持定时器（Event scheduler），分区，基于行的复制等特性。 2009年，Oracle以74亿美金收购Sun公司。 2010年， MySQL 5.5 发布

教程链接： http://c.biancheng.net/view/2361.html 什么是存储引擎 数据库存储引擎是数据库底层软件组件， 数据库管理系统使用数据引擎进行创建、查询、更新和删除数据操作 。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能，使用不同的存储引擎还可以获得特定的功能。 提示： InnoDB 事务型数据库的首选引擎，支持事务安全表（ACID），支持行锁定和外键。MySQL 5.5.5 之后，InnoDB 作为默认存储引擎。 MyISAM 是基于 ISAM 的存储引擎，并对其进行扩展，是在 Web、数据仓储和其他应用环境下最常使用的存储引擎之一。MyISAM 拥有较高的插入、查询速度，但不支持事务。 MySQL存储引擎种类 存储引擎能够根据具体的应用建立不同存储引擎表。 1 #存储引擎种类 2 InnoDB 3 MyISAM 4 MEMORY 5 ARCHIVE 6 FEDERATED 7 EXAMPLE 8 BLACKHOLE 9 MERGE 10 NDBCLUSTER 11 CSV 其他分支 percona : XtraDB MariaDB : InnoDB 其他的引擎: TokuDB , MyRocks Compression: 25x for high compression Fast Insertions and Deletions

存储引擎都是作用在表上的 MyISAM索引文件和数据文件是分离的（非聚集）最终一个表会形成3个文件 例如表名叫 aa,形成的3个文件分别叫aa.frm(存储表的结构信息，就是有哪些字段等信息)，aa.MYD(存储数据)，aa.MYI(存储索引文件) InnoDB索引实现（聚集） InnoDB的表最终会形成2个文件，bb.frm(存储表的结构信息，就是有哪些字段等信息),bb.idb(索引和数据) 来源： CSDN 作者： softwareDragon 链接： https://blog.csdn.net/qq_33348135/article/details/104435383

1. 概述 ClickHouse 是一个用于联机分析 (OLAP:Online Analytical Processing) 的列式数据库管理系统 (DBMS:Database Management System) ，简称 CK 。 ClickHouse 是一个完全的列式数据库管理系统，允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器， 支持线性扩展，简单方便，高可靠性，容错 。 ClickHouse 官方文档： https://clickhouse.yandex/docs/en/ 2. 应用场景 OLAP 场景关键特征： 大多数是读请求 数据总是以相当大的批 (> 1000 rows) 进行写入 不修改已添加的数据 每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列 宽表，即每个表包含着大量的列 较少的查询 ( 通常每台服务器每秒数百个查询或更少 ) 对于简单查询，允许延迟大约 50 毫秒 列中的数据相对较小： 数字和短字符串 ( 例如，每个 UR60 个字节 ) 处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行） 事务不是必须的 对数据一致性要求低 每一个查询除了一个大表外都很小 查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中 应用场景： 用于结构良好清晰且不可变的事件或日志流分析 。 不适合的场景

简介：Windows Azure Storage（WAS）是微软的一种分布式云存储系统，允许用户在上面存储数据，并且存储空间可以无限增长（表面上）。WAS中，数据存储在分布式系统中。WAS可以存储Blobs（文件），tables（结构化存储），Queues（消息队列），这篇文章主要总结了WAS的架构，全局定义和一些数据模型。 关键词：云计算，分布式存储系统，Windows Azure 第一部分：介绍 　　WAS是一种可扩展的的云存储技术，在2008年开始时上线，在微软的内部开始使用。WAS给出的格式是Blobs（文件），tables（结构化存储），Queues（消息队列），这三种格式的数据几乎提供了所有的存储形式，可以应用到大多数的应用中，最常见的一种存入取出的形式就是blobs，也就是各种形式的文件数据。queue提供了数据流的形式，最终也是以blob和tables的形式存储。 　　一个例子，构建在WAS中的一个引擎可以提供近乎实时的Facebook和Twitter的搜索服务。这种服务是一种大数据流水线计算的一部分，来提供可搜索的内容（15秒内用户的消息和状态更新）,内容还是以blobs存储。引擎可以解析用户的各种信息记录等，分类。信息被分类整理好以后，交给bing引擎去搜索。这个解析引擎会使用queue来管理流数据，做索引以及发送给搜索引擎的耗时。在这篇论文发表的时候