ostatni rekord z tablicy - problem z optymalizacją Opcje

[ChrisB]

witam jak w temacie potrzebuje pobrać ostatni rekord z tablicy

tablica to innodb z około 1k rekordów (w tym przypadku mała ale i prosta - mam też parę innych tabel gdzie jest więcej rekordów i ten sam problem)

[SQL] pobierz, plaintext 
CREATE TABLE IF NOT EXISTS `statydzienne` (
  `ids` int(6) NOT NULL AUTO_INCREMENT,
  `data` date NOT NULL DEFAULT '0000-00-00',
i tam pare innych pól które nie maja aktualnie znaczenia
  PRIMARY KEY  (`ids`),
  KEY `data` (`data`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1037 ;
[SQL] pobierz, plaintext 

problem:

polecany wszędzie sposób pobierania ostatniego rekordu:

[SQL] pobierz, plaintext 
mysql> EXPLAIN SELECT * FROM statydzienne ORDER BY ids ASC LIMIT 1;
+----+-------------+--------------+-------+---------------+---------+---------+------+------+-------+
| id | select_type | TABLE        | type  | possible_keys | KEY     | key_len | ref  | rows | Extra |
+----+-------------+--------------+-------+---------------+---------+---------+------+------+-------+
|  1 | SIMPLE      | statydzienne | INDEX | NULL          | PRIMARY | 4       | NULL |  882 |       |
+----+-------------+--------------+-------+---------------+---------+---------+------+------+-------+
1 row IN SET (0.00 sec)
 
[SQL] pobierz, plaintext 

czyli żebym otrzymał wynik - musi przeskanować cała tablice...

inny sposób:

[SQL] pobierz, plaintext 
mysql> EXPLAIN SELECT * FROM statydzienne WHERE ids=(SELECT max(ids) FROM statydzienne);
+----+-------------+--------------+-------+---------------+---------+---------+-------+------+------------------------------+
| id | select_type | TABLE        | type  | possible_keys | KEY     | key_len | ref   | rows | Extra                        |
+----+-------------+--------------+-------+---------------+---------+---------+-------+------+------------------------------+
|  1 | PRIMARY     | statydzienne | const | PRIMARY       | PRIMARY | 4       | const |    1 |                              |
|  2 | SUBQUERY    | NULL         | NULL  | NULL          | NULL    | NULL    | NULL  | NULL | SELECT TABLES optimized away |
+----+-------------+--------------+-------+---------------+---------+---------+-------+------+------------------------------+
2 rows IN SET (0.00 sec)
[SQL] pobierz, plaintext 

nie wiem czy lepiej bo nie do końca rozumiem tą drugą linijke:) ale przynajmniej z pierwszej wynika że tylko 1 wiersz skanuje - ten poprawny

opcja 3 to przechowywanie w tempie id ostatniego wiersza (jest on dodawany raz dziennie wiec w tym przypadku to nie jest problem) :

[SQL] pobierz, plaintext 
mysql> EXPLAIN SELECT * FROM statydzienne WHERE ids=777;
+----+-------------+--------------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | TABLE        | type  | possible_keys | KEY     | key_len | ref   | rows | Extra |
+----+-------------+--------------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | statydzienne | const | PRIMARY       | PRIMARY | 4       | const |    1 |       |
+----+-------------+--------------+-------+---------------+---------+---------+-------+------+-------+
1 row IN SET (0.00 sec)
[SQL] pobierz, plaintext 

którą drogą powinienem iść? (zakładam że 1 mogę pominąć, więc jest 2 którą pod względem optymalności nie do końca rozumiem, lub 3 - dla której cachowanie trzeba by dopisac)

czy może są lepsze metody?

[ChrisB]

i nie jest to jedyny problem z indexami jaki mam;/ przy wybieraniu danych z where po indexie - w paru innych przypadkach tez skanuje wszystko jak leci;/
ten w tym temacie najczęściej występuje i jest najprostszy dlatego chciałem od niego zacząć

to stoi na vps z mysql 5.0.67 bodajże, z własnymi ustawieniami my.cnf - może coś tam mam źle...
zauważyłem też naprawdę spore wartości
Handler_read_rnd_next
(Liczba żądań odczytu następnego rekord w pliku z danymi. Wartość jest duża przy wykonywania wielu przeszukiwań tabeli. Ogólnie sugeruje to, że tabele nie są poprawnie zindeksowane lub że zapytania nie są napisane w sposób pozwalający skorzystać z istniejących indeksów.)


co do indexów
czyli zakładając że wybieram przewaznie dane z tej tablicy w formie

where id_uzyt=XX and data >'yy'

powinienem złożony klucz na id_uzyt,data jako unique nałożyc? (nie ma id_uzyt i daty w tej kombinacji powtarzającej się) i usunąć klucz primary auto increment z ID i całe pole wywalić?
i czy ten index będzie też wykorzystywany przy zapytaniach tylko na id_uzyt lub tylko na date - czy powinienem założyć 3 - id_uzyt/data(unique), id_uzyt(index), data(index)

Ten post edytował ChrisB 30.08.2010, 10:10:12