Charger plus
Intermédiaire · indexing, pagination, sorting
Étant donnée une table bugs(id, token, title, category, device, reported_at, created_at, updated_at)
d'environ 10 millions de lignes, une application liste les bugs du rapporteur token = 'token4242'
triés par reported_at puis par id, 10 à la fois. La dernière ligne affichée est le bug avec
id = 6805335, reported_at = '2020-02-02'. Renvoyez les 10 lignes suivantes de la liste.
Renvoyez les colonnes (id, reported_at).
Colonnes attendues
id, reported_at
Indices
Indice 1 : les égalités sur le curseur
Regardez les lignes de token4242 du 2020-02-02 : plusieurs bugs partagent cette date. reported_at > '2020-02-02' saute ceux qui viennent après l'id 6805335, et >= répète ceux déjà affichés. Le curseur a besoin des deux colonnes.
Indice 2 : la colonne cachée
Un index secondaire stocke la clé primaire après ses propres colonnes : index_bugs_on_category_and_token_and_reported_at est donc en réalité trié par (category, token, reported_at, id). Fixez category et token, et ORDER BY reported_at, id correspond exactement à l'ordre de l'index.
Indice 3 : écrivez le curseur en entier
Écrivez « après (D, N) » sous la forme reported_at > D OR (reported_at = D AND id > N). Comparez EXPLAIN et les lignes lues avec la forme courte par constructeur de ligne (reported_at, id) > (D, N).