J'ai une exigence ici,
Base de données locale (une) :
Une table user_local,
Base de données distante (un total de deux bibliothèques, cinq tables), toutes les informations sont liées via l'uid
Une base de données ( user_data_a ), il n'y a qu'une seule table user_basic, qui contient les informations de base de tous les utilisateurs. Les quatre autres tables d'une autre base de données (user_data_b) sont divisées en deux catégories,
Une catégorie (deux des tables, user_profile_active et user_profile_not_active) sont utilisés pour stocker les fichiers utilisateur, une table est destinée aux utilisateurs actifs, l'autre table est destinée aux utilisateurs inactifs,
Un autre type de table (les deux autres tables user_ext_info_active et user_ext_info_not_active) est utilisé pour stocker d'autres informations utilisateur, une table est également un utilisateur actif, et l'autre table C'est un utilisateur inactif,
Par exemple, si l'enregistrement d'un uid dans
user_basic n'est pas dans user_profile_active, alors il est dans user_profile_not_active,
S'il n'est pas dans user_ext_info_active, alors c'est dans user_ext_info_not_active
Théoriquement parlant, active correspond à active, et not_active correspond à not_active
La demande actuelle est d'utiliser principalement user_basic pour obtenir certains champs des informations correspondantes de l'utilisateur à partir de ces deux types de tables. (quatre au total), puis rassemblez-les en un seul. Les enregistrements sont écrits dans la table user_local locale. Il y a environ 800 000 enregistrements. Maître Qiu peut vous donner des conseils sur la façon de les gérer afin d'éviter d'interroger la base de données dans un. bouclez et évitez les débordements de mémoire et les délais d'attente ~~ Je vous en supplie
Le framework est thinkphp5 .1
Si les performances de vos données MySQL sont bonnes, vous pouvez écrire des opérations de table conjointes et les compléter avec une seule instruction. Cependant, il est en effet facile de provoquer un dépassement de délai et un débordement de mémoire. Il n'y a pas de raccourci. a 800 000 données. Si ces tables ont tout, c'est effrayant de connecter des tables pour interroger de grandes quantités de données. Il vaut mieux être honnête et finir d'abord d'exploiter les deux tables de données user_profile_active et user_profile_not_active, puis d'exploiter les deux tables suivantes user_ext_info_active et user_ext_info_not_active
.