ugrás a tartalomhoz

MySQL időrendi lekérdezés gyorsítása

LuMatt · 2011. Jún. 20. (H), 04.45
Sziasztok,

Miben jobb a dátumot és az időt tárolni mysql -ben. TIMESTAMP vagy INT (unix time) formátumban. Melyikkel kapok gyorsabban eredméynt vissza, ha idő szerint rendezett listát akarok egy több (10-100) millió soros adatbázisban?
Logikusnak tűnne, ha az INT gyorsabb lenne, de lehet, hogy a datetime már eleve számként kerül letárolásra?
‹ Egyedi sorrend meghatározása MySQL eredmény sorokból HTML table egymás utáni oszlopokban sorokból oszlopok ›
 ■
1

http://dev.mysql.com/doc/refm

H.Z. v2 · 2011. Jún. 20. (H), 06.54
http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

Nekem úgy tűnik, a timestamp és az általad említett "int" ugyanazt jelenti MySQL-ben.
6

Igen, timestam = Unix time

LuMatt · 2011. Jún. 20. (H), 10.14
TIMESTAMP: A four-byte integer representing seconds UTC since the epoch ('1970-01-01 00:00:00' UTC)

több mint 4 órát túrtam a doksikat, és ez az egy sor nem ütötte ki a szemem.
Köszönöm a linket. Gondolom a későbbi verzióknál is marad / mardt ez.
2

Indexek és tárolás

Poetro · 2011. Jún. 20. (H), 06.54
Ahogy a MySQL dokumentáció is írja a DATETIME is integerként van tárolva:

  • DATE: A three-byte integer packed as DD + MM×32 + YYYY×16×32
  • TIME: A three-byte integer packed as DD×24×3600 + HH×3600 + MM×60 + SS
  • DATETIME: Eight bytes:
    A four-byte integer packed as YYYY×10000 + MM×100 + DD
    A four-byte integer packed as HH×10000 + MM×100 + SS
  • TIMESTAMP: A four-byte integer representing seconds UTC since the epoch ('1970-01-01 00:00:00' UTC)
  • YEAR: A one-byte integer


Ha pedig valamilyen INDEX van a mezőn, akkor teljesen mindegy, hogy milyen formában van tárolva (csak a beszúrások alkalmával).
3

Ennél a nagyságrendnél már

H.Z. v2 · 2011. Jún. 20. (H), 07.08
Ennél a nagyságrendnél már nem teljesen mindegy akkor sem, ha index is van rajta. Dupla méretű kulcs -> feleannyi kulcsot tud egy I/O művelettel beolvasni a memóriába. Oracle(9i) alatt ez mérhető eltérést produkált. MySQL nem tudom, mit művel ilyen esetekben.
4

keresés

kulijan28 · 2011. Jún. 20. (H), 07.50
Kérdés az is, hogy keresés, vagy bulk lekérdezés... order by...
7

szűrt rendezett keresés

LuMatt · 2011. Jún. 20. (H), 10.18
select valami from TABLE where akarmi=1 order by IDO DESC. ilyesmi lekérdezések futnak.

Az akarmire es az IDO re van közös kulcs téve. mert minden esetben az akarmi -hez rendelt adatokat kell időrendben kiolvasni (az utolsó x-et)
10

Ha még nem tetted volna meg,

H.Z. v2 · 2011. Jún. 20. (H), 11.22
Ha még nem tetted volna meg, akkor érdemes lenne megnézni, hogy az explain plan mit mond a lekérdezéseidre. Ugyanis (megintcsak oracle-s tapasztalat, dehát a MySQL is az ő kezükben van) könnyen előfordulhat, hogy bizonyos méret felett ignorálja az indexeket. Így viszont előfordulhat, hogy feleslegesen lassítod a rendszeredet az indexek karbantartásával.
5

a datetime -t nem javasolom

robit · 2011. Jún. 20. (H), 09.02
Nekem olyan gondom volt, hogy egy syslog adatbázisba datetime formátum volt használva
és piszok lassú volt.
Kiderült hogy a datetime index használatakor a mysql karakter konverziót csinál
így az indexet a nem használja

Üdv Robit
8

datetime ről állunk át TIMESTAMP -re

LuMatt · 2011. Jún. 20. (H), 10.21
Eredetileg nekünk is DATETIME volt, de nagyon belassult. Ezért most átállunk TIMESTAMP -re. De ha már úgy is hozzá kell nyúlni a rendszerhez azt akartam megnézni, hogy a TIMESTAMP -nál lehet -e az UNIX TIME típusú INT -ben tárolt idő gyorsabb.

De szerencsére a doksiban benne van hogy a TIMESTAMP = UNIX TIME.

TIMESTAMP: A four-byte integer representing seconds UTC since the epoch ('1970-01-01 00:00:00' UTC)
9

köszönöm

LuMatt · 2011. Jún. 20. (H), 10.23
Köszönöm mindenkinek a segítséget és a válaszokat.