<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ??碼云GVP開源項目 12k star Uniapp+ElementUI 功能強大 支持多語言、二開方便! 廣告
                # VACUUM ## Name VACUUM?--?垃圾收集以及可選地分析一個數據庫 ## Synopsis ``` VACUUM [ ( { FULL | FREEZE | VERBOSE | ANALYZE } [, ...] ) ] [ _table_name_ [ (_column_name_ [, ...] ) ] ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ _table_name_ ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ _table_name_ [ (_column_name_ [, ...] ) ] ] ``` ## 描述 `VACUUM`回收死行占據的存儲空間。在一般的PostgreSQL 操作里,那些已經 DELETE 的行或者被 UPDATE 過后過時的行并沒有從它們所屬的表中物理刪除; 在完成`VACUUM`之前它們仍然存在。因此有必要周期地運行`VACUUM`, 特別是在經常更新的表上。 如果沒有參數,`VACUUM`處理當前用戶有權限vacuum的當前數據庫里的每個表, 如果有參數,`VACUUM`只處理那個表。 `VACUUM ANALYZE`先執行一個`VACUUM` 然后是給每個選定的表執行一個`ANALYZE`。對于日常維護腳本而言, 這是一個很方便的組合。參閱[ANALYZE](#calibre_link-589)獲取更多有關其處理的細節。 簡單的`VACUUM`(沒有`FULL`)只是簡單地回收空間并且令其可以再次使用。 這種形式的命令可以和對表的普通讀寫并發操作,因為沒有請求排他鎖。然而, 額外的空間并不返回到操作系統(在大多數情況下);僅保持在相同的表中可重用。 `VACUUM FULL`將表的全部內容重寫到一個沒有任何多余空間的新磁盤文件中, 允許未使用的空間返回到操作系統中。這種形式要慢許多并且在處理的時候需要在表上施加一個排它鎖。 當選項列表被括號括起來時,該選項可以任意順序來寫。沒有圓括號,選項必須按以上顯示的順序指定。 加圓括號的語法在PostgreSQL 9.0中添加;不加括號的語法已經廢棄了。 ## 參數 `FULL` 選擇"完全"清理,這樣可以恢復更多的空間,但是花的時間更多并且在表上施加了排它鎖。 該方法也需要額外的磁盤空間,因為它寫了一個表的新拷貝并且不釋放舊的拷貝,直到操作完成。 通常這應該只用于當一個大量的空間需要在這個表中回收時。 `FREEZE` 選擇激進的行"凍結"。指定`FREEZE`相當于執行 `VACUUM`時將[vacuum_freeze_min_age](#calibre_link-750)參數設為零。 `VERBOSE` 為每個表打印一份詳細的清理工作報告。 `ANALYZE` 更新用于優化器的統計信息,以決定執行查詢的最有效方法。 `_table_name_` 要清理的表的名稱(可以有模式修飾)。缺省時是當前數據庫中的所有表。 `_column_name_` 要分析的具體的字段名稱。缺省是所有字段。若指定一個字段列表,就暗含`ANALYZE`。 ## 輸出 如果指定了`VERBOSE`,那么`VACUUM`將發出處理過程中的信息, 以表明當前正在處理哪個表。各種有關這些表的統計也會打印出來。 ## 注意 要清空一個表,一個人必須通常是表的所有者或是一個超級用戶。然而, 數據庫所有者允許清空他們的數據庫中的所有表,除了共享目錄。 (對共享目錄的限制意味著一個真正的數據庫范圍的`VACUUM`僅能由超級用戶執行。) `VACUUM`將跳過調用用戶沒有權限清空的任何表。 `VACUUM`不能在事務塊內執行。 對于有GIN索引的表,`VACUUM`(以任何形式) 也完成任何掛起索引插入內容,通過移動掛起索引條目到主GIN索引結構中的相應位置。 參閱[Section 57.3.1](#calibre_link-751)獲取詳細信息。 建議生產數據庫經常清理(至少每晚一次),以保證不斷地刪除死行。尤其是在增刪了大量記錄之后, 對受影響的表執行`VACUUM ANALYZE`命令是一個很好的習慣。 這樣做將更新系統目錄為最近的更改,并且允許PostgreSQL 查詢優化器在規劃用戶查詢時有更好的選擇。 不建議日常使用`FULL`選項,但是可以在特殊情況下使用。 一個例子就是在你刪除或更新了一個表的大部分行之后, 希望從物理上縮小該表以減少磁盤空間占用并且允許更快的表掃描。`VACUUM FULL` 通常要比單純的`VACUUM`收縮更多的表尺寸。 `VACUUM`導致 I/O 流量增加,可能會導致其它活動會話的性能惡劣。因此, 有時候會建議使用基于開銷的 vacuum 延遲特性。 參閱[Section 18.4.4](#calibre_link-752)獲取細節。 PostgreSQL包含一個"autovacuum"設施, 它可以自動進行日常的 vacuum 維護。關于手動和自動清理的更多細節, 參見[Section 23.1](#calibre_link-753)。 ## 例子 下面是一個在蛻變(regression)數據庫里某個表上執行`VACUUM`的一個例子: ``` regression=# VACUUM (VERBOSE, ANALYZE) onek; INFO: vacuuming "public.onek" INFO: index "onek_unique1" now contains 1000 tuples in 14 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.18 sec. INFO: index "onek_unique2" now contains 1000 tuples in 16 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.07u sec elapsed 0.23 sec. INFO: index "onek_hundred" now contains 1000 tuples in 13 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.17 sec. INFO: index "onek_stringu1" now contains 1000 tuples in 48 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.09u sec elapsed 0.59 sec. INFO: "onek": removed 3000 tuples in 108 pages DETAIL: CPU 0.01s/0.06u sec elapsed 0.07 sec. INFO: "onek": found 3000 removable, 1000 nonremovable tuples in 143 pages DETAIL: 0 dead tuples cannot be removed yet. There were 0 unused item pointers. 0 pages are entirely empty. CPU 0.07s/0.39u sec elapsed 1.56 sec. INFO: analyzing "public.onek" INFO: "onek": 36 pages, 1000 rows sampled, 1000 estimated total rows VACUUM ``` ## 兼容性 SQL 標準里沒有`VACUUM`語句。 ## 又見 [vacuumdb](#calibre_link-754), [Section 18.4.4](#calibre_link-752), [Section 23.1.6](#calibre_link-77)
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看