一、使用EXPLAIN：
十載的嘉興網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整嘉興建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)公司從事“嘉興網(wǎng)站設(shè)計(jì)”,“嘉興網(wǎng)站推廣”以來，每個客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
PostgreSQL為每個查詢都生成一個查詢規(guī)劃，因?yàn)檫x擇正確的查詢路徑對性能的影響是極為關(guān)鍵的。PostgreSQL本身已經(jīng)包含了一個規(guī)劃器用于尋找最優(yōu)規(guī)劃，我們可以通過使用EXPLAIN命令來查看規(guī)劃器為每個查詢生成的查詢規(guī)劃。
PostgreSQL中生成的查詢規(guī)劃是由1到n個規(guī)劃節(jié)點(diǎn)構(gòu)成的規(guī)劃樹，其中最底層的節(jié)點(diǎn)為表掃描節(jié)點(diǎn)，用于從數(shù)據(jù)表中返回檢索出的數(shù)據(jù)行。然而，不同
的掃描節(jié)點(diǎn)類型代表著不同的表訪問模式，如：順序掃描、索引掃描，以及位圖索引掃描等。如果查詢?nèi)匀恍枰B接、聚集、排序，或者是對原始行的其它操作，那
么就會在掃描節(jié)點(diǎn)"之上"有其它額外的節(jié)點(diǎn)。并且這些操作通常都有多種方法，因此在這些位置也有可能出現(xiàn)不同的節(jié)點(diǎn)類型。EXPLAIN將為規(guī)劃樹中的每
個節(jié)點(diǎn)都輸出一行信息，顯示基本的節(jié)點(diǎn)類型和規(guī)劃器為執(zhí)行這個規(guī)劃節(jié)點(diǎn)計(jì)算出的預(yù)計(jì)開銷值。第一行(最上層的節(jié)點(diǎn))是對該規(guī)劃的總執(zhí)行開銷的預(yù)計(jì)，這個數(shù)
值就是規(guī)劃器試圖最小化的數(shù)值。
這里有一個簡單的例子，如下：
復(fù)制代碼 代碼如下:
EXPLAIN SELECT * FROM tenk1;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)
EXPLAIN引用的數(shù)據(jù)是：
1). 預(yù)計(jì)的啟動開銷(在輸出掃描開始之前消耗的時間，比如在一個排序節(jié)點(diǎn)里做排續(xù)的時間)。
2). 預(yù)計(jì)的總開銷。
3). 預(yù)計(jì)的該規(guī)劃節(jié)點(diǎn)輸出的行數(shù)。
4). 預(yù)計(jì)的該規(guī)劃節(jié)點(diǎn)的行平均寬度(單位：字節(jié))。
這里開銷(cost)的計(jì)算單位是磁盤頁面的存取數(shù)量，如1.0將表示一次順序的磁盤頁面讀取。其中上層節(jié)點(diǎn)的開銷將包括其所有子節(jié)點(diǎn)的開銷。這里的輸出
行數(shù)(rows)并不是規(guī)劃節(jié)點(diǎn)處理/掃描的行數(shù)，通常會更少一些。一般而言，頂層的行預(yù)計(jì)數(shù)量會更接近于查詢實(shí)際返回的行數(shù)。
現(xiàn)在我們執(zhí)行下面基于系統(tǒng)表的查詢：
復(fù)制代碼 代碼如下:
SELECT relpages, reltuples FROM pg_class WHERE relname = 'tenk1';
從查詢結(jié)果中可以看出tenk1表占有358個磁盤頁面和10000條記錄，然而為了計(jì)算cost的值，我們?nèi)匀恍枰懒硗庖粋€系統(tǒng)參數(shù)值。
復(fù)制代碼 代碼如下:
postgres=# show cpu_tuple_cost;
cpu_tuple_cost
----------------
0.01
(1 row)
cost = 358(磁盤頁面數(shù)) + 10000(行數(shù)) * 0.01(cpu_tuple_cost系統(tǒng)參數(shù)值)
下面我們再來看一個帶有WHERE條件的查詢規(guī)劃。
復(fù)制代碼 代碼如下:
EXPLAIN SELECT * FROM tenk1 WHERE unique1 7000;
QUERY PLAN
------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..483.00 rows=7033 width=244)
Filter: (unique1 7000)
EXPLAIN的輸出顯示，WHERE子句被當(dāng)作一個"filter"應(yīng)用，這表示該規(guī)劃節(jié)點(diǎn)將掃描表中的每一行數(shù)據(jù)，之后再判定它們是否符合過濾的條
件，最后僅輸出通過過濾條件的行數(shù)。這里由于WHERE子句的存在，預(yù)計(jì)的輸出行數(shù)減少了。即便如此，掃描仍將訪問所有10000行數(shù)據(jù)，因此開銷并沒有
真正降低，實(shí)際上它還增加了一些因數(shù)據(jù)過濾而產(chǎn)生的額外CPU開銷。
上面的數(shù)據(jù)只是一個預(yù)計(jì)數(shù)字，即使是在每次執(zhí)行ANALYZE命令之后也會隨之改變，因?yàn)锳NALYZE生成的統(tǒng)計(jì)數(shù)據(jù)是通過從該表中隨機(jī)抽取的樣本計(jì)算的。
如果我們將上面查詢的條件設(shè)置的更為嚴(yán)格一些的話，將會得到不同的查詢規(guī)劃，如：
復(fù)制代碼 代碼如下:
EXPLAIN SELECT * FROM tenk1 WHERE unique1 100;
QUERY PLAN
------------------------------------------------------------------------------
Bitmap Heap Scan on tenk1 (cost=2.37..232.35 rows=106 width=244)
Recheck Cond: (unique1 100)
- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)
Index Cond: (unique1 100)
這里，規(guī)劃器決定使用兩步規(guī)劃，最內(nèi)層的規(guī)劃節(jié)點(diǎn)訪問一個索引，找出匹配索引條件的行的位置，然后上層規(guī)劃節(jié)點(diǎn)再從表里讀取這些行。單獨(dú)地讀取數(shù)據(jù)行比順
序地讀取它們的開銷要高很多，但是因?yàn)椴⒎窃L問該表的所有磁盤頁面，因此該方法的開銷仍然比一次順序掃描的開銷要少。這里使用兩層規(guī)劃的原因是因?yàn)樯蠈右?guī)
劃節(jié)點(diǎn)把通過索引檢索出來的行的物理位置先進(jìn)行排序，這樣可以最小化單獨(dú)讀取磁盤頁面的開銷。節(jié)點(diǎn)名稱里面提到的"位圖(bitmap)"是進(jìn)行排序的機(jī)
制。
現(xiàn)在我們還可以將WHERE的條件設(shè)置的更加嚴(yán)格，如：
復(fù)制代碼 代碼如下:
EXPLAIN SELECT * FROM tenk1 WHERE unique1 3;
QUERY PLAN
------------------------------------------------------------------------------
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..10.00 rows=2 width=244)
Index Cond: (unique1 3)
在該SQL中，表的數(shù)據(jù)行是以索引的順序來讀取的，這樣就會令讀取它們的開銷變得更大，然而事實(shí)上這里將要獲取的行數(shù)卻少得可憐，因此沒有必要在基于行的物理位置進(jìn)行排序了。
現(xiàn)在我們需要向WHERE子句增加另外一個條件，如：
復(fù)制代碼 代碼如下:
EXPLAIN SELECT * FROM tenk1 WHERE unique1 3 AND stringu1 = 'xxx';
QUERY PLAN
------------------------------------------------------------------------------
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..10.01 rows=1 width=244)
Index Cond: (unique1 3)
Filter: (stringu1 = 'xxx'::name)
新增的過濾條件stringu1 = 'xxx'只是減少了預(yù)計(jì)輸出的行數(shù)，但是并沒有減少實(shí)際開銷，因?yàn)槲覀內(nèi)匀恍枰L問相同數(shù)量的數(shù)據(jù)行。而該條件并沒有作為一個索引條件，而是被當(dāng)成對索引結(jié)果的過濾條件來看待。
如果WHERE條件里有多個字段存在索引，那么規(guī)劃器可能會使用索引的AND或OR的組合，如：
復(fù)制代碼 代碼如下:
EXPLAIN SELECT * FROM tenk1 WHERE unique1 100 AND unique2 9000;
QUERY PLAN
-------------------------------------------------------------------------------------
Bitmap Heap Scan on tenk1 (cost=11.27..49.11 rows=11 width=244)
Recheck Cond: ((unique1 100) AND (unique2 9000))
- BitmapAnd (cost=11.27..11.27 rows=11 width=0)
- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)
Index Cond: (unique1 100)
- Bitmap Index Scan on tenk1_unique2 (cost=0.00..8.65 rows=1042 width=0)
Index Cond: (unique2 9000)
這樣的結(jié)果將會導(dǎo)致訪問兩個索引，與只使用一個索引，而把另外一個條件只當(dāng)作過濾器相比，這個方法未必是更優(yōu)。
現(xiàn)在讓我們來看一下基于索引字段進(jìn)行表連接的查詢規(guī)劃，如：
復(fù)制代碼 代碼如下:
EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 100 AND t1.unique2 = t2.unique2;
QUERY PLAN
--------------------------------------------------------------------------------------
Nested Loop (cost=2.37..553.11 rows=106 width=488)
- Bitmap Heap Scan on tenk1 t1 (cost=2.37..232.35 rows=106 width=244)
Recheck Cond: (unique1 100)
- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)
Index Cond: (unique1 100)
- Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.00..3.01 rows=1 width=244)
Index Cond: ("outer".unique2 = t2.unique2)
從查詢規(guī)劃中可以看出(Nested
Loop)該查詢語句使用了嵌套循環(huán)。外層的掃描是一個位圖索引，因此其開銷與行計(jì)數(shù)和之前查詢的開銷是相同的，這是因?yàn)闂l件unique1
100發(fā)揮了作用。 這個時候t1.unique2 =
t2.unique2條件子句還沒有產(chǎn)生什么作用，因此它不會影響外層掃描的行計(jì)數(shù)。然而對于內(nèi)層掃描而言，當(dāng)前外層掃描的數(shù)據(jù)行將被插入到內(nèi)層索引掃描
中，并生成類似的條件t2.unique2 = constant。所以，內(nèi)層掃描將得到和EXPLAIN SELECT * FROM tenk2
WHERE unique2 = 42一樣的計(jì)劃和開銷。最后，以外層掃描的開銷為基礎(chǔ)設(shè)置循環(huán)節(jié)點(diǎn)的開銷，再加上每個外層行的一個迭代(這里是 106
* 3.01)，以及連接處理需要的一點(diǎn)點(diǎn)CPU時間。
如果不想使用嵌套循環(huán)的方式來規(guī)劃上面的查詢，那么我們可以通過執(zhí)行以下系統(tǒng)設(shè)置，以關(guān)閉嵌套循環(huán)，如：
復(fù)制代碼 代碼如下:
SET enable_nestloop = off;
EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 100 AND t1.unique2 = t2.unique2;
QUERY PLAN
------------------------------------------------------------------------------------------
Hash Join (cost=232.61..741.67 rows=106 width=488)
Hash Cond: ("outer".unique2 = "inner".unique2)
- Seq Scan on tenk2 t2 (cost=0.00..458.00 rows=10000 width=244)
- Hash (cost=232.35..232.35 rows=106 width=244)
- Bitmap Heap Scan on tenk1 t1 (cost=2.37..232.35 rows=106 width=244)
Recheck Cond: (unique1 100)
- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37 rows=106 width=0)
Index Cond: (unique1 100)
這個規(guī)劃仍然試圖用同樣的索引掃描從tenk1里面取出符合要求的100行，并把它們存儲在內(nèi)存中的散列(哈希)表里，然后對tenk2做一次全表順序掃
描，并為每一條tenk2中的記錄查詢散列(哈希)表，尋找可能匹配t1.unique2 =
t2.unique2的行。讀取tenk1和建立散列表是此散列聯(lián)接的全部啟動開銷，因?yàn)槲覀冊陂_始讀取tenk2之前不可能獲得任何輸出行。
此外，我們還可以用EXPLAIN ANALYZE命令檢查規(guī)劃器預(yù)估值的準(zhǔn)確性。這個命令將先執(zhí)行該查詢，然后顯示每個規(guī)劃節(jié)點(diǎn)內(nèi)實(shí)際運(yùn)行時間，以及單純EXPLAIN命令顯示的預(yù)計(jì)開銷，如：
復(fù)制代碼 代碼如下:
EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 100 AND t1.unique2 = t2.unique2;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
Nested Loop (cost=2.37..553.11 rows=106 width=488) (actual time=1.392..12.700 rows=100 loops=1)
- Bitmap Heap Scan on tenk1 t1 (cost=2.37..232.35 rows=106 width=244) (actual time=0.878..2.367 rows=100 loops=1)
Recheck Cond: (unique1 100)
- Bitmap Index Scan on tenk1_unique1 (cost=0.00..2.37
rows=106 width=0) (actual time=0.546..0.546 rows=100 loops=1)
Index Cond: (unique1 100)
- Index Scan using tenk2_unique2 on tenk2 t2
(cost=0.00..3.01 rows=1 width=244) (actual time=0.067..0.078 rows=1
loops=100)
Index Cond: ("outer".unique2 = t2.unique2)
Total runtime: 14.452 ms
注意"actual time"數(shù)值是以真實(shí)時間的毫秒來計(jì)算的，而"cost"預(yù)估值是以磁盤頁面讀取數(shù)量來計(jì)算的，所以它們很可能是不一致的。然而我們需要關(guān)注的只是兩組數(shù)據(jù)的比值是否一致。
在一些查詢規(guī)劃里，一個子規(guī)劃節(jié)點(diǎn)很可能會運(yùn)行多次，如之前的嵌套循環(huán)規(guī)劃，內(nèi)層的索引掃描會為每個外層行執(zhí)行一次。在這種情況下，"loops"將報(bào)告
該節(jié)點(diǎn)執(zhí)行的總次數(shù)，而顯示的實(shí)際時間和行數(shù)目則是每次執(zhí)行的平均值。這么做的原因是令這些真實(shí)數(shù)值與開銷預(yù)計(jì)顯示的數(shù)值更具可比性。如果想獲得該節(jié)點(diǎn)所
花費(fèi)的時間總數(shù)，計(jì)算方式是用該值乘以"loops"值。
EXPLAIN ANALYZE顯示的"Total runtime"包括執(zhí)行器啟動和關(guān)閉的時間，以及結(jié)果行處理的時間，但是它并不包括分析、重寫或者規(guī)劃的時間。
如果EXPLAIN命令僅能用于測試環(huán)境，而不能用于真實(shí)環(huán)境，那它就什么用都沒有。比如，在一個數(shù)據(jù)較少的表上執(zhí)行EXPLAIN，它不能適用于數(shù)量很
多的大表，因?yàn)橐?guī)劃器的開銷計(jì)算不是線性的，因此它很可能對大些或者小些的表選擇不同的規(guī)劃。一個極端的例子是一個只占據(jù)一個磁盤頁面的表，在這樣的表
上，不管它有沒有索引可以使用，你幾乎都總是得到順序掃描規(guī)劃。規(guī)劃器知道不管在任何情況下它都要進(jìn)行一個磁盤頁面的讀取，所以再增加幾個磁盤頁面讀取用
以查找索引是毫無意義的。
二、批量數(shù)據(jù)插入：
有以下幾種方法用于優(yōu)化數(shù)據(jù)的批量插入。
1. 關(guān)閉自動提交：
在批量插入數(shù)據(jù)時，如果每條數(shù)據(jù)都被自動提交，當(dāng)中途出現(xiàn)系統(tǒng)故障時，不僅不能保障本次批量插入的數(shù)據(jù)一致性，而且由于有多次提交操作的發(fā)生，整個插入效
率也會受到很大的打擊。解決方法是，關(guān)閉系統(tǒng)的自動提交，并且在插入開始之前，顯示的執(zhí)行begin
transaction命令，在全部插入操作完成之后再執(zhí)行commit命令提交所有的插入操作。
2. 使用COPY：
使用COPY在一條命令里裝載所有記錄，而不是一系列的INSERT命令。COPY命令是為裝載數(shù)量巨大的數(shù)據(jù)行優(yōu)化過的，它不像INSERT命令那樣靈
活，但是在裝載大量數(shù)據(jù)時，系統(tǒng)開銷也要少很多。因?yàn)镃OPY是單條命令，因此在填充表的時就沒有必要關(guān)閉自動提交了。
3. 刪除索引：
如果你正在裝載一個新創(chuàng)建的表，最快的方法是創(chuàng)建表，用COPY批量裝載，然后創(chuàng)建表需要的任何索引。因?yàn)樵谝汛嬖跀?shù)據(jù)的表上創(chuàng)建索引比維護(hù)逐行增加要快。當(dāng)然在缺少索引期間，其它有關(guān)該表的查詢操作的性能將會受到一定的影響，唯一性約束也有可能遭到破壞。
4. 刪除外鍵約束：
和索引一樣，"批量地"檢查外鍵約束比一行行檢查更加高效。因此，我們可以先刪除外鍵約束，裝載數(shù)據(jù)，然后在重建約束。
5. 增大maintenance_work_mem：
在裝載大量數(shù)據(jù)時，臨時增大maintenance_work_mem系統(tǒng)變量的值可以改進(jìn)性能。這個系統(tǒng)參數(shù)可以提高CREATE
INDEX命令和ALTER TABLE ADD FOREIGN KEY命令的執(zhí)行效率，但是它不會對COPY操作本身產(chǎn)生多大的影響。
6. 增大checkpoint_segments：
臨時增大checkpoint_segments系統(tǒng)變量的值也可以提高大量數(shù)據(jù)裝載的效率。這是因?yàn)樵谙騊ostgreSQL裝載大量數(shù)據(jù)時，將會導(dǎo)致
檢查點(diǎn)操作(由系統(tǒng)變量checkpoint_timeout聲明)比平時更加頻繁的發(fā)生。在每次檢查點(diǎn)發(fā)生時，所有的臟數(shù)據(jù)都必須flush到磁盤上。
通過提高checkpoint_segments變量的值，可以有效的減少檢查點(diǎn)的數(shù)目。
7. 事后運(yùn)行ANALYZE：
在增加或者更新了大量數(shù)據(jù)之后，應(yīng)該立即運(yùn)行ANALYZE命令，這樣可以保證規(guī)劃器得到基于該表的最新數(shù)據(jù)統(tǒng)計(jì)。換句話說，如果沒有統(tǒng)計(jì)數(shù)據(jù)或者統(tǒng)計(jì)數(shù)據(jù)太過陳舊，那么規(guī)劃器很可能會選擇一個較差的查詢規(guī)劃，從而導(dǎo)致查詢效率過于低下。
一、索引的類型：
PostgreSQL提供了多種索引類型：B-Tree、Hash、GiST和GIN，由于它們使用了不同的算法，因此每種索引類型都有其適合的查詢類型，缺省時，CREATE INDEX命令將創(chuàng)建B-Tree索引。
1. B-Tree:
CREATE TABLE test1 (
id integer,
content varchar
);
CREATE INDEX test1_id_index ON test1 (id);
B-Tree索引主要用于等于和范圍查詢，特別是當(dāng)索引列包含操作符" 、=和"作為查詢條件時，PostgreSQL的查詢規(guī)劃器都會考慮使用B-Tree索引。在使用BETWEEN、IN、IS NULL和IS NOT NULL的查詢中，PostgreSQL也可以使用B-Tree索引。然而對于基于模式匹配操作符的查詢，如LIKE、ILIKE、~和 ~*，僅當(dāng)模式存在一個常量，且該常量位于模式字符串的開頭時，如col LIKE 'foo%'或col ~ '^foo'，索引才會生效，否則將會執(zhí)行全表掃描，如：col LIKE '%bar'。
2. Hash：
CREATE INDEX name ON table USING hash (column);
散列(Hash)索引只能處理簡單的等于比較。當(dāng)索引列使用等于操作符進(jìn)行比較時，查詢規(guī)劃器會考慮使用散列索引。
這里需要額外說明的是，PostgreSQL散列索引的性能不比B-Tree索引強(qiáng)，但是散列索引的尺寸和構(gòu)造時間則更差。另外，由于散列索引操作目前沒有記錄WAL日志，因此一旦發(fā)生了數(shù)據(jù)庫崩潰，我們將不得不用REINDEX重建散列索引。
3. GiST：
GiST索引不是一種單獨(dú)的索引類型，而是一種架構(gòu)，可以在該架構(gòu)上實(shí)現(xiàn)很多不同的索引策略。從而可以使GiST索引根據(jù)不同的索引策略，而使用特定的操作符類型。
4. GIN：
GIN索引是反轉(zhuǎn)索引，它可以處理包含多個鍵的值(比如數(shù)組)。與GiST類似，GIN同樣支持用戶定義的索引策略，從而可以使GIN索引根據(jù)不同的索引策略，而使用特定的操作符類型。作為示例，PostgreSQL的標(biāo)準(zhǔn)發(fā)布中包含了用于一維數(shù)組的GIN操作符類型，如：、=、等。
二、復(fù)合索引：
PostgreSQL中的索引可以定義在數(shù)據(jù)表的多個字段上，如：
CREATE TABLE test2 (
major int,
minor int,
name varchar
}
CREATE INDEX test2_mm_idx ON test2 (major, minor);
1. B-Tree類型的復(fù)合索引：
在B-Tree類型的復(fù)合索引中，該索引字段的任意子集均可用于查詢條件，不過，只有當(dāng)復(fù)合索引中的第一個索引字段(最左邊)被包含其中時，才可以獲得最高效率。
2. GiST類型的復(fù)合索引：
在GiST類型的復(fù)合索引中，只有當(dāng)?shù)谝粋€索引字段被包含在查詢條件中時，才能決定該查詢會掃描多少索引數(shù)據(jù)，而其他索引字段上的條件只是會限制索引返回的條目。假如第一個索引字段上的大多數(shù)數(shù)據(jù)都有相同的鍵值，那么此時應(yīng)用GiST索引就會比較低效。
3. GIN類型的復(fù)合索引：
與B-Tree和GiST索引不同的是，GIN復(fù)合索引不會受到查詢條件中使用了哪些索引字段子集的影響，無論是哪種組合，都會得到相同的效率。
使用復(fù)合索引應(yīng)該謹(jǐn)慎。在大多數(shù)情況下，單一字段上的索引就已經(jīng)足夠了，并且還節(jié)約時間和空間。除非表的使用模式非常固定，否則超過三個字段的索引幾乎沒什么用處。
三、組合多個索引：
PostgreSQL可以在查詢時組合多個索引(包括同一索引的多次使用)，來處理單個索引掃描不能實(shí)現(xiàn)的場合。與此同時，系統(tǒng)還可以在多個索引掃描之間組成AND和OR的條件。比如，一個類似WHERE x = 42 OR x = 47 OR x = 53 OR x = 99的查詢，可以被分解成四個獨(dú)立的基于x字段索引的掃描，每個掃描使用一個查詢子句，之后再將這些掃描結(jié)果OR在一起并生成最終的結(jié)果。另外一個例子是，如果我們在x和y上分別存在獨(dú)立的索引，那么一個類似WHERE x = 5 AND y = 6的查詢，就會分別基于這兩個字段的索引進(jìn)行掃描，之后再將各自掃描的結(jié)果進(jìn)行AND操作并生成最終的結(jié)果行。
為了組合多個索引，系統(tǒng)掃描每個需要的索引，然后在內(nèi)存里組織一個BITMAP，它將給出索引掃描出的數(shù)據(jù)在數(shù)據(jù)表中的物理位置。然后，再根據(jù)查詢的需要，把這些位圖進(jìn)行AND或者OR的操作并得出最終的BITMAP。最后，檢索數(shù)據(jù)表并返回?cái)?shù)據(jù)行。表的數(shù)據(jù)行是按照物理順序進(jìn)行訪問的，因?yàn)檫@是位圖的布局，這就意味著任何原來的索引的排序都將消失。如果查詢中有ORDER BY子句，那么還將會有一個額外的排序步驟。因?yàn)檫@個原因，以及每個額外的索引掃描都會增加額外的時間，這樣規(guī)劃器有時候就會選擇使用簡單的索引掃描，即使有多個索引可用也會如此。
四、唯一索引：
CREATE UNIQUE INDEX name ON table (column [, ...]);
五、表達(dá)式索引：
表達(dá)式索引主要用于在查詢條件中存在基于某個字段的函數(shù)或表達(dá)式的結(jié)果與其他值進(jìn)行比較的情況，如：
SELECT * FROM test1 WHERE lower(col1) = 'value';
此時，如果我們僅僅是在col1字段上建立索引，那么該查詢在執(zhí)行時一定不會使用該索引，而是直接進(jìn)行全表掃描。如果該表的數(shù)據(jù)量較大，那么執(zhí)行該查詢也將會需要很長時間。解決該問題的辦法非常簡單，在test1表上建立基于col1字段的表達(dá)式索引，如：
CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
SELECT * FROM people WHERE (first_name || ' ' || last_name) = 'John Smith';
和上面的例子一樣，盡管我們可能會為first_name和last_name分別創(chuàng)建獨(dú)立索引，或者是基于這兩個字段的復(fù)合索引，在執(zhí)行該查詢語句時，這些索引均不會被使用，該查詢能夠使用的索引只有我們下面創(chuàng)建的表達(dá)式索引。
CREATE INDEX people_names ON people ((first_name || ' ' || last_name));
CREATE INDEX命令的語法通常要求在索引表達(dá)式周圍書寫圓括弧，就像我們在第二個例子里顯示的那樣。如果表達(dá)式只是一個函數(shù)調(diào)用，那么可以省略，就像我們在第一個例子里顯示的那樣。
從索引維護(hù)的角度來看，索引表達(dá)式要相對低效一些，因?yàn)樵诓迦霐?shù)據(jù)或者更新數(shù)據(jù)的時候，都必須為該行計(jì)算表達(dá)式的結(jié)果，并將該結(jié)果直接存儲到索引里。然而在查詢時，PostgreSQL就會把它們看做WHERE idxcol = 'constant'，因此搜索的速度等效于基于簡單索引的查詢。通常而言，我們只是應(yīng)該在檢索速度比插入和更新速度更重要的場景下使用表達(dá)式索引。
六、部分索引：
部分索引(partial index)是建立在一個表的子集上的索引，而該子集是由一個條件表達(dá)式定義的(叫做部分索引的謂詞)。該索引只包含表中那些滿足這個謂詞的行。
由于不是在所有的情況下都需要更新索引，因此部分索引會提高數(shù)據(jù)插入和數(shù)據(jù)更新的效率。然而又因?yàn)椴糠炙饕绕胀ㄋ饕。虼丝梢愿玫奶岣叽_實(shí)需要索引部分的查詢效率。見以下三個示例：
1. 索引字段和謂詞條件字段一致：
CREATE INDEX access_log_client_ip_ix ON access_log(client_ip)
WHERE NOT (client_ip inet '192.168.100.0' AND client_ip inet '192.168.100.255');
下面的查詢將會用到該部分索引：
SELECT * FROM access_log WHERE url = '/index.html' AND client_ip = inet '212.78.10.32';
下面的查詢將不會用該部分索引：
一個不能使用這個索引的查詢可以是
SELECT * FROM access_log WHERE client_ip = inet '192.168.100.23';
2. 索引字段和謂詞條件字段不一致：
PostgreSQL支持帶任意謂詞的部分索引，唯一的約束是謂詞的字段也要來自于同樣的數(shù)據(jù)表。注意，如果你希望你的查詢語句能夠用到部分索引，那么就要求該查詢語句的條件部分必須和部分索引的謂詞完全匹配。 準(zhǔn)確說，只有在PostgreSQL能夠識別出該查詢的WHERE條件在數(shù)學(xué)上涵蓋了該索引的謂詞時，這個部分索引才能被用于該查詢。
CREATE INDEX orders_unbilled_index ON orders(order_nr) WHERE billed is not true;
下面的查詢一定會用到該部分索引：
SELECT * FROM orders WHERE billed is not true AND order_nr 10000;
那么對于如下查詢呢？
SELECT * FROM orders WHERE billed is not true AND amount 5000.00;
這個查詢將不像上面那個查詢這么高效，畢竟查詢的條件語句中沒有用到索引字段，然而查詢條件"billed is not true"卻和部分索引的謂詞完全匹配，因此PostgreSQL將掃描整個索引。這樣只有在索引數(shù)據(jù)相對較少的情況下，該查詢才能更有效一些。
下面的查詢將不會用到部分索引。
SELECT * FROM orders WHERE order_nr = 3501;
3. 數(shù)據(jù)表子集的唯一性約束：
CREATE TABLE tests (
subject text,
target text,
success boolean,
...
);
CREATE UNIQUE INDEX tests_success_constraint ON tests(subject, target) WHERE success;
該部分索引將只會對success字段值為true的數(shù)據(jù)進(jìn)行唯一性約束。在實(shí)際的應(yīng)用中，如果成功的數(shù)據(jù)較少，而不成功的數(shù)據(jù)較多時，該實(shí)現(xiàn)方法將會非常高效。
七、檢查索引的使用：
見以下四條建議：
1. 總是先運(yùn)行ANALYZE。
該命令將會收集表中數(shù)值分布狀況的統(tǒng)計(jì)。在估算一個查詢返回的行數(shù)時需要這個信息，而規(guī)劃器則需要這個行數(shù)以便給每個可能的查詢規(guī)劃賦予真實(shí)的開銷值。如果缺乏任何真實(shí)的統(tǒng)計(jì)信息，那么就會使用一些缺省數(shù)值，這樣肯定是不準(zhǔn)確的。因此，如果還沒有運(yùn)行ANALYZE就檢查一個索引的使用狀況，那將會是一次失敗的檢查。
2. 使用真實(shí)的數(shù)據(jù)做實(shí)驗(yàn)。
用測試數(shù)據(jù)填充數(shù)據(jù)表，那么該表的索引將只會基于測試數(shù)據(jù)來評估該如何使用索引，而不是對所有的數(shù)據(jù)都如此使用。比如從100000行中選1000行，規(guī)劃器可能會考慮使用索引，那么如果從100行中選1行就很難說也會使用索引了。因?yàn)?00行的數(shù)據(jù)很可能是存儲在一個磁盤頁面中，然而沒有任何查詢規(guī)劃能比通過順序訪問一個磁盤頁面更加高效了。與此同時，在模擬測試數(shù)據(jù)時也要注意，如果這些數(shù)據(jù)是非常相似的數(shù)據(jù)、完全隨機(jī)的數(shù)據(jù)，或按照排序順序插入的數(shù)據(jù)，都會令統(tǒng)計(jì)信息偏離實(shí)際數(shù)據(jù)應(yīng)該具有的特征。
3. 如果索引沒有得到使用，那么在測試中強(qiáng)制它的使用也許會有些價值。有一些運(yùn)行時參數(shù)可以關(guān)閉各種各樣的查詢規(guī)劃。
4. 強(qiáng)制使用索引用法將會導(dǎo)致兩種可能：一是系統(tǒng)選擇是正確的，使用索引實(shí)際上并不合適，二是查詢計(jì)劃的開銷計(jì)算并不能反映現(xiàn)實(shí)情況。這樣你就應(yīng)該對使用和不使用索引的查詢進(jìn)行計(jì)時，這個時候EXPLAIN ANALYZE命令就很有用了。
方案一：
如果 base64 轉(zhuǎn)換前的大小, 小于 備注字段 上限的話.
那么還是可以直接插入的.
因?yàn)槲谋局械摹芏? 可以通過 兩個 ' 也就是 '' 來轉(zhuǎn)義，使之成功的通過 SQL 語句，插入到表中。
方案二：
如果 base64 轉(zhuǎn)換前的大小， 就大于 備注字段的上限了，那么嘗試使用下面數(shù)據(jù)類型的一種：
OLE 對象
Microsoft Access 表中鏈接 （OLE/DDE 鏈接：OLE 對象及其 OLE 服務(wù)器之間，或動態(tài)數(shù)據(jù)交換 (DDE) 的源文檔與目標(biāo)文檔之間的一種連接。）或嵌入 （嵌入：用于插入來自其他應(yīng)用程序的 OLE 對象的副本。源對象稱為 OLE 服務(wù)器端，可以是任意支持鏈接和嵌入對象的應(yīng)用程序。對嵌入式對象的更改不會反映在原對象中。）的對象（例如 Microsoft Excel 電子表格、Microsoft Word 文檔、圖形、聲音或其他二進(jìn)制數(shù)據(jù)）。 最多為 1 G 字節(jié)（受可用磁盤空間限制）。
超鏈接
文本或文本和以文本形式存儲的數(shù)字的組合，用作超鏈接地址 （超鏈接地址：指向諸如對象、文檔或網(wǎng)頁等目標(biāo)的路徑。超鏈接地址可以是 URL（Internet 或 Intranet 網(wǎng)站的地址），也可以是 UNC 網(wǎng)絡(luò)路徑（局域網(wǎng)上的文件的地址）。）。超鏈接地址最多包含三部分：
顯示的文本：在字段或控件中顯示的文本。
地址：指向文件（UNC 路徑 （通用命名約定 (UNC)：一種對文件的命名約定，它提供了獨(dú)立于機(jī)器的文件定位方式。UNC 名稱使用 \\server\share\path\filename 這一語法格式，而不是指定驅(qū)動器符和路徑。））或頁（URL （統(tǒng)一資源定位符 (URL)：一種地址，指定協(xié)議（如 HTTP 或 FTP）以及對象、文檔、萬維網(wǎng)網(wǎng)頁或其他目標(biāo)在 Internet 或 Intranet 上的位置，例如：。））的路徑。
子地址：位于文件或頁中的地址。
屏幕提示：作為工具提示顯示的文本。
超鏈接 （“超鏈接”數(shù)據(jù)類型：存儲超鏈接地址的 Access 數(shù)據(jù)庫字段的數(shù)據(jù)類型。地址最多可以包含四部分，用以下語法格式編寫：displaytext#address#subaddress#。）數(shù)據(jù)類型三個部分中的每一部分最多只能包含 2048 個字符。
附件 任何支持的文件類型 可以將圖像、電子表格文件、文檔、圖表和其他類型的支持文件附加到數(shù)據(jù)庫的記錄，這與將文件附加到電子郵件非常類似。還可以查看和編輯附加的文件，具體取決于數(shù)據(jù)庫設(shè)計(jì)者對附件字段的設(shè)置方式?！案郊弊侄魏汀癘LE 對象”字段相比，有著更大的靈活性，而且可以更高效地使用存儲空間，這是因?yàn)椤案郊弊侄尾挥脛?chuàng)建原始文件的位圖圖像。
sysbench原來自帶的lua數(shù)據(jù)裝載腳本是使用以下方式串行裝載的，速度比較慢(比單條insert快，但是比COPY慢)。insertintotable1values(),(),().insertintotable2values(),(),().insertintotablenvalues(),(),().使用prepare導(dǎo)入數(shù)據(jù)的用法舉例./sy.
一、使用EXPLAIN： PostgreSQL為每個查詢都生成一個查詢規(guī)劃，因?yàn)檫x擇正確的查詢路徑對性能的影響是極為關(guān)鍵的。PostgreSQL本身已經(jīng)包含了一個規(guī)劃器用于尋找最優(yōu)規(guī)劃，我們可以通過使用EXPLAIN命令來查看規(guī)劃器為每個查詢生成的查詢規(guī)劃。 Pos
psc格式文件是Adobe Photoshop簡稱“PS”軟件的源文件，要打開psc文件必須要用PS軟件才能打開。
Photoshop主要處理以像素所構(gòu)成的數(shù)字圖像。使用其眾多的編修與繪圖工具，可以有效地進(jìn)行圖片編輯工作。ps有很多功能，在圖像、圖形、文字、視頻、出版等各方面都有涉及。
2003年，Adobe Photoshop 8被更名為Adobe Photoshop CS。2013年7月，Adobe公司推出了新版本的Photoshop CC，自此，Photoshop CS6作為Adobe CS系列的最后一個版本被新的CC系列取代。
截止2019年1月Adobe Photoshop CC 2019為市場最新版本。
擴(kuò)展資料：
功能
專業(yè)測評：Photoshop的專長在于圖像處理，而不是圖形創(chuàng)作。圖像處理是對已有的位圖圖像進(jìn)行編輯加工處理以及運(yùn)用一些特殊效果，其重點(diǎn)在于對圖像的處理加工；圖形創(chuàng)作軟件是按照自己的構(gòu)思創(chuàng)意，使用矢量圖形等來設(shè)計(jì)圖形。?
平面設(shè)計(jì)：平面設(shè)計(jì)是Photoshop應(yīng)用最為廣泛的領(lǐng)域，無論是圖書封面，還是招帖、海報(bào)，這些平面印刷品通常都需要Photoshop軟件對圖像進(jìn)行處理。?
廣告攝影：廣告攝影作為一種對視覺要求非常嚴(yán)格的工作，其最終成品往往要經(jīng)過Photoshop的修改才能得到滿意的效果。?
影像創(chuàng)意：影像創(chuàng)意是Photoshop的特長，通過Photoshop的處理 可以將不同的對象組合在一起，使圖像發(fā)生變化。?
網(wǎng)頁制作：網(wǎng)絡(luò)的普及是促使更多人需要掌握Photoshop，因?yàn)樵谥谱骶W(wǎng)頁時Photoshop是必不可少的網(wǎng)頁圖像處理軟件。?
后期修飾：在制作建筑效果圖包括許三維場景時，人物與配景包括場景的顏色常常需要在Photoshop中增加并調(diào)整。?
視覺創(chuàng)意：視覺創(chuàng)意與設(shè)計(jì)是設(shè)計(jì)藝術(shù)的一個分支，此類設(shè)計(jì)通常沒有非常明顯的商業(yè)目的，但由于他為廣大設(shè)計(jì)愛好者提供了廣闊的設(shè)計(jì)空間，因此越來越多的設(shè)計(jì)愛好者開始學(xué)習(xí)Photoshop，并進(jìn)行具有個人特色與風(fēng)格的視覺創(chuàng)意。?
界面設(shè)計(jì)：界面設(shè)計(jì)是一個新興的領(lǐng)域，受到越來越多的軟件企業(yè)及開發(fā)者的重視。在當(dāng)前還沒有用于做界面設(shè)計(jì)的專業(yè)軟件，因此絕大多數(shù)設(shè)計(jì)者使用的都是該軟件。?
參考資料來源：百度百科-Adobe Photoshop
重慶分公司
重慶分公司
