Mam taką tabelę sesji:

[SQL] pobierz, plaintext 
"CREATE TABLE session (
                    `id` VARCHAR(64) NOT NULL, PRIMARY KEY(`id`),
                    `last_modification` DATETIME, INDEX (`last_modification`),
                    `data` TEXT
                ) ENGINE=InnoDB CHARACTER SET `utf8`;"
[SQL] pobierz, plaintext 

Chciałbym prosić o komentarze:

• czy dobrze jeśli id jest jednoczesnie kluczem sesji a typ pola id to VARCHAR? Ponoć CHAR jest szybsze. To prawda?
• czy index na polu last_modification coś mi da?
• pole data trzymać będzie zserializowane dane sesji. Czy dobrze dać pole typu text? Moze są jakieś szybsze typy?
• W jednej konfiguracji mySQL'a widziałem opcję ustawienia tabeli na MEMORY. Dokładnie nie pamiętam ale chyba to oznaczało, że tabela będzie przechowywana w RAM-ie. Czy to prawda? Mogę ustawić tylko tą tabelę żeby działała szybciej?
• Mam też inne tabele które są stosunkowo małe a wymagają częstego odczytu (zapisu tylko raz na jakiś czas np. settingsy). Dane w nich są jednak ważniejsze. Czy można zrobić tak aby tabela siedziała w ramie i była szybko odczytywana a update oznaczałby zapis na dysku ?

Zmiana pola na CHAR przy równoczesnym użyciu innego pola tekstowego o zmiennej długości nie przyniesie oczekiwanego rezultatu (w Twoim przypadku pole `data`).


Tak. Indeksy powinno się zakładać na pola, po których będzie odbywało się wyszukiwanie lub sortowanie. Dodatkowo różnorodność danych w takich polach powinna być wysoka (w książce "MS SQL Server 2005. Programowanie" zostało to określone na poziomie 90%). Czyli nie ma sensu ustawiać indeksu na polu typu boolean bo nic się nie zyska, a wręcz straci (duplikacja danych). W Twoim przypadku indeks powinien być przydatny.


Ja bym sugerował olać serializację i skorzystać raczej z formatu JSON (json_encode" title="Zobacz w manualu PHP" target="_manual + json_decode" title="Zobacz w manualu PHP" target="_manual) aczkolwiek nie wiem jak się ma pod względem wydajności. Zaoszczędzisz sporo miejsca. Typ pola wydaje się jedynym sensownym.

Na resztę pytań wolę się nie wypowiadać aby nie napisać głupot.

PS: Na dzień dobry zmień InnoDB na MyISAM, które jest szybsze. Może potem zmienisz na Memory ale na razie olej dobrodziejstwa jakie daje InnoDB, z których i tak nie korzystasz.

[*] czy dobrze jeśli id jest jednoczesnie kluczem sesji a typ pola id to VARCHAR? Ponoć CHAR jest szybsze. To prawda?
najlepiej jakbys uzywal INT-a - najmniejszy rozmiar indeksu czyli najszybsze wyszukiwanie

[*] czy index na polu last_modification coś mi da?
to zalezy, jesli uzywac tego pola przy wyszukiwaniu to oczywiscie, w przeciwnym wypadku tylko zaszkodzi

[*] pole data trzymać będzie zserializowane dane sesji. Czy dobrze dać pole typu text? Moze są jakieś szybsze typy?
nie wiem

[*] W jednej konfiguracji mySQL'a widziałem opcję ustawienia tabeli na MEMORY. Dokładnie nie pamiętam ale chyba to oznaczało, że tabela będzie przechowywana w RAM-ie. Czy to prawda? Mogę ustawić tylko tą tabelę żeby działała szybciej?
silnik skladowania danych mozna wybrac dla kazdej tabeli inny, wiec mozesz tak zrobic u siebie. W przypadku silnika MEMORY wszystkie dane przechowywane sa w pamieci, dlatego tez po restarcie serwera tabela jest czysta. Na pewno bedzie to dzialalo szybciej niz InnoDB czy MyISAM.

[*] Mam też inne tabele które są stosunkowo małe a wymagają częstego odczytu (zapisu tylko raz na jakiś czas np. settingsy). Dane w nich są jednak ważniejsze. Czy można zrobić tak aby tabela siedziała w ramie i była szybko odczytywana a update oznaczałby zapis na dysku ?
Z tego co wiem to nie istnieje taki silnik skladowania, ale mozna to obejsc w nastepujacy sposob (replikacja na jednej maszynie z uzyciem triggerow): tworzysz dwie tabele jedna MyISAM lub InnoDB, druga MEMORY. ustawiasz triggery na update, delete i insert dla tabeli trwalej, zeby modyfikowaly odpowiednie rekordy w tabeli MEMOERY. Dodatkowo przy kazdym wlaczeniu serwera kopiujesz zawartosc z tabeli trwalej do MEMORY.
Chociaz wg mnie jesli Twoja baza jest juz tak bardzo obciazona to zajalbym sie innymi sprawami: optymalizacja wykorzystania BD przez aplikacje (optymalizacja zapytan, cacheowanie zapytan), optymalizacja ustawien serwera i struktury BD, a na koniec redundancja. Jesli juz zopytmalizowales wszystko co sie dalo, to nie masz innej mozliwosci jak tylko dolozyc nastepny serwer, gdyz takie triki to czesciej przynosza wiecej problemow niz korzysci.

Przechowywanie sesji w BD moze czasami prowadzic do sporych problemow. Wiecej info we wpisie http://www.mysqlperformanceblog.com/2007/0...database-based/ i komentarzach ponizej.

Tak, ale wtedy musiałbym dodać nowe pole 'sessionId' zeby identyfikowac sesję. Raczej zawsze musi to byc Varchar.

Memory nie osługuje typów TEXT i BLOB

Coś ten JSON nie chce działać.

Po tak obszernej informacji ciężko cokolwiek wywnioskować Pokaż może jakie dane przepuszczasz przez kodera JSON.

tablice asocjacyjne.