arrière-plan
Le test m'a dit qu'il avait importé les données, mais je n'ai pas affiché les données. J'ai donc saisi l'instruction et lié les deux tables pour interroger les données. J'ai utilisé la jointure gauche mais il n'y avait pas de données, mais les deux tables ont été interrogées séparément et il y avait des données. C'était comme l'enfer. En fait, dans ce cas, c’est généralement parce qu’il y a plus d’espaces dans les données. Mais les identifiants uniques de mes deux tables sont les mêmes, c'est suffisant pour une telle condition d'association.
question
-- a,b 可以理解为Table1，Table2的外号
-- id是a,b表的栏位名称，且两边数据都相等
-- left join...on...去看看数据库的笛卡尔积吧
select b.* from table1 a left join table2 b on a.id=b.id;
CHAR et VARCHAR
Plus tard, on a découvert qu'il y avait effectivement un problème avec les données, mais la clé était qu'il y avait des espaces dans les données. Mais même ainsi, j'ai pu le découvrir en utilisant des conditions de requête sans espaces, ou en utilisant des conditions de requête avec des espaces ajoutés, car le système lui-même a supprimé les espaces à la fin. .
Une table est de type CHAR et l'autre est de type VARCHAR. Les requêtes de type char bloquent automatiquement les suivantes ou quelque chose du genre, mais elles peuvent quand même être trouvées.
Pour les données de type char, j'ai créé une longueur de 17, mais la valeur réelle n'est que de 16 chiffres (certains ont 17 chiffres) et le dernier chiffre est rempli d'espaces ; mais VARCHAR ne remplira pas les espaces pour vous et la longueur sera être rempli .
Résumer
Si la longueur de vos données est fixe et que la longueur du champ créé est la même, l'utilisation de CHAR ne posera aucun problème, mais si vous êtes incohérent, vous pouvez toujours utiliser VARCHAR ou VARCHAR2. On dit qu'il y a un petit écart de performances entre CHAR et VARCHAR, mais pour les gens comme moi qui peuvent l'utiliser, une trop grande recherche de performances peut conduire à un tas de bugs. Mais j'apprendrai lentement plus tard.