การสแกนตามลำดับ PostgreSQL แทนการสแกนดัชนีทำไม


12

สวัสดีทุกคนฉันมีปัญหากับแบบสอบถามฐานข้อมูล PostgreSQL ของฉันและสงสัยว่าใครสามารถช่วยได้ ในบางสถานการณ์แบบสอบถามของฉันดูเหมือนจะไม่สนใจดัชนีที่ฉันสร้างขึ้นซึ่งจะใช้สำหรับการเข้าร่วมสองตารางและdata data_areaเมื่อสิ่งนี้เกิดขึ้นจะใช้การสแกนตามลำดับและส่งผลให้แบบสอบถามช้าลงมาก

การสแกนตามลำดับ (~ 5 นาที)

Unique  (cost=15368261.82..15369053.96 rows=200 width=1942) (actual time=301266.832..301346.936 rows=153812 loops=1)
   CTE data
     ->  Bitmap Heap Scan on data  (cost=6086.77..610089.54 rows=321976 width=297) (actual time=26.286..197.625 rows=335130 loops=1)
           Recheck Cond: (datasetid = 1)
           Filter: ((readingdatetime >= '1920-01-01 00:00:00'::timestamp without time zone) AND (readingdatetime <= '2013-03-11 00:00:00'::timestamp without time zone) AND (depth >= 0::double precision) AND (depth <= 99999::double precision))
           ->  Bitmap Index Scan on data_datasetid_index  (cost=0.00..6006.27 rows=324789 width=0) (actual time=25.462..25.462 rows=335130 loops=1)
                 Index Cond: (datasetid = 1)
   ->  Sort  (cost=15368261.82..15368657.89 rows=158427 width=1942) (actual time=301266.829..301287.110 rows=155194 loops=1)
         Sort Key: data.id
         Sort Method: quicksort  Memory: 81999kB
         ->  Hash Left Join  (cost=15174943.29..15354578.91 rows=158427 width=1942) (actual time=300068.588..301052.832 rows=155194 loops=1)
               Hash Cond: (data_area.area_id = area.id)
               ->  Hash Join  (cost=15174792.93..15351854.12 rows=158427 width=684) (actual time=300066.288..300971.644 rows=155194 loops=1)
                     Hash Cond: (data.id = data_area.data_id)
                     ->  CTE Scan on data  (cost=0.00..6439.52 rows=321976 width=676) (actual time=26.290..313.842 rows=335130 loops=1)
                     ->  Hash  (cost=14857017.62..14857017.62 rows=25422025 width=8) (actual time=300028.260..300028.260 rows=26709939 loops=1)
                           Buckets: 4194304  Batches: 1  Memory Usage: 1043357kB
                           ->  Seq Scan on data_area  (cost=0.00..14857017.62 rows=25422025 width=8) (actual time=182921.056..291687.996 rows=26709939 loops=1)
                                 Filter: (area_id = ANY ('{28,29,30,31,32,33,25,26,27,18,19,20,21,12,13,14,15,16,17,34,35,1,2,3,4,5,6,22,23,24,7,8,9,10,11}'::integer[]))
               ->  Hash  (cost=108.49..108.49 rows=3349 width=1258) (actual time=2.256..2.256 rows=3349 loops=1)
                     Buckets: 1024  Batches: 1  Memory Usage: 584kB
                     ->  Seq Scan on area  (cost=0.00..108.49 rows=3349 width=1258) (actual time=0.007..0.666 rows=3349 loops=1)
 Total runtime: 301493.379 ms

การสแกนดัชนี (ประมาณ 3 วินาที) ( บน expl.depesz.com )

Unique  (cost=17352256.47..17353067.50 rows=200 width=1942) (actual time=3603.303..3681.619 rows=153812 loops=1)
   CTE data
     ->  Bitmap Heap Scan on data  (cost=6284.60..619979.56 rows=332340 width=297) (actual time=26.201..262.314 rows=335130 loops=1)
           Recheck Cond: (datasetid = 1)
           Filter: ((readingdatetime >= '1920-01-01 00:00:00'::timestamp without time zone) AND (readingdatetime <= '2013-03-11 00:00:00'::timestamp without time zone) AND (depth >= 0::double precision) AND (depth <= 99999::double precision))
           ->  Bitmap Index Scan on data_datasetid_index  (cost=0.00..6201.51 rows=335354 width=0) (actual time=25.381..25.381 rows=335130 loops=1)
                 Index Cond: (datasetid = 1)
   ->  Sort  (cost=17352256.47..17352661.98 rows=162206 width=1942) (actual time=3603.302..3623.113 rows=155194 loops=1)
         Sort Key: data.id
         Sort Method: quicksort  Memory: 81999kB
         ->  Hash Left Join  (cost=1296.08..17338219.59 rows=162206 width=1942) (actual time=29.980..3375.921 rows=155194 loops=1)
               Hash Cond: (data_area.area_id = area.id)
               ->  Nested Loop  (cost=0.00..17334287.66 rows=162206 width=684) (actual time=26.903..3268.674 rows=155194 loops=1)
                     ->  CTE Scan on data  (cost=0.00..6646.80 rows=332340 width=676) (actual time=26.205..421.858 rows=335130 loops=1)
                     ->  Index Scan using data_area_pkey on data_area  (cost=0.00..52.13 rows=1 width=8) (actual time=0.006..0.008 rows=0 loops=335130)
                           Index Cond: (data_id = data.id)
                           Filter: (area_id = ANY ('{28,29,30,31,32,33,25,26,27,18,19,20,21,12,13,14,15,16,17,34,35,1,2,3,4,5,6,22,23,24,7,8,9,10,11}'::integer[]))
               ->  Hash  (cost=1254.22..1254.22 rows=3349 width=1258) (actual time=3.057..3.057 rows=3349 loops=1)
                     Buckets: 1024  Batches: 1  Memory Usage: 584kB
                     ->  Index Scan using area_primary_key on area  (cost=0.00..1254.22 rows=3349 width=1258) (actual time=0.012..1.429 rows=3349 loops=1)
 Total runtime: 3706.630 ms

โครงสร้างตาราง

นี่คือโครงสร้างตารางสำหรับdata_areaตาราง ฉันสามารถให้ตารางอื่น ๆ ได้ถ้าต้องการ

CREATE TABLE data_area
(
  data_id integer NOT NULL,
  area_id integer NOT NULL,
  CONSTRAINT data_area_pkey PRIMARY KEY (data_id , area_id ),
  CONSTRAINT data_area_area_id_fk FOREIGN KEY (area_id)
      REFERENCES area (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT data_area_data_id_fk FOREIGN KEY (data_id)
      REFERENCES data (id) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE CASCADE
);

QUERY

WITH data AS (
    SELECT * 
    FROM data 
    WHERE 
        datasetid IN (1) 
        AND (readingdatetime BETWEEN '1920-01-01' AND '2013-03-11') 
        AND depth BETWEEN 0 AND 99999
)
SELECT * 
FROM ( 
    SELECT DISTINCT ON (data.id) data.id, * 
    FROM 
        data, 
        data_area 
        LEFT JOIN area ON area_id = area.id 
    WHERE 
        data_id = data.id 
        AND area_id IN (28,29,30,31,32,33,25,26,27,18,19,20,21,12,13,14,15,16,17,34,35,1,2,3,4,5,6,22,23,24,7,8,9,10,11) 
) as s;

ส่งคืน153812แถว ไม่set enable_seqscan= false;ปิดการใช้งานการสแกนตามลำดับและได้รับผลดัชนี

ฉันพยายามทำANALYSEในฐานข้อมูลและเพิ่มสถิติที่รวบรวมในคอลัมน์ที่ใช้ในการสืบค้น แต่ดูเหมือนว่าจะไม่มีอะไรช่วย

ทุกคนสามารถแพร่กระจายและแสงในนี้หรือแนะนำสิ่งอื่นที่ฉันควรลอง?


มันจะช่วยฉันถ้าคุณรวมคำค้นหาที่สร้างแผนการดำเนินการแต่ละแผน
Mike Sherrill 'Cat Recall'

ความแตกต่างของคำสั่ง 2 ขนาดในจำนวนแถวโดยประมาณและจำนวนแถวจริงหรือไม่ ฉันอ่านถูกไหม
Mike Sherrill 'Cat Recall'

@Catcall ได้เพิ่มการสืบค้น (kinda basic เพื่อให้สามารถทำงานสิ่งที่เกิดขึ้น) เมื่อคุณอ้างถึงแถวโดยประมาณคือ 200 และจากนั้นจริง ๆ แล้วคืนค่า 153812
Mark Davidson

2
ใช่ 200 vs 150k ดูแปลก ๆ อย่างรวดเร็ว มีเหตุผลที่น่าสนใจในการผสมผสานซ้ายเข้าร่วมกับผลิตภัณฑ์คาร์ทีเซียน ( FROM data, data_area)? อย่างรวดเร็วก่อนการใช้ DISTINCT ON โดยไม่มีส่วนคำสั่ง ORDER BY ดูเหมือนจะเป็นความคิดที่ไม่ดี
Mike Catrill 'Cat Recall'

expl.depesz.com/s/Uzinอาจเป็นข้อมูล
Craig Ringer

คำตอบ:


8

สังเกตบรรทัดนี้:

->  Index Scan using data_area_pkey on data_area  (cost=0.00..52.13 rows=1 width=8) 
    (actual time=0.006..0.008 rows=0 loops=335130)

หากคุณคำนวณค่าใช้จ่ายทั้งหมดโดยคำนึงถึงลูปก็คือ 52.3 * 335130 = 17527299ถ้าคุณคำนวณค่าใช้จ่ายทั้งหมดพิจารณาลูปมันเป็นนี่มีขนาดใหญ่กว่า 14857017.62 สำหรับseq_scanทางเลือก นั่นคือสาเหตุที่ไม่ใช้ดัชนี

ดังนั้นเครื่องมือเพิ่มประสิทธิภาพจึงประเมินค่าใช้จ่ายในการสแกนดัชนีสูงเกินไป ฉันเดาว่าข้อมูลของคุณถูกจัดเรียงไว้ในดัชนี (เนื่องจากดัชนีคลัสเตอร์หรือวิธีการโหลด) และ / หรือคุณมีหน่วยความจำแคชและ / หรือดิสก์เร็วที่ดี ดังนั้นจึงมี I / O สุ่มเกิดขึ้นเล็กน้อย

นอกจากนี้คุณยังควรตรวจสอบcorrelationในpg_statsที่ถูกใช้โดยการเพิ่มประสิทธิภาพในการประเมินการจัดกลุ่มเมื่อคำนวณค่าใช้จ่ายดัชนีและในที่สุดก็ลองเปลี่ยนrandom_page_costและcpu_index_tuple_costเพื่อให้ตรงกับระบบของคุณ


เว้นแต่ว่าฉันขาดอะไรไปฉันคิดว่า @jop หมายถึง52.13ไม่ใช่52.3ซึ่งจะส่งผลให้ 17470326.9 (ยังคงมีขนาดใหญ่กว่า seq_scan)
BotNet

2

CTE ของคุณจริง ๆ แล้วไม่ทำอะไรนอกจาก 'outsource' WHEREเงื่อนไขบางอย่างพวกเขาส่วนใหญ่ดูเทียบเท่าWHERE TRUEเงื่อนไขที่สุดของพวกเขามองเทียบเท่าเนื่องจาก CTE มักจะอยู่หลังรั้วการปรับให้เหมาะสม (หมายความว่ามันปรับให้เหมาะสมด้วยตัวเอง) พวกเขาสามารถช่วยได้มากกับการค้นหาบางอย่าง อย่างไรก็ตามในกรณีนี้ฉันคาดว่าจะเกิดผลตรงกันข้าม

สิ่งที่ฉันจะพยายามคือการเขียนแบบสอบถามให้ง่ายที่สุดเท่าที่จะทำได้:

SELECT d.id, * 
FROM 
    data d 
    JOIN data_area da ON da.data_id = d.id
    LEFT JOIN area a ON da.area_id = a.id 
WHERE 
    d.datasetid IN (1) 
    AND da.area_id IN (28,29,30,31,32,33,25,26,27,18,19,20,21,12,13,14,15,16,17,34,35,1,2,3,4,5,6,22,23,24,7,8,9,10,11) 
    AND (readingdatetime BETWEEN '1920-01-01' AND '2013-03-11') -- this and the next condition don't do anything, I think
    AND depth BETWEEN 0 AND 99999
;

จากนั้นตรวจสอบว่ามีการใช้ดัชนีหรือไม่ ยังคงเป็นไปได้มากที่คุณไม่ต้องการคอลัมน์เอาต์พุตทั้งหมด (อย่างน้อยสองคอลัมน์ของตารางแยกจะไม่จำเป็น)

โปรดรายงานกลับมาและบอกเราว่าคุณใช้ PostgreSQL รุ่นใด


ขอบคุณสำหรับคำแนะนำของคุณขออภัยในความล่าช้าของฉันตอบกลับโพสต์ของคุณฉันได้ทำงานในโครงการอื่น ๆ คำแนะนำของคุณหมายความว่าแบบสอบถามตอนนี้ดูเหมือนว่าจะใช้ดัชนีสำหรับแบบสอบถามทั้งหมดได้อย่างน่าเชื่อถือ แต่ฉันยังไม่ได้รับประสิทธิภาพตามที่ฉันคาดหวัง ฉันได้ทำการวิเคราะห์คำค้นหาที่มีข้อมูลจำนวนมากขึ้นมาก expl.depesz.com/s/1yuใช้เวลาประมาณ 4 นาทีโดยใช้เวลา 95% ของเวลาที่ใช้ในการสแกน INDEX
Mark Davidson

ลืมพูดถึงฉันใช้รุ่น 9.1.4
Mark Davidson

โดยทั่วไปการสแกนดัชนีค่อนข้างเร็วปัญหาคือว่าซ้ำหลายล้านครั้ง คุณจะได้อะไรถ้าคุณSET enable_nestloop=offก่อนเรียกใช้แบบสอบถาม
dezso

-1

สำหรับผู้ติดตามฉันมีปัญหาคล้ายกันที่เป็นเช่นนั้น

select * from table where bigint_column between x and y and mod(bigint_column, 10000) == z

ปัญหาคือว่า bigint_column "ของฉันระหว่าง x และ y" มีดัชนี แต่โดยทั่วไปแบบสอบถามของฉันคือ "ทุกแถว" ในตารางนั้นดังนั้นจึงไม่ได้ใช้ดัชนี [เนื่องจากต้องสแกนทั้งตารางต่อไป] แต่ ทำการสแกนตามลำดับ seq_scan การแก้ไขสำหรับฉันก็คือการสร้างดัชนีใหม่สำหรับ "สมัย" ด้านข้างของสมการเพื่อที่จะสามารถใช้ในการแสดงออก


downvoters อย่าลังเลที่จะแสดงความคิดเห็นว่าทำไม :)
rogerdpack
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.