Bonjour,  
Lorsque j'utitise SELECT * FROM my_table, le tri de la liste est dans l'ordre dans lesquel les enregistrements ont été faits.  
Comment faire pour afficher cette liste dans l'ordre inverse ?  
Je n'utilise pas d'id auto-incrémente et donc ne peut faire ORDER BY id DESC. Je n'utilise pas d'id car le nombre d'enregistrements est trop fréquents (mais pas la quantité d'enregistrement car il y a des DELETE réguliers), mais dans tous les cas l'id ne cesserait d'augmenter et de dépasser sa valeur maximale...

Même si, souvent, les enregistrements apparaissent par défaut dans l'ordre dans lequel ils ont été insérés, on ne peut pas présager de ce résultat. Si tu n'indiques pas un tri explicite, alors le SGBD se réserve la possibilité de fournir les résultats dans l'ordre qu'il veut  
 
Donc, si tu veux un tri particulier, il faut l'indiquer, par exemple avec une colonne "date d'insertion"

Oui, tu n'as pas d'autre choix. Il te faut te débrouiller pour avoir une colonne qui te permette de faire ton tri. Un ID, tu n'en veux pas... Dans ce cas, une date d'ajout parait le mieux pour ton objectif...
 
Tu risques d'être surpris par l'ordre d'apparition sinon (c'est aléatoire, selon l'humeur de la base )

ah oui, c'est bizarre ce comportement aléatoire. Merci pour ces précisions, ça va m'éviter des surprises selon l'humeur de la base

+1 avec l'ordre "aléatoire" des résultats. Une même requête, lancée deux fois de suite, si elle n'a pas de clause order by, peut parfaitement donner des résultats triés différements.

Et d'après vous, qu'est-ce qui mieux d'utiliser (taille, vitesse du tri) pour gérer la clause ORDER BY sur de très nombreux enregistrements : un BIGINT qui s'auto-incrémente ou un DATETIME ?

un datetime avec un default now(). une séquence, ça se réinitialise, etc. Un index dessus et voilà.

t'as pas à te poser cette question. la seule question que tu dois te poser, c'est "qu'est qui représente le mieux l'information que je veux stocker"
 
cf. le lien de ma signature.

Dans le cas de mes tables que ce soit un datetime ou un entier qui s'incrémente ça ne change rien car je n'utilise aucun des deux pour la recherche, c'est juste pour le tri. C'est pourquoi un datetime avec now() me convient tout aussi bien et évite la réinitialisation d'un entier... bien que la réinitialisation d'un bigint unsigned soit vraiment difficile à obtenir !
Question de novice à propos de la clé index: Est-ce qu'on la créer généralement sur le champ qu'on a l'intention de trier avec ORDER BY ?

bah tu mets un index et voilà.