it-swarm-eu.dev

Je to dobrý nápad / přístup k indexování sloupce VARCHAR?

Používáme PostgreSQL v8.2.3.

Jedná se o tabulky: [~ # ~] zaměstnanec [~ # ~] a [~ # ~] emaillista [~ # ~].

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

2 tabulky jsou spojeny tak, že pokud EMPLOYEE.EMAIL1 nebo EMPLOYEE.EMAIL2 nemají odpovídající záznam, budou tyto řádky vráceny.

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

Sloupec EMAIL, který je varchar (256) tabulky EMAILLIST je indexován. Nyní je doba odezvy 14 sekund.

Statistiky počtu tabulek: V současné době má EMPLOYEE 165 018 záznamů a EMAILLIST má 1 810 228 záznamů a očekává se, že obě tabulky v budoucnu porostou.

  1. Je to dobrý nápad/přístup k indexování sloupce VARCHAR? Tato otázka mě okamžitě napadla z důvodu, že jsme v naší aplikaci neindexovali sloupec VARCHAR. Rady a doporučení odborníků v této oblasti jsou vysoce ceněny.
  2. S tímto aktuálním dotazem a indexem je doba odezvy 14 sekund přiměřená nebo existuje prostor pro další ladění? Jaké jsou zkušenosti/názory ostatních uživatelů v reálném čase na základě této velikosti tabulky a doby odezvy?

POZNÁMKA: Můj skutečný případ požadavku/použití je podrobně vysvětlen zde .

performancepostgresqlindexquery
33
Gnanam

S indexováním varchar sloupce není nic špatného, ​​pokud na něm budete dělat dotazy. Mějte však na paměti, že existují určité limity pro některé indexy a kolik mohou indexovat v jednom poli. Příklad nelze indexovat sloupec, který může obsahovat neomezené množství textu. Měli byste však být schopni udělat index na varchar (256) bez problému. Vyzkoušejte to a analyzujte vylepšení výkonu dotazů, abyste zjistili, zda to pomůže.

26
xenoterracide

Neexistuje žádný problém indexování varchar sloupce jako takové

Problémem může být situace, kdy máte sloupec varchar jako FK v tabulce miliard řádků. Pak byste měli náhradní klíč pro PK a FK, ale na přírodní varcharový klíč byste stále potřebovali jedinečné omezení/index.

Vaše tabulky jsou poměrně malé a výkon by mohl souviset s klauzulí OR). Bohužel stejný problém platí bez ohledu na to, jak strukturujete dotaz (a nejsem dostatečně obeznámen s PostgresSQL, abych nabídl moc líto)

5
gbn

Zkuste se zbavit části dotazu „NEBO e2.email IS NULL“) a podívejte se, jak rychle to běží. Pokud to běží rychleji, bude možné jej spustit rychleji pomocí „spojení všech“ "

0
Joe Love