Ce n'est qu'un avertissement et n'empêche pas la table de fonctionner correctement.
rappel :
Citation :
Les index sont utilisés pour trouver des lignes de résultat avec une valeur spécifique, très rapidement. Sans index, MySQL doit lire successivement toutes les lignes, et à chaque fois, faire les comparaisons nécessaires pour extraire un résultat pertinent.
Plus la table est grosse, plus c'est coûteux. Si la table dispose d'un index pour les colonnes utilisées, MySQL peut alors trouver rapidement les positions des lignes dans le fichier d'index, sans avoir à fouiller toute la table
Si une table à 1000 lignes, l'opération sera alors 100 fois plus rapide qu'une lecture séquentielle.
La table des messages privés est créé ainsi :
CREATE TABLE priv_msgs (
msg_id mediumint(8) unsigned NOT NULL auto_increment,
msg_image varchar(100) default NULL,
subject varchar(255) NOT NULL default '',
from_userid mediumint(8) unsigned NOT NULL default '0',
to_userid mediumint(8) unsigned NOT NULL default '0',
msg_time int(10) unsigned NOT NULL default '0',
msg_text text NOT NULL,
read_msg tinyint(1) unsigned NOT NULL default '0',
PRIMARY KEY (msg_id),
KEY to_userid (to_userid),
KEY touseridreadmsg (to_userid,read_msg),
KEY msgidfromuserid (msg_id,from_userid)
) TYPE=MyISAM;
On peut y lire que la clé principale de la table est le champ
msg_id et un peu plus bas qu'un index de performance a été créé sur les colonnes msg_id et from_userid. A mon avis et jusqu'à preuve du contraire cet index est superflu, je n'ai pas vu de clause
where qui porterait simultanément sur ces deux champs et dans cet ordre.