มันเป็นความคิดที่ดี / วิธีการจัดทำดัชนีคอลัมน์ VARCHAR?

เรากำลังใช้ PostgreSQL v8.2.3

มีตารางที่เกี่ยวข้อง: พนักงานและEMAILLIST

Table 1: EMPLOYEE (column1, column2, email1, email2, column5, column6)
Table 2: EMAILLIST (email)

มีการรวม 2 ตารางเข้าด้วยกันซึ่งหาก EMPLOYEE.EMAIL1 หรือ EMPLOYEE.EMAIL2 ไม่ได้เข้าคู่กันแถวเหล่านั้นจะถูกส่งกลับ

SELECT employee.email1, employee.email2,
        e1.email IS NOT NULL AS email1_matched, e2.email IS NOT NULL AS email2_matched
   FROM employee
   LEFT JOIN emaillist e1 ON e1.email = employee.email1
   LEFT JOIN emaillist e2 ON e2.email = employee.email2
 WHERE e1.email IS NULL OR e2.email IS NULL

คอลัมน์EMAILซึ่งเป็นvarchar (256)ของEMAILLISTตารางถูกทำดัชนี ตอนนี้เวลาตอบสนองคือ 14 วินาที

สถิติการนับตาราง: ปัจจุบัน EMPLOYEE มีเร็กคอร์ด 165,018 & EMAILLIST ได้ 1,810,228 บันทึกและคาดว่าทั้งสองตารางจะเติบโตในอนาคต

1. มันเป็นความคิดที่ดี / วิธีการจัดทำดัชนีคอลัมน์ VARCHAR? คำถามนี้ตอบคำถามฉันทันทีเพราะเหตุผลที่เราไม่ได้จัดทำดัชนีคอลัมน์ VARCHAR ไว้ก่อนในใบสมัครของเรา คำแนะนำจากผู้เชี่ยวชาญ / ข้อเสนอแนะเกี่ยวกับเรื่องนี้ได้รับการชื่นชมอย่างมาก
2. ด้วยการสืบค้นและดัชนีปัจจุบันเวลาตอบสนอง 14 วินาทีนั้นสมเหตุสมผลหรือมีขอบเขตสำหรับการปรับแต่งเพิ่มเติมหรือไม่ ประสบการณ์ / ความคิดเห็นแบบเรียลไทม์ของผู้ใช้รายอื่นที่มาจากขนาดของตารางและเวลาตอบสนองคืออะไร

หมายเหตุ:กรณี / ความต้องการการใช้งานจริงของฉันคือการอธิบายในรายละเอียดที่นี่

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

ไม่มีปัญหาในการสร้างดัชนีคอลัมน์ varchar เช่นนี้

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

ตารางของคุณมีขนาดค่อนข้างเล็กและประสิทธิภาพอาจเกี่ยวข้องกับข้อ OR น่าเสียดายที่ปัญหาเดียวกันนี้นำไปใช้ไม่ว่าคุณจะจัดโครงสร้างคิวรีอย่างไร (และฉันไม่คุ้นเคยกับ PostgresSQL มากพอที่จะขอโทษ)

ลองกำจัดส่วน "OR e2.email IS NULL" ของคุณและดูว่ามันทำงานเร็วแค่ไหน หากมันทำงานเร็วขึ้นคุณอาจสามารถเรียกใช้งานได้เร็วขึ้นด้วย "union all"