Worker Pool für SQL Aufgaben und dann da alles an Queries reinkippen und mit Callback rausholen. Das wird dir nur vermutlich nichts sagen, aber dein Problem hat nichts mit SQL oder Minecraft zu tun, sondern ist Softwarearchitektur. Wie man mit Worker Pools arbeitet braucht bisschen Erfahrung und vielleicht auch Projekte in denen man mal ne Library genutzt hat, die sowas macht.
Da Minecraft selbst überhaupt keine Multithreading API hat, ist es als Lernbeispiel extrem ungeeignet. Da wirst du nie mit in Berührung kommen. Von daher für dich der selbe Tipp, wie für alle anderen auch: Wenn du keine Ahnung hast, dann lass es. Der naive Ansatz mit einfachen Dateien ist für Anfänger deutlich besser, als Datenbanken. Ich könnte da jetzt noch ins Detail gehen und dir erklären, warum asynchrones Datenbank IO in Minecraft eh fast nie umgesetzt werden kann, aber ich glaub nicht, dass dich das überzeugen würde. Wie gesagt, Bukkit ist dafür nicht gebaut.
Ich habe gehört, dass es viel Performance frisst, sobald viele Abfragen nacheinander gemacht werden. Meine Frage wäre daher, wie man am besten eine asynchrone MySQL programmieren kann.
Das ist übrigens absolut falsch. Die Abfragen brauchen die Zeit, die sie nunmal brauchen. Aufgrund der Tatsache, dass du von dem Thema wenig Ahnung hast, kann ich dir aber versichern, dass die Ausführungszeit für deine Anfragen irrelevant sein wird. Was vermutlich deutlich teurer wird, sind schlecht implementierte Datenbankzugriffe, wie sie von Anfängern nunmal fast durchgehend gebaut werden.
Also sofern du fertig werden möchtest ohne dir Fallen zu bauen, vergiss den Ansatz mit der Datenbank und arbeite einfach mit Dateien un In-Memory Daten. Falls du das Thema lernen willst und bereit bist da mehrere Wochen drin zu versenken und auch die notwendige Zeit hast. Guck dir an, wie man Aufgaben mit explizitem Threading in Worker Pools parallelisiert und was Callback Architekturen sind. Und wenn du das verstanden hast, benutzt du bitte
DataSource.
Vorher überlegst du dir aber vielleicht auch, wie du die entsprechenden Events in Bukkit verzögern willst und wie du mit Delays in der Abfrage umgehst. Du kannst den Server nämlich nicht so lange anhalten, bis du deine Daten hast. Und du musst davon ausgehen, dass die Datenbank nicht erreichbar ist und entsprechend deinen State irgendwie konsistent halten. Den Teil vergessen dann leider die Meisten. Eine Datenbank ist nicht cool und sie ist auch nicht besser als Flatfiles. Sie ist eigentlich sogar schlechter, aber ab einem gewissen Punkt kommt man oft nicht mehr ohne aus. Das ist dann der Moment, wo man in den sauren Apfel beißt und die Datenbank einbindet, nicht vorher.