`SELECT * FROM `messages` WHERE user_id ORDER BY created_at DESC LIMIT N` が非常に遅い

5/9 に、このクエリが12回たたかれ、それぞれが10分くらい探索し続け、DBのCPU使用率が張り付き、traQがめちゃくちゃ重くなった。
おそらくIndexが効いていないだけだが、このクエリがなんで叩かれたのか、から調査してIndexを貼るか他の解決法を模索するかをして欲しい。

{"id":"8cac9a5f-a291-4b7e-a2d4-71134508c598","state":1,"bot":true,"iconFileId":"cd7d0d0d-18d3-434b-a369-54077323f3a3","displayName":"光の商人 カシワデ","name":"Webhook#jKyaX6KRS36i1HETRQjFmA","twitterId":"","lastOnline":null,"updatedAt":"2024-05-09T07:46:05.612726Z","tags":[],"groups":[],"bio":"","homeChannel":null}

SELECT * FROM messagesWHERE messages.user_id = 'UUID' ANDmessages.deleted_at IS NULL ORDER BY messages.created_at DESC LIMIT N
https://monitor.trap.jp/d/HU1s_0w7z/mariadb-slow-query-log?orgId=1&from=1715239500000&to=1715241900000
https://github.com/traPtitech/traQ/blob/master/docs/dbSchema/messages.md

https://q.trap.jp/messages/6a0dbe52-4ec6-4581-94db-8a106d13ef2b

Start with the linked MariaDB slow-query log and docs/dbSchema/messages.md, then trace which application path issued the messages query. Confirm the cause of the repeated full or inefficient lookup and evaluate the index or other remedy. Done means the query is handled efficiently without the reported CPU saturation and prolonged execution.