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?

[nospor]

Ja tylko stwierdzam że nie musi być klucza głównego jak nie jest potrzebny.

To jest tylko ładniej napisane "g.prawda" (IMG:style_emoticons/default/smile.gif)
Zacytuję ci odpowiedż jaką ci dałem na "g.prawda"

Wiem, że bez klucza głównego tabela może "żyć". Jednak dla własnego dobra, nawet jesli w danej chwili go nie widzisz, dobrze jest by klucz główny był.

I mówię ci to na podstawie zawodowego doświadczenia (IMG:style_emoticons/default/smile.gif) Też czasem nie używam klucza głównego, zdarza się to sporadycznie i tylko wówczas gdy naprawdę, naprawdę, naprawdę nie jest konieczne (IMG:style_emoticons/default/smile.gif)

edit: po przeczytaniu tego wszystkiego jeszcze raz po części się z tobą zgodzę. Źle to napisałem
Powinienem był napisać "W większości przypadków powinien być zawsze" (tak miałem w domyśle - mój błąd).Większość używanych przez nas tabel powinna mieć klucz główny. Oczywiście zdarzają się odstępstwa gdzie ten klucz niczemu służyć nie będzie.
Twoja cudna argumentacja "g.prawda" niestety zadziałała na mnie jak płachta na byka. Twoje ostatnie zdanie już jest "lepiej" sformułowane i "zmusiło" mnie do ponownego przetrawienia treści (IMG:style_emoticons/default/winksmiley.jpg)