B-tree索引适合用于存储排序的数据。对于这种数据类型需要定义大于、大于等于、小于、小于等于操作符。
索引主要被用来提升数据库性能，不当的使用会导致性能变差。 PostgreSQL 提供了多种索引类型： B-tree、Hash、GiST、SP-GiST 、GIN 和 BRIN。每一种索引类型使用了一种不同的算法来适应不同类型的查询。默认情况下，CREATE INDEX 命令创建适合于大部分情况的 B-tree 索引。
作为学院派的数据库，postgresql在底层的架构设计上就考虑了很多算法层面的优化。其中在postgresql9.6版本中推出bloom索引也是十足的黑科技。
简单说，忽略列存储概念，将之认为压缩的行存储。列存储是这个概念的扩展，在下节解释。最基本的磁盘数据结构是B-tree，以TID为索引列。注意，这不是现有的Btree索引，而是独立于表数据存储的另外新Btree。
测试场景的限制GIN索引查询速度是很快的， 在实际生产中，可能出现使用gin索引后，查询速度依然很高的情况，特点就是执行计划中Bitmap Heap Scan占用了大量时间，Bitmap Index Scan大部分标记的块都被过滤掉了。
SQL调优这块呢，大厂面试必问的。最近金九银十嘛，所以整理了SQL的调优思路，并且附几个经典案例分析。
写了600 多篇博客文章后，我以为我已经掌握了cluster命令的复杂性 ，但似乎我还没有，所以现在让我们开始吧。
会发现生成的语句中过滤条件是 WHERE account.id != account.id，使用PostgreSQL Explain ANALYZE 命令，
PostgreSQL 10 版本开始支持逻辑复制，在12版本之前逻辑复制仅支持普通表，不支持分区表，如果需要对分区表进行逻辑复制，需单独对所有分区进行逻辑复制。
关系型数据库都需要产生一个最佳的执行计划从而在查询时耗费的时间和资源最少。通常情况下，所有的数据库都会产生一个以树形式的执行计划：计划树的叶子节点被称为表扫描节点。查询节点对应于从基表获取数据。
PostgreSQL13.0于2020年9月24日正式release，13版本的PG带来很多优秀特性：比如索引的并行vacuum，增量排序，btree索引deduplication，异构分区表逻辑订阅等。在这里面最闪亮的特性非deduplication莫属。
这是我在线上遇到的一个真实的TiDB问题，文章在TiDB AskTug社区专栏中已经发布，可以直接点击底部"阅读原文"到专栏阅读。
使用explain关键字可以模拟优化器执行SQL查询语句，从而知道Mysql是如何处理你的SQL语句的。分析你的查询语句或者表结构的性能瓶颈
数据库的执行计划是SQL优化的最重要手段，执行计划怎么来的、包含什么内容、我们应该关注哪些点，这些是需要我们掌握的，基于这些知识再去理解SQL优化将更加容易。 本文由腾讯云数据库高级架构师何敏带来TDSQL PostgreSQL执行计划详解，以下为分享实录： 在了解PostgreSQL执行计划之前，需要先知道执行计划由来。TDSQL PostgreSQL版任何查询都会经过语法和语义解析，生成查询表达式树，也就是常用查询数，解析器会去解析语法，分析器会把语法对应对象进行展开，通过重写器对规则进行重写，最后生成
TXSQL Parallel DDL 功能建设 DDL（Data Definition Language）是用来修改数据库和表结构的一类操作，是数据库所有操作中最高危也是最重要的一类操作，常见的DDL操作包括：加减列、修改列类型、加减索引等。由于DDL操作涉及到数据库表结构、表数据的重构，尤其是在云数据库场景下，表的数据量急速上涨，DDL操作的效率受到了极大的挑战，一条慢速的DDL操作甚至需要花费几天的时间来完成，在这期间DDL操作持续持有锁，意味着业务可能会面临长时间等待锁的情况，几天的等待对于业务来说是
PostgreSQL从小白到专家，是从入门逐渐能力提升的一个系列教程，内容包括对PG基础的认知、包括安装使用、包括角色权限、包括维护管理、、等内容，希望对热爱PG、学习PG的同学们有帮助，欢迎持续关注CUUG PG技术大讲堂。
过年回来的第二周了，终于有时间继续总结知识了。这次来看一下SQL调优的知识，这类问题基本上面试的时候都会被问到，无论你的岗位是后端，运维，测试等等。 像本文标题中的两个问题，就是我在实际面试过程中遇到的，所以这次就主要围绕着这两个问题来总结一下。
《Postgresql 内幕探索》读书笔记 - 第一章：集簇、表空间、元组 引言 个人建议本章节自己搭建一个Postgresql数据库边实战边阅读更容易理解。 思维导图 图片比较大，这里贴出xmind
PostgreSQL作为传统关系型数据，在设计架构上和Oracle非常相似，下图可以带给你直观的了解。
前一段时间修改数据表时，给一个表添加一个datetime字段，当时遇到了一个问题：我是否需要给该datetime字段上加索引呢？如果不给该字段加索引，当where语句中使用该字段时，会不会扫全表呢？如果给其加了索引，那么势必会带来一些开销，假如这个索引用不到的话，给其加了索引岂不是画蛇添足了呢？
很多时候，我们的慢查询，都是因为没有加索引。如果没有加索引的话，会导致全表扫描的。因此，应考虑在 where 的条件列，建立索引，尽量避免全表扫描。
日常开发中，我们经常会遇到数据库慢查询。那么导致数据慢查询都有哪些常见的原因呢？今天田螺哥就跟大家聊聊导致MySQL慢查询的12个常见原因，以及对应的解决方法。
postgres查询规划过程中，查询请求的不同执行方案是通过建立不同的路径来表达的，在生成许多符合条件的路径之后，要从中选择出代价最小的路径，把它转化为一个计划，传递给执行器执行，规划器的核心工作就是生成多条路径，然后从中找出最优的那一条。
PostgreSQL天然集群，多个集群可以组成集簇，有点类似军队的连、团、旅这样的组织规则。对于我们日常学习使用的单节点则是单个集簇单个集群，自己就是集群。
这里记录的是学习分享内容，文章维护在 Github：studeyang/leanrning-share。
表示从表employees 中取出从10000行开始的5行记录。看似只查询5条记录，实际这条SQL是先读取10005条记录，然后抛弃前10000条记录，然后读到后面5条想要的数据。没有添加单独的order by，表示通过主键排序。
网上已经有很多拿PostgreSQL与MySQL比较的文章了，这篇文章只是对一些重要的信息进行下梳理。在开始分析前，先来看下这两张图：
内容概要 利用主索引提升SQL的查询效率是我们经常使用的一个技巧，但是有些时候MySQL给出的执行计划却完全出乎我们的意料，我们预想MySQL会通过索引扫描完成查询，但是MySQL给出的执行计划却是通过全表扫描完成查询的，其中的某些场景我们可以利用覆盖索引进行优化。 前些天，有个同事跟我说：“我写了个SQL，SQL很简单，但是查询速度很慢，并且针对查询条件创建了索引，然而索引却不起作用，你帮我看看有没有办法优化？”。 我对他提供的case进行了优化，并将优化过程整理了下来。 优化前的表结构、数据量、SQL、
问题 [postgres@pg03 ~]$ psql -h 192.168.1.3 -U postgres -d tdb psql: FATAL: cache lookup failed for access method 403 使用客户端新建连接访问数据库时出现报错，无法建立连接，而访问其他数据库正常。 根本原因 postgresql后端服务进程在初始化阶段加载系统字典表时，由于系统字典表pg_am损坏导致加载失败，初始化失败报错退出。 诊断步骤 PG后端服务进程在被fork出来之后会进行如下函数
leaf 叶子 存储数据行时就是有序的 直接将数据行的page作为叶子节点（相邻的叶子节点，有双向指针）
注意:本文基于mysql5.7进行操作,各个版本的mysql使用Explan会有微小的差异
Bitmap索引扫描是对索引扫描的一个优化，通过建立位图的方式将原来的随机堆表访问转换成顺序堆表访问。主要分为两点：1）管理每个Bitmap的hash slot没用完时，每个Bitmap代表每个heap页中满足条件元组的ItemIDs，通过Bitmap扫描heap页时需要将所有Bitmap按照页号进行排序，然后依次获取heap页中记录，依次完成顺序回表。2）当hash slot用完时，就需要将heap页的bitmap范围扩大，转换成一个chunk的bitmap，也就是Bitmap中一位代表页内具有满足条件元组的页。此时，整个Bitmaps有chunk的bitmap也有页的bitmap，该chunk的页号为chunk内最小页号，所以Bitmaps排序后，整体上也是有序的。如此完成顺序扫描heap页，只不过对于Chunk的bitmap中一位代表的heap 页需要再次进行条件检测，将满足条件的tuple输出。
如果有多条数据需要同时插入，不要每次插入一条，然后分多次插入，因为每执行一次插入的操作，都要进行数据库的连接，多个操作就会连接多次，而一次批量操作只需要连接1次
在postgresql11之前，为表增加一个包含非空默认值的字段，将会导致表重写，为每一行添加该字段，并填充默认值。如果该表在增加字段前非常大，那么将会非常耗时。
greenplum Schema 是 Database中逻辑组织object和data。 在同一Database中，不同schema的对象可以使用相同的名称。
谈到索引失效，大家可能都能列举出几个场景，比如：后模糊查询、条件中带函数、索引中断等等。今天我想和你分享另一个场景：索引成本分析。
任何一个系统，分页查询都是必不可少的吧 ，MySQL中的分页查询 就是 limit呗 ，你有没有感觉到 越往后翻页越慢 ，常见的SQL如下
mysql中可以使用explain这个关键字来获取（查询）sql语句的查询执行计划的。使用explain关键字，可以模拟mysql优化器执行的sql语句，从而知道mysql是如何处理sql语句的。通过explain可以分析查询语句或表结构的性能瓶颈。
最近在写SQL语句时，对选择IN 还是Exists 犹豫不决，于是把两种方法的SQL都写出来对比一下执行效率，发现IN的查询效率比Exists高了很多，于是想当然的认为IN的效率比Exists好，但本着寻根究底的原则，我想知道这个结论是否适用所有场景，以及为什么会出现这个结果。
5.11.6. Best Practices for Declarative Partitioning
如果一次性需要插入大批量数据(比如: 几百万的记录)，使用insert语句插入性能较低，此时可以使用MySQL数据库提供的load指令进行插入。操作如下：
由于系统表中OID全部都是原User OID与新User OID对不上，如果将系统表对应的OID全部更新为新的User OID工作量比较大，所以选择根据原User OID 重建pg_authid表
这天我正在午休呢，公司DBA就把我喊醒了，说某库出现大量慢SQL，很快啊，很快，我还没反应过来，库就挂了，我心想现在的用户不讲武德啊，怎么在我睡觉的时候大量请求呢。
内容为慕课网的"高并发 高性能 高可用 MySQL 实战"视频的学习笔记内容和个人整理扩展之后的笔记，本节内容讲述的索引优化的内容，另外本部分内容涉及很多优化的内容，所以学习的时候建议翻开《高性能Mysql》第六章进行回顾和了解，对于Mysql数据的开发同学来说大致了解内部工作机制是有必要的。
服务器硬件的性能瓶颈：top,free, iostat和vmstat来查看系统的性能状态
Vacuum是PG的一个重要功能用于回收表和索引中的死记录。如果没有这个功能，PG就会持续膨胀。本文介绍VACUUM命令中的PARALLEL选项，该选项于PG13引入。
在涉及order by操作的sql时，b-tree索引返回的结果是有序的，可以直接返回，而其他索引类型，需要对索引返回结果再进行一次排序。b-tree索引的默认排序为升序，空值放在最后，创建索引时可以指定排序方式，如按倒序排序时，空值默认是放在最前的，但往往我们的查询并不想展示空值的结果，此时可以在创建索引时指定排序desc nulls last以达到和查询sql切合的目的。
好长时间不进行研究了，最近被突发的问题想到了INDEX 的问题，随机想到数据和INDEX 存储在一起会怎样，我们将索引和数据进行分离后，会不会对数据库的性能有优化的可能。
领取专属 10元无门槛券
手把手带您无忧上云
