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]

I tabela równie dobrze może posiadać parę jako klucz główny,

A gdzie ja napisałem że nie może?

A pozatym ty mi napisałes "g.prawda" do odpowiedzi:

Klucz główny powinien być zawsze.

Para to też klucz główny, wiec klucz istnieje. Sam to teraz mowisz, ze para moze byc kluczem głównym, więc sam sobie przeczysz słowami "g.prawda".