博客
关于我
PostgreSQL索引膨胀
阅读量:558 次
发布时间:2019-03-09

本文共 892 字,大约阅读时间需要 2 分钟。

数据库中索引膨胀问题在各大数据库中均存在,包括PostgreSQL。这种现象的根本原因往往与索引结构和数据插入顺序有关。

传统观点认为,索引膨胀是由于数据随机乱序写入所致。由于索引页面中的数据需要按序存储,随机插入会导致索引页频繁分裂,进而使得索引页面无法保持完全 packed(紧凑),最终引发索引膨胀。这种情况在PostgreSQL的btree、gin、gist等索引类型中同样会出现。

以btree索引为例:

  • 首先创建索引,再进行随机乱序数据插入时,索引大小会达到284MB。

  • 先按序插入数据再创建索引,索引大小则减小至214MB。这种差异的原因是,相比随机插入有序插入能更好地利用索引页面格局,减少索引分裂,进而降低索引膨胀的概率。

  • 若先插入数据再创建索引,索引大小也会维持在214MB。与随机插入对比,第一种做法反而会导致索引膨胀。最初的创建操作会将所有数据放入一个树的高度节点中,这种结构在随后随机插入时会经历严重的分裂结果,导致索引膨胀的发生。

  • 通过上述对比可以看出,顺序写入数据不会导致索引膨胀。索引膨胀的产生更多依赖于数据随机插入的方式以及索引树的构建顺序。

    Gin、gist等其他类型的索引也会面临类似的膨胀挑战。这就要求在出现索引膨胀时,必须对其进行重建以确保索引效率和性能。

    在PostgreSQL中,进行索引重建是支持的。重建索引的常规方法包含在同一列中创建新的索引,同时更新旧索引。另外,PostgreSQL还支持通过设置CONCURRENTLY参数对索引进行并行重建。这种机制可以避免在数据解析时出现较大的阻塞问题。具体操作如下:

    CREATE INDEX idx_t_idx ON t_idx (id) USING btree;\di+ idx_t_idx

    或者通过以下命令进行并行重建索引:

    CREATE INDEX CONCURRENTLY idx_t_idx ON t_idx (id) USING btree;

    并行处理可以显著减少索引重建对业务操作的影响,提升系统整体性能。这种方式既保证了索引维护的必要性,又最大化地降低了对在线操作的干扰。

    转载地址:http://yfcpz.baihongyu.com/

    你可能感兴趣的文章
    mysql 断电数据损坏,无法启动
    查看>>
    MySQL 日期时间类型的选择
    查看>>
    Mysql 时间操作(当天,昨天,7天,30天,半年,全年,季度)
    查看>>
    MySQL 是如何加锁的?
    查看>>
    MySQL 是怎样运行的 - InnoDB数据页结构
    查看>>
    mysql 更新子表_mysql 在update中实现子查询的方式
    查看>>
    MySQL 有什么优点?
    查看>>
    mysql 权限整理记录
    查看>>
    mysql 权限登录问题:ERROR 1045 (28000): Access denied for user ‘root‘@‘localhost‘ (using password: YES)
    查看>>
    MYSQL 查看最大连接数和修改最大连接数
    查看>>
    MySQL 查看有哪些表
    查看>>
    mysql 查看锁_阿里/美团/字节面试官必问的Mysql锁机制,你真的明白吗
    查看>>
    MySql 查询以逗号分隔的字符串的方法(正则)
    查看>>
    MySQL 查询优化:提速查询效率的13大秘籍(避免使用SELECT 、分页查询的优化、合理使用连接、子查询的优化)(上)
    查看>>
    mysql 查询数据库所有表的字段信息
    查看>>
    【Java基础】什么是面向对象?
    查看>>
    mysql 查询,正数降序排序,负数升序排序
    查看>>
    MySQL 树形结构 根据指定节点 获取其下属的所有子节点(包含路径上的枝干节点和叶子节点)...
    查看>>
    mysql 死锁 Deadlock found when trying to get lock; try restarting transaction
    查看>>
    mysql 死锁(先delete 后insert)日志分析
    查看>>