BTree

背景 在日常的生活中，我们可能会经常需要一些像相近、相仿、距离接近、性格接近等等类似这样的需求，对数据进行筛选。 这些需求PostgreSQL居然都支持，是不是很变态。 变态的例子 这些场景都支持索引排序和检索，否则怎么叫变态呢。 按长相相似度排序 比如最近的王宝强和马蓉的事件，估计很多人会拿宋喆的照片进行相似度的搜索，八卦八卦。 说起图像搜索，我前几天才写了一篇这样的文章，是关于在PG数据库中使用图像搜索插件的文章。 《弱水三千,只取一瓢,当图像搜索遇见PostgreSQL(Haar wavelet)》 https://yq.aliyun.com/articles/58246 按喜好重合度排序 比如收集了人群的各种喜好的数据，按喜好进行聚类，或者按喜好的重叠度进行排序，找出目标人群。 按年龄相近程度排序 这个相对简单，比如输入23岁，按接近23岁的输出即可。 例子 https://www.postgresql.org/docs/9.5/static/btree-gist.html 输出与100最接近的10条数据。 postgres= # create extension btree_gist; CREATE EXTENSION postgres =# create table test12( id int ); CREATE TABLE postgres =# insert

原文来自 https://blog.csdn.net/qq_27529917/article/details/87904179 先构建本篇博客的案列演示表： create table a ( a1 int primary key , a2 int , index ( a2 ) ) ; --双字段都有索引 create table c ( c1 int primary key , c2 int , index ( c2 ) , c3 int ) ; --双字段都有索引 create table b ( b1 int primary key , b2 int ) ; --有主键索引 create table d ( d1 int , d2 int ) ; --没有索引 insert into a values ( 1 , 1 ) , ( 2 , 2 ) , ( 3 , 3 ) , ( 4 , 4 ) , ( 5 , 5 ) , ( 6 , 6 ) , ( 7 , 7 ) , ( 8 , 8 ) , ( 9 , 9 ) , ( 10 , 10 ) ; insert into b values ( 1 , 1 ) , ( 2 , 2 ) , ( 3 , 3 ) , ( 4 , 4 ) , ( 5 , 5 ) , ( 6 , 6 ) , ( 7 , 7 ) , ( 8 , 8 ) , ( 9

许多现代编程语言都将哈希表作为基本数据类型。从表面上看，哈希表看起来像一个常规数组，使用任何数据类型(例如字符串)建立索引，而不仅是使用整数。PostgreSQL中的哈希索引也是以类似的方式构造的。这是如何运作的呢? 作为一个规则，数据类型允许的值范围非常大:在一个类型为«text»的列中，我们可以设想有多少不同的字符串?同时，在某个表的«text»的列中实际存储了多少不同的值?通常不会有那么多。 哈希的思想是将一个小数字(从0到N−1,N个值)与任意数据类型的值相关联。这样的关联称为哈希函数。获得的数字可以用作常规数组的索引，其中存储对表行(tid)的引用。这个数组的元素称为哈希表bucket——如果同一个索引值出现在不同的行中，那么一个bucket可以存储多个tid。 哈希函数越均匀地按桶分配原值，效果就越好。但即使是一个好的哈希函数，有时也会对不同的原值产生相同的结果——这叫做冲突。因此，一个bucket可以存储对应于不同键的TIDs，因此，需要重新检查从索引中获得的TIDs。 举个例子，我们能想到字符串的哈希函数是什么?让桶的数目为256。然后，以桶号为例，我们可以获取第一个字符的代码(假设采用单字节字符编码)。这是个好的哈希函数吗?显然不是:如果所有字符串都以相同的字符开头，那么它们都将进入一个bucket，因此一致性是不可能的，所有的值都需要重新检查

阅读目录 　　初识索引 　　索引的原理 　　索引的数据结构 　　聚集索引与辅助索引 　　MySQL索引管理 　　测试索引 　　正确使用索引 　　联合索引 　　查询优化神器-explain 　　慢查询优化的基本步骤 　　慢日志管理 返回顶部 一 初识索引 为什么要有索引? 一般的应用系统，读写比例在10:1左右，而且插入操作和一般的更新操作很少出现性能问题，在生产环境中，我们遇到最多的，也是最容易出问题的，还是一些复杂的查询操作，因此对查询语句的优化显然是重中之重。说起加速查询，就不得不提到索引了。 什么是索引？ 索引在MySQL中也叫是一种“键”，是存储引擎用于快速找到记录的一种数据结构。索引对于良好的性能 非常关键，尤其是当表中的数据量越来越大时，索引对于性能的影响愈发重要。 索引优化应该是对查询性能优化最有效的手段了。索引能够轻易将查询性能提高好几个数量级。 索引相当于字典的音序表，如果要查某个字，如果不使用音序表，则需要从几百页中逐页去查。 你是否对索引存在误解？ 索引是应用程序设计和开发的一个重要方面。若索引太多，应用程序的性能可能会受到影响。而索引太少，对查询性能又会产生影响，要找到一个平衡点，这对应用程序的性能至关重要。一些开发人员总是在事后才想起添加索引----我一直认为，这源于一种错误的开发模式。如果知道数据的使用，从一开始就应该在需要处添加索引

MYSQL MYSQL架构介绍 MYSQL简介 MySQL是一个关系型数据库管理系统，由瑞典MySQL AB公司开发，目前属于Oracle公司。 MySQL是一种关联数据库管理系统，将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这就增加速度并提高了灵活性。 MYSQL安装 安装 在 Ubuntu 18.04.3下安装mysql8 wget https://dev.mysql.com/get/mysql-apt-config_0.8.15-1_all.deb sudo dpkg -i mysql-apt-config_0.8.15-1_all.deb sudo apt install mysql-server mysql -u root -p select host, user, authentication_string, plugin from mysql.user; MYSQL用户与权限管理 MYSQL用户管理 1.创建用户 创建hb用户，密码123 create user 'hbx'@'%' identified with mysql_native_password by '123'; 创建hb用户，ip:192.118.1.1,密码123 create user 'hb'@'192.118.1.1' identified by '123'; 创建ip：192

前言 上周新系统改版上线，上线第二天就出现了较多的线上 慢sql 查询，紧接着dba 给出了定位及解决方案，这里较多的是使用 延迟关联 去优化。 而我对于这个 延迟关联 也是第一次听说（o(╥﹏╥)o），所以今天一定要学习并产出一篇学习笔记。( ^▽^ ) 回表 我们都知道InnoDB采用的B+ tree来实现索引的，索引又分为主键索引(聚簇索引)和普通索引(二级索引)。 那么我们就来看下 基于主键索引和普通索引的查询有什么区别？ 如果语句是select * from T where ID=500，即主键查询方式，则只需要搜索ID这棵B+树； 如果语句是select * from T where k=5，即普通索引查询方式，则需要先搜索k索引树，得到ID的值为500，再到ID索引树搜索一次。这个过程称为回表。 举个栗子： 可以看出我们有一个普通索引k，那么两颗B+树的示意图如下： （注：图来自极客时间专栏） 当我们查询 select * from T where k=5 其实会先到k那个索引树上查询k = 5，然后找到对应的id为500，最后回表到主键索引的索引树找返回所需数据。 如果我们查询 select id from T where k=5 则不需要回表就直接返回。 也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。 覆盖索引 解释一

Index(索引)这个概念对于很多熟悉关系型数据库的人来说，不是一个陌生的概念。当表中数据越来越多时，在查询时，为了避免全表查询（sequence scan)可以在查询相关的条件字段上添加索引。举例来说明index对于查询效率的影响。首先创建测试表 "sort_test"，如下时表创建SQL，可以发现此表有2个字段id和salary。其中id是主键，我们知道属于主键的字段是默认添加了索引的。 CREATE TABLE public.sort_test( id bigint NOT NULL, salary numeric NOT NULL, CONSTRAINT sort_test_pkey PRIMARY KEY (id)) TABLESPACE pg_default; ALTER TABLE public.sort_test OWNER to postgres; 以以下SQL查询语句为例进行讲解，其中查询字段salary上没有创建索引。 select * from public."sort_test" where salary = 101; 那么此时的执行计划和执行时间是多少呢，可以参考下图，执行计划是走Parallel Seq Scan，SQL运行时间是 246.71 ms. 那么如果要在salary字段上添加索引呢?创建索引的语句如下： CREATE INDEX index

目录 背景 一、安装pg_stat_statements 二、加载pg_stat_statements模块 三、配置pg_stat_statements采样参数 四、创建pg_stat_statements extension 五、分析TOP SQL pg_stat_statements输出内容介绍 最耗IO SQL 最耗时 SQL 响应时间抖动最严重 SQL 最耗共享内存 SQL 最耗临时空间 SQL 六、重置统计信息 慢SQL到底慢在哪里？ 七、慢SQL、TOP SQL优化示例 八、常见优化点汇总 参考 背景 数据库是较大型的应用，对于繁忙的数据库，需要消耗大量的内存、CPU、IO、网络资源。 SQL优化是数据库优化的手段之一，优化什么SQL效果最佳呢？首先要了解最耗费资源的SQL，即TOP SQL。 从哪里可以了解数据库的资源都被哪些SQL消耗掉了呢？ 资源分为多个维度，CPU，内存，IO等。如何能了解各个维度层面的TOP SQL呢？ pg_stat_statements插件可以用于统计数据库的资源开销，分析TOP SQL。 一、安装pg_stat_statements 如果您使用的是云数据库，跳过安装，到create extension 部分。 pg_stat_statements是PostgreSQL的核心插件之一。可以在编译PostgreSQL时安装，也可以单独安装。

对于order by的优化，MySQL若可以利用索引的有序性进行排序，则优先使用索引进行排序，这种情况的执行效率是最快的；若无法有效利用索引的情况下，MySQL主要有3排序种算法对其进行优化每个算法都有一定的适用场景。 一、 利用索引排序 B-tree索引可以很好的支持单点查询、范围查询、有序性查询。所以对于order by 的排序查询，我们可以利用B-tree的有序性来有效的利用索引进行排序查询。当然，如果可以利用索引进行排序对我们的SQL查询本身也是有一定的要求限制的。 1.1 利用索引排序的特点 1）排序列必须有B-tree索引 2）如果为多表关联查询，排序列必须是对驱动表字段的排序 1.2、示例 ##建表语句，sbtest3与sbtest4表字段与索引一致，sbtest3的表数据量为30000，sbtest4的表数据量为60000 CREATE TABLE `sbtest4` ( `id` int(11) NOT NULL AUTO_INCREMENT, `k` int(11) NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k_4` (`k`) ) ENGINE=InnoDB AUTO

MySQL数据库的常用索引 本文关键字：数据库、MySQL、索引的作用、常用索引 在使用数据库的过程中，经常会进行数据的查询。随着数据量的增大，查询的时间会变的原来越长，这就需要合理的建立索引来提高查询效率。 一、索引概述 1. 数据库检索 在讲述索引之前我们要先来简单介绍一下数据库中是如何进行数据查询的，这更有助于我们理解索引。对于数据库来说，本质上是一个软件，或者可以称为一个系统，提供了对于数据管理的功能。存放在数据表中的数据其实同样是存储在磁盘上，对于不同的数据库，会以不同的数据格式文件存在。 在进行数据库检索时，尤其是条件查询，解析SQL指令后，本质上是对数据存储文件的扫描。我们所使用的绝大部分关系型数据库的表结构采用的都是行式存储，也就是一条数据是一行，每一列的数据是在这一行中以某种分隔符来分隔。数据库在进行数据扫描时也是通过游标（cursor）以行为单位来进行操作，与之相对的就是列式存储（column table），比如HANA。 那么在进行条件查询时，会逐行进行扫描，通过移动游标指定到不同的行，然后再获取到对应的列的值，比对，确定结果，在数据量比较小的时候我们可以忽略时间问题，但当数据量很大时（千万级）问题就很明显了，查询速度很难接受，在使用索引前，数据查询的过程可以这样表示： 2. 索引的作用 说到索引，大家一定都很熟悉目录，如果我们把数据表看成一本书的话