一,並行順序掃描
01,了解順序掃描
了解並行前應該先學下順序掃描,也就是全表掃描,每次檢索都是全表跑一邊,這就導致大表掃描期間就會消耗大量的CPU ,內存 磁盤I/o,這個對數據庫影響還是很大的. OLTP 事務型的數據庫一般都要避免這個掃描方式
02,創建環境
CREATE TABLE test_bigl ( ID int4, NAME CHARACTER VARYING ( 32 ), create_time timestamp without TIME ZONE DEFAULT clock_TIMESTAMP ( ) ); --創建表結構 INSERT INTO test_bigl(id,name) SELECT n,n||'test' FROM generate_series(1,50000000) n; --插入百萬級別的數據
03, 實操了解掃描與並行掃描
先來一個操作: kingledb=> EXPLAIN SELECT * FROM test_bigl WHERE name='test'; QUERY PLAN ------------------------------------------------------------------------------ Gather (cost=1000.00..619228.77 rows=1 width=24) Workers Planned: 2 -> Parallel Seq Scan on test_bigl (cost=0.00..618228.67 rows=1 width=24) Filter: ((name)::text = 'test'::text) (4 rows)
查看這個加深的 能了解到這個是順序掃描
kingledb=> EXPLAIN ANALYZE SELECT * FROM test_bigl WHERE name='test'; QUERY PLAN -------------------------------------------------------------------------------------- ---------------------------------------- Gather (cost=1000.00..619228.77 rows=1 width=24) (actual time=2957.652..2961.262 row s=0 loops=1) Workers Planned: 2 Workers Launched: 2 -> Parallel Seq Scan on test_bigl (cost=0.00..618228.67 rows=1 width=24) (actual time=2951.512..2951.512 rows=0 loops=3) Filter: ((name)::text = 'test'::text) Rows Removed by Filter: 16666667 Planning time: 0.098 ms Execution time: 2961.299 ms (8 rows)
這個能查看到執行計划中兩個增加的選項:
Workers Planned: 執行計划預估的並行進程數
Workers Launched: 查詢實際獲得的並行進程數
發現這兩個都是為2
Parallel Seq Scan on test_bigl --這個代表這這個進行了並行的循序掃描
Planning time: 0.098 ms -->這個是sql生成執行計划的時間
Execution time: 2961.299 ms -->這個是sql實際執行時間
其實到這里你就發現我這個一直開啟了並行度,現在我們關閉它
kingledb=> set max_parallel_workers_per_gather = 0; SET 0 代表關閉 其他正整數代表 開啟的並行度
我們再次執行下
kingledb=> EXPLAIN ANALYZE SELECT * FROM test_bigl WHERE name='test'; QUERY PLAN -------------------------------------------------------------------------------------- --------------------------- Seq Scan on test_bigl (cost=0.00..982812.00 rows=1 width=24) (actual time=10028.226. .10028.226 rows=0 loops=1) Filter: ((name)::text = 'test'::text) Rows Removed by Filter: 50000000 Planning time: 0.237 ms Execution time: 10028.266 ms (5 rows) --可以發現上面加深顏色的都不存在了,而且執行時間慢了5倍!!!,相當恐怖
二,並行索引掃描
01,索引掃描
也就是在表上創建索引~~~
02,操作觀察
--創建索引
kingledb=# CREATE INDEX index_test_bigl on kingle.test_bigl USING btree (id); CREATE INDEX kingledb=#
--不開啟並行度查看索引掃描 kingledb=# EXPLAIN ANALYZE SELECT count(name) FROM kingle.test_bigl WHERE id <100000 ; QUERY PLAN -------------------------------------------------------------------------------------- -------------------------------------------------------- Aggregate (cost=3684.05..3684.06 rows=1 width=8) (actual time=54.445..54.445 rows=1 loops=1) -> Index Scan using index_test_bigl on test_bigl (cost=0.56..3442.86 rows=96474 w idth=12) (actual time=0.056..35.887 rows=99999 loops=1) Index Cond: (id < 100000) Planning time: 1.212 ms Execution time: 54.614 ms (5 rows)
--開啟並行度掃描 kingledb=# EXPLAIN ANALYZE SELECT count(name) FROM kingle.test_bigl WHERE id <1000000 ; QUERY PLAN -------------------------------------------------------------------------------------- --------------------------------------------------------------------------------- Finalize Aggregate (cost=30200.04..30200.05 rows=1 width=8) (actual time=191.625..19 1.625 rows=1 loops=1) -> Gather (cost=30199.62..30200.03 rows=4 width=8) (actual time=191.585..195.111 rows=5 loops=1) Workers Planned: 4 Workers Launched: 4 -> Partial Aggregate (cost=29199.62..29199.63 rows=1 width=8) (actual time= 178.688..178.688 rows=1 loops=5) -> Parallel Index Scan using index_test_bigl on test_bigl (cost=0.56. .28564.97 rows=253860 width=12) (actual time=0.073..148.722 rows=200000 loops=5) Index Cond: (id < 1000000) Planning time: 0.204 ms Execution time: 195.215 ms (9 rows)
三,並行index-only掃描
kingledb=# EXPLAIN ANALYZE SELECT "count"(*) from kingle.test_bigl WHERE id <1000000; QUERY PLAN -------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------- Finalize Aggregate (cost=30200.04..30200.05 rows=1 width=8) (actual time=184.775..18 4.776 rows=1 loops=1) -> Gather (cost=30199.62..30200.03 rows=4 width=8) (actual time=181.043..184.904 rows=5 loops=1) Workers Planned: 4 Workers Launched: 4 -> Partial Aggregate (cost=29199.62..29199.63 rows=1 width=8) (actual time= 170.658..170.658 rows=1 loops=5) -> Parallel Index Only Scan using index_test_bigl on test_bigl (cost= 0.56..28564.97 rows=253860 width=0) (actual time=0.114..142.576 rows=200000 loops=5) Index Cond: (id < 1000000) Heap Fetches: 206058 Planning time: 0.340 ms Execution time: 185.024 ms (10 rows)
四,並行bitmap heap掃描
kingledb=# EXPLAIN ANALYZE SELECT count(*) from kingle.test_bigl WHERE id<1000000 or id >490000000 kingledb-# ; QUERY PLAN -------------------------------------------------------------------------------------- --------------------------------------------------------------------------- Finalize Aggregate (cost=382523.64..382523.65 rows=1 width=8) (actual time=209.846.. 209.847 rows=1 loops=1) -> Gather (cost=382523.22..382523.63 rows=4 width=8) (actual time=206.653..210.28 5 rows=5 loops=1) Workers Planned: 4 Workers Launched: 4 -> Partial Aggregate (cost=381523.22..381523.23 rows=1 width=8) (actual tim e=197.044..197.044 rows=1 loops=5) -> Parallel Bitmap Heap Scan on test_bigl (cost=19268.67..380888.57 r ows=253860 width=0) (actual time=85.352..170.740 rows=200000 loops=5) Recheck Cond: ((id < 1000000) OR (id > 490000000)) Heap Blocks: exact=1478 -> BitmapOr (cost=19268.67..19268.67 rows=1015441 width=0) (act ual time=91.773..91.773 rows=0 loops=1) -> Bitmap Index Scan on index_test_bigl (cost=0.00..18756 .37 rows=1015441 width=0) (actual time=91.749..91.749 rows=999999 loops=1) Index Cond: (id < 1000000) -> Bitmap Index Scan on index_test_bigl (cost=0.00..4.57 rows=1 width=0) (actual time=0.014..0.014 rows=0 loops=1) Index Cond: (id > 490000000) Planning time: 0.456 ms Execution time: 210.420 ms (15 rows) kingledb=#