搜尋
首頁資料庫mysql教程使用局部索引来提升 PostgreSQL 的性能

大家可能还不知道 PostgreSQL 支持对表数据进行局部索引吧? 它的好处是既能加快这部分索引过的数据的读取速度, 又不会增加额外开

大家可能还不知道 PostgreSQL 支持对表数据进行局部索引吧?  它的好处是既能加快这部分索引过的数据的读取速度, 又不会增加额外开销.  对于那些反复根据给定的 WHERE 子句读出来的数据, 最好的办法就是对这部分数据索引. 这对某些需要预先进行聚集计算的特定分析工作流来说, 很合适. 本帖中, 我将举一个例子说明如何通过部分索引优化数据查询.

假设有这样一个事件表, 结构如下:

每个事件关联一个用户, 有一个 ID, 一个时间戳, 和一个描述事件的 JSON. JSON 的内容包含页面的路径, 事件的类别 (如: 单击, 网页浏览, 表单提交), 以及其他跟事件相关的属性。

我们使用这个表存储各种事件日志. 假设我们手上有个事件自动跟踪器 , 能自动记录用户的每一个点击, 每一次页面浏览, 每一次表单提交, 以便我们以后做分析. 再假设我们想做个内部用的报表(internal dashboard)显示一些有价值的数据(high-value metrics), 如:每周的注册数量, 每天应收帐款. 那么, 问题就来了. 跟这个报表相关的事件, 只占该事件表数据的一小部分 -- 网站的点击量虽然很高, 但是只有很小一部分最终成交! 而这一小部分成交数据跟其他数据混杂放在一起, 也就是说, 它的信噪比很低. 

我们现在想提高报表查询的速度.  先说注册事件吧, 我们把它定义为:注册页面(/signup/)的一次表单提交. 要获得九月份第一周的注册数量, 可以理解成:

对一个包含1千万条记录, 其中只有 3000 条是注册记录, 并且没有做过索引的数据集, 执行这样的查询需要 45 秒.

对单列做全索引(Full Indexes) : 大杂烩

提高查询速度, 比较傻的办法是: 给事件相关的各种属性创建单列索引(single-column index):(data->>'type'),(data->>'path'), 和 time. 通过 bitmap,  我们可以把这三个索引扫描结果合并起来.  如果我们只是有选择地查询其中一部分数据, 而且相关索引依然存在内存中, 查询的速度会变得很快.  刚开始查询大概用 200 毫秒, 后面会降到 20 毫秒 — 比起要花 45 秒查询的顺序扫描, 确实有明显的提高.

这种索引方式有几个弊端:

  • 数据写入的开销. 这种方式在每次 INSERT/UPDATE/DELETE 操作的时候, 需要修改这三个索引的数据.  导致像本例这样频需要繁写入数据的更新数据操作代价太高.

  • 数据查询的限制. 这种方式同时也限制了我们自定义有价值(high-value)事件类型的能力. 比方说, 我们无法在 JSON 字段上做比范围查询更复杂的查询. 具体如:通过正则表达式搜索, 或者查找路径是/signup/ 开头的页面.

  • 磁盘空间的使用. 本例中的提到的表占 6660 mb 磁盘空间, 三个索引和起来有 1026 mb, 随着时间的推移, 这些数字还会不断的暴涨.

  • 局部索引(Partial Indexes)

    我们分析用的注册事件,只占了表中全部数据的 0.03%。而全索引是对全部数据进行索引, 显然不合适。要提高查询速度, 最好的办法是用局部索引。

    以我们对注册事件的定义为过滤条件,创建一个无关列(unrelated column)索引,,通过该索引,PostgreSQL 很容易找到注册事件所在的行,查询速度自然要比在相关字段的3个全索引快的多。 尤其是对时间字段进行局部索引。具体用法如下:

    CREATE INDEX event_signups ON event (time)
    WHERE (data->>'type') = 'submit' AND (data->>'path') = '/signup/'

    这个索引的查询速度,会从刚开始的 200 毫秒, 降到 2 毫秒。只要多运行查询语句,速度自然就会加快。更重要的是,局部索引解决了前面提到的全索引的几个缺点。

  • 索引只占 96 kb 磁盘空间, 是全索引的 1026 mb 的 1/10000。

  • 只有新增的行符合注册事件的过滤条件, 才更新索引。由于符合条件的事件只有 0.03%,数据写入的性能得到很大的提高: 基本上,创建和更新这样的索引没有太大的开销。

  • 这样的局部合并(partial join) 允许我们使用 PostgreSQL 提供的各种表达式作为过滤条件。索引中用到的 WHERE 子句,跟在查询语句中的用法没什么两样, 所以我们可以写出很复杂的过滤条件。 如:正则表达式, 函数返回结果,前面提到的前缀匹配。

  • 不要索引结果是布尔值的断言

    我见过有人直接索引布尔表达式:

    (data->>'type') = 'submit' AND (data->>'path') = '/signup/'

    ,然后把时间字段放在第二项. 如:

    CREATE INDEX event_signup_time ON event
    (((data->>'type') = 'submit' AND (data->>'path') = '/signup/'), time)

    这样做的后果,比上面两种方法还要严重,因为 PostgreSQL 的查询规划器(query planner)不会将这个布尔表达式当作过滤条件。也就是说,规划器不会把它当作 WHERE 语句:

    WHERE (data->>'type') = 'submit' AND (data->>'path') = '/signup/'

    所以,我们索引的字段:

    ((data->>'type') = 'submit' AND (data->>'path') = '/signup/')

    的值始终为 true。 当我们用这个索引当作条件过滤事件的时候,不管表达式的结果是 true 还是 false,都会先把事件数据读出来,加载完后,再过滤。

    这么一来, 索引的时候会从磁盘中读取许多不必要的数据, 此外也要检查每一行数据的有效性. 拿我们例子中的数据集来说, 这样的查询第一次要 25 秒, 之后会降到 8 秒.  这样的结果比索引整个时间字段还要差一些.

    局部索引能在很大程度上, 提高那些通过断言过滤出表中一部分数据的查询的速度. 对于以流量论英雄(Judging by traffic )的 #postgresql IRC 来说, 局部索引显得有些资源利用不足. 对比全索引, 局部索引有适用范围更广的断言(greater range of predicates), 配合高选择性过滤条件(highly selective filters), 写操作和磁盘空间会变得更少. 要是你经常查询某个表中的一小部分数据, 应当优先考虑局部索引.

    是不是开始爱上 PostgreSQL 了?  要了解它的各种功能和特点, 请移步到这里 @danlovesproofs.

    想不想将强大的技术变得更易于使用? 有兴趣就给我们发邮件 jobs@heapanalytics.com.

    陳述
    本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
    MySQL:世界上最受歡迎的數據庫的簡介MySQL:世界上最受歡迎的數據庫的簡介Apr 12, 2025 am 12:18 AM

    MySQL是一種開源的關係型數據庫管理系統,主要用於快速、可靠地存儲和檢索數據。其工作原理包括客戶端請求、查詢解析、執行查詢和返回結果。使用示例包括創建表、插入和查詢數據,以及高級功能如JOIN操作。常見錯誤涉及SQL語法、數據類型和權限問題,優化建議包括使用索引、優化查詢和分錶分區。

    MySQL的重要性:數據存儲和管理MySQL的重要性:數據存儲和管理Apr 12, 2025 am 12:18 AM

    MySQL是一個開源的關係型數據庫管理系統,適用於數據存儲、管理、查詢和安全。 1.它支持多種操作系統,廣泛應用於Web應用等領域。 2.通過客戶端-服務器架構和不同存儲引擎,MySQL高效處理數據。 3.基本用法包括創建數據庫和表,插入、查詢和更新數據。 4.高級用法涉及復雜查詢和存儲過程。 5.常見錯誤可通過EXPLAIN語句調試。 6.性能優化包括合理使用索引和優化查詢語句。

    為什麼要使用mysql?利益和優勢為什麼要使用mysql?利益和優勢Apr 12, 2025 am 12:17 AM

    選擇MySQL的原因是其性能、可靠性、易用性和社區支持。 1.MySQL提供高效的數據存儲和檢索功能,支持多種數據類型和高級查詢操作。 2.採用客戶端-服務器架構和多種存儲引擎,支持事務和查詢優化。 3.易於使用,支持多種操作系統和編程語言。 4.擁有強大的社區支持,提供豐富的資源和解決方案。

    描述InnoDB鎖定機制(共享鎖,獨家鎖,意向鎖,記錄鎖,間隙鎖,下一鍵鎖)。描述InnoDB鎖定機制(共享鎖,獨家鎖,意向鎖,記錄鎖,間隙鎖,下一鍵鎖)。Apr 12, 2025 am 12:16 AM

    InnoDB的鎖機制包括共享鎖、排他鎖、意向鎖、記錄鎖、間隙鎖和下一個鍵鎖。 1.共享鎖允許事務讀取數據而不阻止其他事務讀取。 2.排他鎖阻止其他事務讀取和修改數據。 3.意向鎖優化鎖效率。 4.記錄鎖鎖定索引記錄。 5.間隙鎖鎖定索引記錄間隙。 6.下一個鍵鎖是記錄鎖和間隙鎖的組合,確保數據一致性。

    MySQL查詢性能差的常見原因是什麼?MySQL查詢性能差的常見原因是什麼?Apr 12, 2025 am 12:11 AM

    MySQL查询性能不佳的原因主要包括没有使用索引、查询优化器选择错误的执行计划、表设计不合理、数据量过大和锁竞争。1.没有索引导致查询缓慢,添加索引后可显著提升性能。2.使用EXPLAIN命令可以分析查询计划,找出优化器错误。3.重构表结构和优化JOIN条件可改善表设计问题。4.数据量大时,采用分区和分表策略。5.高并发环境下,优化事务和锁策略可减少锁竞争。

    您什麼時候應該使用複合索引與多個單列索引?您什麼時候應該使用複合索引與多個單列索引?Apr 11, 2025 am 12:06 AM

    在數據庫優化中,應根據查詢需求選擇索引策略:1.當查詢涉及多個列且條件順序固定時,使用複合索引;2.當查詢涉及多個列但條件順序不固定時,使用多個單列索引。複合索引適用於優化多列查詢,單列索引則適合單列查詢。

    如何識別和優化MySQL中的慢速查詢? (慢查詢日誌,performance_schema)如何識別和優化MySQL中的慢速查詢? (慢查詢日誌,performance_schema)Apr 10, 2025 am 09:36 AM

    要優化MySQL慢查詢,需使用slowquerylog和performance_schema:1.啟用slowquerylog並設置閾值,記錄慢查詢;2.利用performance_schema分析查詢執行細節,找出性能瓶頸並優化。

    MySQL和SQL:開發人員的基本技能MySQL和SQL:開發人員的基本技能Apr 10, 2025 am 09:30 AM

    MySQL和SQL是開發者必備技能。 1.MySQL是開源的關係型數據庫管理系統,SQL是用於管理和操作數據庫的標準語言。 2.MySQL通過高效的數據存儲和檢索功能支持多種存儲引擎,SQL通過簡單語句完成複雜數據操作。 3.使用示例包括基本查詢和高級查詢,如按條件過濾和排序。 4.常見錯誤包括語法錯誤和性能問題,可通過檢查SQL語句和使用EXPLAIN命令優化。 5.性能優化技巧包括使用索引、避免全表掃描、優化JOIN操作和提升代碼可讀性。

    See all articles

    熱AI工具

    Undresser.AI Undress

    Undresser.AI Undress

    人工智慧驅動的應用程序,用於創建逼真的裸體照片

    AI Clothes Remover

    AI Clothes Remover

    用於從照片中去除衣服的線上人工智慧工具。

    Undress AI Tool

    Undress AI Tool

    免費脫衣圖片

    Clothoff.io

    Clothoff.io

    AI脫衣器

    AI Hentai Generator

    AI Hentai Generator

    免費產生 AI 無盡。

    熱門文章

    R.E.P.O.能量晶體解釋及其做什麼(黃色晶體)
    3 週前By尊渡假赌尊渡假赌尊渡假赌
    R.E.P.O.最佳圖形設置
    3 週前By尊渡假赌尊渡假赌尊渡假赌
    R.E.P.O.如果您聽不到任何人,如何修復音頻
    3 週前By尊渡假赌尊渡假赌尊渡假赌
    WWE 2K25:如何解鎖Myrise中的所有內容
    4 週前By尊渡假赌尊渡假赌尊渡假赌

    熱工具

    禪工作室 13.0.1

    禪工作室 13.0.1

    強大的PHP整合開發環境

    WebStorm Mac版

    WebStorm Mac版

    好用的JavaScript開發工具

    MantisBT

    MantisBT

    Mantis是一個易於部署的基於Web的缺陷追蹤工具,用於幫助產品缺陷追蹤。它需要PHP、MySQL和一個Web伺服器。請查看我們的演示和託管服務。

    SublimeText3 Linux新版

    SublimeText3 Linux新版

    SublimeText3 Linux最新版

    記事本++7.3.1

    記事本++7.3.1

    好用且免費的程式碼編輯器