รูปแบบประสิทธิภาพของแบบสอบถาม PostgreSQL LIKE

ฉันเห็นการเปลี่ยนแปลงค่อนข้างมากในเวลาตอบสนองเกี่ยวกับการLIKEสืบค้นตารางใดตารางหนึ่งในฐานข้อมูลของฉัน บางครั้งฉันจะได้ผลลัพธ์ภายใน 200-400 มิลลิวินาที (ยอมรับได้มาก) แต่บางครั้งอาจใช้เวลามากถึง 30 วินาทีในการส่งคืนผลลัพธ์

ฉันเข้าใจว่าLIKEข้อความค้นหามีทรัพยากรมาก แต่ฉันไม่เข้าใจว่าทำไมเวลาตอบกลับจึงมีความแตกต่างกันมาก ฉันได้สร้างดัชนี btree บนowner1สนาม แต่ฉันไม่คิดว่ามันจะช่วยในการLIKEสืบค้น ใครมีไอเดียบ้าง

SQL ตัวอย่าง:

SELECT gid, owner1 FORM parcels
WHERE owner1 ILIKE '%someones name%' LIMIT 10

ฉันได้ลองแล้ว:

SELECT gid, owner1 FROM parcels
WHERE lower(owner1) LIKE lower('%someones name%') LIMIT 10

และ:

SELECT gid, owner1 FROM parcels
WHERE lower(owner1) LIKE lower('someones name%') LIMIT 10

ด้วยผลลัพธ์ที่คล้ายกัน.
จำนวนแถวของตาราง: ประมาณ 95,000

FTS ไม่รองรับ LIKE

ตอบรับก่อนหน้านี้ไม่ถูกต้อง การค้นหาข้อความแบบเต็มพร้อมดัชนีข้อความแบบเต็มไม่ได้มีไว้สำหรับLIKEโอเปอเรเตอร์ แต่อย่างใด แต่ก็มีตัวดำเนินการของตัวเองและใช้ไม่ได้กับสตริงที่กำหนดเอง มันทำงานโดยใช้คำตามพจนานุกรมและการสะกดคำ มันไม่สนับสนุนการจับคู่คำนำหน้าคำแต่ไม่ได้อยู่กับLIKEผู้ประกอบการ:

• จับคู่บางส่วนจากคอลัมน์ TSVECTOR ที่จัดทำดัชนี GIN

ดัชนี Trigram สำหรับ LIKE

ติดตั้งโมดูลเพิ่มเติมpg_trgmซึ่งจัดเตรียมคลาสตัวดำเนินการสำหรับดัชนีทริกเกอร์ GIN และ GiSTเพื่อรองรับรูปแบบและรูปแบบทั้งหมดLIKEILIKEไม่ใช่เฉพาะที่ยึดด้านซ้าย:

ตัวอย่างดัชนี:

CREATE INDEX tbl_col_gin_trgm_idx  ON tbl USING gin  (col gin_trgm_ops);

หรือ:

CREATE INDEX tbl_col_gist_trgm_idx ON tbl USING gist (col gist_trgm_ops);

• ความแตกต่างระหว่างดัชนี GiST และ GIN

ตัวอย่างแบบสอบถาม:

SELECT * FROM tbl WHERE col LIKE '%foo%';   -- leading wildcard
SELECT * FROM tbl WHERE col ILIKE '%foo%';  -- works case insensitively as well

Trigrams? แล้วสตริงที่สั้นกว่าล่ะ?

คำที่มีตัวอักษรน้อยกว่า 3 ตัวในค่าดัชนียังคงใช้ได้ คู่มือ:

แต่ละคำถือว่ามีช่องว่างสองช่องนำหน้าและมีช่องว่างหนึ่งช่องต่อท้ายเมื่อกำหนดชุดของตรีโกณมิติที่อยู่ในสตริง

และรูปแบบการค้นหาที่มีตัวอักษรน้อยกว่า 3 ตัว? คู่มือ:

สำหรับการค้นหาทั้งแบบLIKEและนิพจน์ทั่วไปโปรดทราบว่ารูปแบบที่ไม่มีทริกเกอร์ที่แยกได้จะลดระดับลงเป็นการสแกนแบบเต็มดัชนี

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

text_pattern_ops สำหรับการจับคู่คำนำหน้า

สำหรับรูปแบบที่ยึดด้านซ้ายเท่านั้น(ไม่มีสัญลักษณ์นำหน้า) คุณจะได้รับสิ่งที่ดีที่สุดด้วยคลาสตัวดำเนินการที่เหมาะสมสำหรับดัชนี btree: text_pattern_opsหรือvarchar_pattern_ops. ทั้งคุณสมบัติในตัวของ Postgres มาตรฐานไม่จำเป็นต้องมีโมดูลเพิ่มเติม ประสิทธิภาพใกล้เคียงกัน แต่ดัชนีเล็กกว่ามาก

ตัวอย่างดัชนี:

CREATE INDEX tbl_col_text_pattern_ops_idx ON tbl(col text_pattern_ops);

ตัวอย่างแบบสอบถาม:

SELECT * FROM tbl WHERE col LIKE 'foo%';  -- no leading wildcard

หรือถ้าคุณควรเรียกใช้ฐานข้อมูลของคุณด้วยโลแคล'C' ( ไม่มีโลแคลอย่างมีประสิทธิภาพ) ทุกอย่างจะถูกจัดเรียงตามลำดับไบต์ต่อไปและดัชนี btree ธรรมดาที่มีคลาสตัวดำเนินการเริ่มต้นจะทำงาน

รายละเอียดเพิ่มเติมคำอธิบายตัวอย่างและลิงค์ในคำตอบที่เกี่ยวข้องเหล่านี้บน dba.SE:

• รูปแบบที่ตรงกับ LIKE, SIMILAR TO หรือนิพจน์ทั่วไปใน PostgreSQL
• LIKE ใช้งานอย่างไร?
• ค้นหาสตริงที่คล้ายกันด้วย PostgreSQL อย่างรวดเร็ว

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

หากคุณต้องการค้นหาสตริงในกลางสนามที่คุณควรมีลักษณะเป็นข้อความเต็มหรือไตรแกรมดัชนี ประการแรกอยู่ในแกนของ Postgres ส่วนอื่น ๆ มีอยู่ในโมดูลการสนับสนุน

คุณสามารถติดตั้งWildspeedซึ่งเป็นดัชนีประเภทอื่นใน PostgreSQL Wildspeed ทำงานร่วมกับอักขระตัวแทน% word% ได้ไม่มีปัญหา ข้อเสียคือขนาดของดัชนีซึ่งอาจมีขนาดใหญ่มาก

โปรดดำเนินการค้นหาด้านล่างเพื่อปรับปรุงประสิทธิภาพการสืบค้น LIKE ใน postgresql สร้างดัชนีเช่นนี้สำหรับตารางที่ใหญ่ขึ้น:

CREATE INDEX <indexname> ON <tablename> USING btree (<fieldname> text_pattern_ops)

สำหรับสิ่งที่คุ้มค่าDjango ORM มักจะใช้UPPER(text)สำหรับการLIKEค้นหาทั้งหมดเพื่อให้ไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่

การเพิ่มดัชนีUPPER(column::text)ช่วยเร่งระบบของฉันอย่างมากไม่เหมือนกับสิ่งอื่นใด

เท่า% นำหน้าใช่ว่าจะไม่ใช้ดัชนี ดูบล็อกนี้สำหรับคำอธิบายที่ดี:

https://use-the-index-luke.com/sql/where-clause/searching-for-ranges/like-performance-tuning

เมื่อเร็ว ๆ นี้ฉันมีปัญหาที่คล้ายกันกับตารางที่มีข้อมูล 200000 รายการและฉันต้องทำแบบสอบถาม LIKE ซ้ำ ในกรณีของฉันสตริงที่กำลังค้นหาได้รับการแก้ไข สาขาอื่น ๆ หลากหลาย ด้วยเหตุนี้ฉันจึงสามารถเขียนใหม่ได้:

SELECT owner1 FROM parcels
WHERE lower(owner1) LIKE lower('%someones name%');

เช่น

CREATE INDEX ix_parcels ON parcels(position(lower('someones name') in lower(owner1)));

SELECT owner1 FROM parcels
WHERE position(lower('someones name') in lower(owner1)) > 0;

ฉันรู้สึกยินดีเป็นอย่างยิ่งเมื่อการสืบค้นกลับมาอย่างรวดเร็วและตรวจสอบแล้วว่าดัชนีถูกใช้กับEXPLAIN ANALYZE:

 Bitmap Heap Scan on parcels  (cost=7.66..25.59 rows=453 width=32) (actual time=0.006..0.006 rows=0 loops=1)
   Recheck Cond: ("position"(lower(owner1), 'someones name'::text) > 0)
   ->  Bitmap Index Scan on ix_parcels  (cost=0.00..7.55 rows=453 width=0) (actual time=0.004..0.004 rows=0 loops=1)
         Index Cond: ("position"(lower(owner1), 'someones name'::text) > 0)
 Planning time: 0.075 ms
 Execution time: 0.025 ms

คำค้นหาที่คุณชอบอาจไม่สามารถใช้ดัชนีที่คุณสร้างขึ้นได้เนื่องจาก:

1) เกณฑ์ LIKE ของคุณเริ่มต้นด้วยสัญลักษณ์แทน

2) คุณเคยใช้ฟังก์ชันกับเกณฑ์ LIKE ของคุณ

เมื่อคุณใช้ประโยคบนคอลัมน์ที่มีฟังก์ชันเช่น LIKE, ILIKE, upper, lower เป็นต้นจากนั้น postgres จะไม่นำดัชนีปกติของคุณมาพิจารณา มันจะทำการสแกนแบบเต็มตารางผ่านแต่ละแถวดังนั้นมันจะช้า

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

create index ix_tblname_col_upper on tblname (UPPER(col) varchar_pattern_ops);

ในทำนองเดียวกันถ้าคอลัมน์ของคุณเป็นข้อความคุณก็ทำสิ่งนี้

create index ix_tblname_col_upper on tblname (UPPER(col) text_pattern_ops);

ในทำนองเดียวกันคุณสามารถเปลี่ยนฟังก์ชันส่วนบนเป็นฟังก์ชันอื่น ๆ ที่คุณต้องการได้