- Verschifft
- 10. August 2026 um 18:14 UTC
- Autor
- Kamo
- Ausschuss
- 371b3bb
Die IP-Nachahmung ist ein Bereichsscan: WO network_start <= ? ORDER BY network_start DESC LIMIT 1 YugabyteDB teilt die LEADING Index-Spalte durch HASH, sofern nicht anders gesagt; CockroachDB-Indizes sind immer bereichsverkleidet. Also, wenn das Schema wieder aufgebaut wurde YugabyteDB, idx_geolite_blocks_range wurde (network_start HASH, network_end ASC) und nicht mehr in der Lage zu sein, dieses Prädikat überhaupt zu dienen. Gemessen: Voller Scan aller 5.820.022 Zeilen, 8.814 ms pro Anruf. Es war die Single die teuerste Sache in der Datenbank -- 3.96 HIER der kumulativen Ausführungszeit Über 455 Anrufe, plus ein zweites Geo bei 16,4 s s Durchschnitt. Es ist auch, was Erschöpfter SecurityServices Anschlusspool. Mit (network_start ASC, network_end ASC): 6,9 ms und 0 Zeilen gescannt. Die beitreten Abfrage geht über 16.421 ms - 10,2 ms. An zwei Stellen festbestehend, weil der Tisch wöchentlich umgebaut wird: - GeoLiteBlock @Index, so dass frische Schema-Builds korrekt sind. - DaemonService GeoLiteSyncService, dessen Staging+rename Swap die Indizes jeden Sonntag und würde dies anderweitig stillschweigend rückgängig machen.