SQL Performance ?

Ich hab ja gerade alles upgraden müssen und dafür auch Geld investiert Jammern will ich nicht aber wenn ich dann in mein mysql-slow Log sehe wird mir schlecht

Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 1.9850 Sekunden.) [time: 1397974538... - 1397974538...]
SELECT time FROM wbb1_post WHERE threadID = '23063' AND time > '1397974460' ORDER BY time LIMIT 1

Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 2.6835 Sekunden.) [time: 1397974538... - 1397974538...]
SELECT time FROM wbb1_post WHERE threadID = '23063' AND time > '1397974460' ORDER BY time LIMIT 1

Keine ahnung woher das kommt ich kann nur sagen ich habe quasi keine Plugins mehr da die gefühlt sowieso immer nur von Kindern geschrieben werden die nach 2 Wochen die Lust an der weiterentwicklung verlieren und dann kein update mehr möglich ist .....

Ich bin kein SQL Guru aber wenn die Id so verwendet wird wie ich mir das vorstelle dann wäre das folgende anscheinend um einiges schneller ...

Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 0.6511 Sekunden.)
SELECT time FROM wbb1_post WHERE threadID = '23063' AND time > '1397974460' ORDER BY postId LIMIT 1

Ich möchte an dieser Stelle anmerken das ich bei einem Produkt in das ich regelmässig geld investiere schon einen gewissen Grad an Qualität liefert auf die ich mich verlassen kann .....

58459 ist das Resultat

Um der das ist der Grund antwort vorzubeugen ich hab das gleiche Problem auch mit kleineren Threads

und wenn das mit der time stimmt

# Query_time: 1.077320  Lock_time: 0.000089 Rows_sent: 25  Rows_examined: 2511
SET timestamp=1581117422;
SELECT    post.postID AS objectID
            FROM    wbb1_post post
                 JOIN wbb1_thread thread
                WHERE post.userID = '3493' AND post.isDisabled = 0 AND post.isDeleted = 0 AND thread.threadID = post.threadID AND thread.boardID IN ('3','89','10','233','15','67','52','66','31','14','12','54','181','87','24','73','79','70','28','104','105','114','120','88','179','183','69','68','91','95','90','75','96','93','122','214','225','226','232','134','25','333','26','51','27','30','229')
                ORDER BY post.time DESC, post.postID DESC LIMIT 25;

warum dann hier die postID im Order By ?

Zeige Datensätze 0 - 24 (25 insgesamt, Die Abfrage dauerte 0.6009 Sekunden.)
SELECT post.postID AS objectID FROM wbb1_post post JOIN wbb1_thread thread WHERE post.userID = '3493' AND post.isDisabled = 0 AND post.isDeleted = 0 AND thread.threadID = post.threadID AND thread.boardID IN ('3','89','10','233','15','67','52','66','31','14','12','54','181','87','24','73','79','70','28','104','105','114','120','88','179','183','69','68','91','95','90','75','96','93','122','214','225','226','232','134','25','333','26','51','27','30','229') ORDER BY post.time DESC LIMIT 25

vs

Zeige Datensätze 0 - 24 (25 insgesamt, Die Abfrage dauerte 1.1629 Sekunden.)
SELECT post.postID AS objectID FROM wbb1_post post JOIN wbb1_thread thread WHERE post.userID = '3493' AND post.isDisabled = 0 AND post.isDeleted = 0 AND thread.threadID = post.threadID AND thread.boardID IN ('3','89','10','233','15','67','52','66','31','14','12','54','181','87','24','73','79','70','28','104','105','114','120','88','179','183','69','68','91','95','90','75','96','93','122','214','225','226','232','134','25','333','26','51','27','30','229') ORDER BY post.time DESC, post.postID DESC LIMIT 25

Ich will nicht überanalysieren aber wenn das was ihr sagt stimmt ist im 2. SQL die postID egal .... Vielleicht sollte demnächst mal ein Augenmerk auf die SQL Performance gelegt werden. Soweit ich kann werde ich dabei auch unterstützend tätig sein

48834

id    select_type    table    partitions    type    possible_keys    key    key_len    ref    rows    filtered    Extra
1    SIMPLE    wbb1_post    NULL    ref    threadID,threadID_2,time,thread_3    threadID_2    4    const    118692    50.00    Using where; Using index

Kann man sagen, dass bestätigt heisst das ich was gefunden habe das auch behoben wird ?

Lieber Alexander Ebert, da ich dir keine Private Nachricht schreiben darf hiermit offiziell ! Mich kotzt diese überhebliche Art die ihr an den Tag legt schön langsam an !

Funktionen die mal drin waren wurden immer wieder entfernt um dann als Deckmantel des Updates erneut verkauft werden können.

Ich erinnere mich als man 2015 ein Plugin kaufen musste um die letzten X Beiträge anzuzeigen (war in einer vorgänger Version enthalten).

Ihr habt noch immer kein vernünftiges Eco System um Plugins dauerhaft verwenden zu können anscheinend verlieren die Entwickler immer wieder die Lust.

Und jetzt schon wieder diese Grosskotzige Antwort das meine MYSQL an allem schuld ist .....

Ich zeig euch und somit auch dir auf das die Indizes ein Thema sind lasse mir erklären das man nach PostId nicht sortieren kann (ok verständlich mit dem Timing) und dann zeige ich euch folgendes SQL

ORDER BY post.time DESC, post.postID DESC

aus meiner sicht macht hier dann die PostID keinen Sinn mehr Warum ? wenn es gleiche Zeit ist ? dann soll die Post ID verwendet werden

Dauer 1.1 vs. 0.6 sec. deine Antwort die bei mir angekommen ist => Kauf dir mehr Ram dann gehts auch mit unseren schlechten SQL Statements ?

Vielleicht solltest du mal daran arbeiten wie du mit Kunden kommunizierst, vorallem jene die immer zuerst versucht haben positiv mitzuarbeiten.

Ich habe übrigens keine MYSQL Settings die ihr empfehlen würdet gefunden...... und klar wenn quasi das Ganze Forum im Ram steht gehts immer schneller ..... Wenn ihr Performance Issues immer so löst indem ihr mehr Ram kauft ist mir alles klar - auch ein weg bin gespannt wieviele eurer Kunden das machen können.

Ausserdem finde ich die Kust seines selektiven Lesens bemerkenswert wie ich angemerkt habe habe ich das Problem nicht bei einem sondern bei zig Threads:

Quote from marksoft

58459 ist das Resultat

Um der das ist der Grund antwort vorzubeugen ich hab das gleiche Problem auch mit kleineren Threads

181883 opend Tables

2211 Mb

// aus der mysql config

innodb_buffer_pool_size=4G

Grandiose Antwort, allerdings wo ich beleidigend wurde hätte ich gerne gewusst. Es sind alles Fakten:

1. das Order By ist nach der Erklärung von Reen aus meiner sicht komplett unnötig und ist bei mir ein unterschied von 0.6 vs 1.07 Sekunden darauf wurde aber nicht eingegangen es wurde nur erklärt der "Arbeitsspeicher ist schuld" (So ist es angekommen)
2. Ich weise aktuell nochmals darauf hin das es wiederholt passiert ist das Funktionen entfernt wurden um sie danach mit einem Update wieder zu erhalten. Hier mal was mir auf die schnelle einfällt auch das habe ich als Vorwurf eingebracht nachdem ich zum wiederholten Male mit meinen Argumenten gegen eine Wand fahre.
   1. Letzte Beiträge
   2. unterschiedliche Logos bei Kategorien
3. Wenn es für den betrieb des Forums anscheinend zwingend notwendig ist Mysql korrekt einzustellen warum findet man nirgends dafür eine Hilfestellung ?
4. Hr. Ebert hat durch seinen Satz Mal als Vergleich, woltlab.com nutzt aktuell bei einer InnoDB data size von 12,2 GB geschmeidige 18,1 GB Arbeitsspeicher. Den eindruck das nur ausreichend RAM ein einwandfreies Forum gewährleisten vermittelt und das die Performance der SQL Statements kein Thema sind wenn alles im RAM "stehen bleibt".
5. mein Hinweis auf das selektive Lesen ist ein Hinweis das es nicht nur bei grossen sondern auch bei kleinen Threads passiert. ich hatte nur das dumme Pech euch aus dem Mysql Log genau dieses herauszupicken und habe das auch schnell erkannt und eben auch notiert das es nicht nur an diesem Thread so aussieht.
6. Mein Eindruck bezüglich der Plugins bisher war immer das ich keines über mehr als 2 Versionen verwenden konnte weil es ein Update behindert hat. auch hier könnte ich eine Liste anführen ist mir aber zuviel arbeit.
   1. Ein 4 gewinnt Spiel wars einmal
   2. und ein Antispam ding bei der Aktuellen wo quasi die Entwicklung nicht mehr da war für neue Versionen und diesen Eindruck hab ich festgehalten. Wenn ich Plugins nicht dauerhaft einsetzten kann dann finde ich den zweck auch nicht mehr zielführend.

Anhang A: https://www.duden.de/rechtschreibung/ueberheblich

Du darfst mir jetzt noch alle Beleidigungen in meinen Postings aufzählen.

Ergänzung: aufgrund der Antwort nach diesem Posting => ich wollte das per Konversation klären war aber nicht möglich auch auf das habe ich hingewiesen.

Das ganze Forum hat bei mir 3.1 GB wobei der Suchindex knapp die hälfte darin füllt. ich hab die Innodb pool size auf 4GB gestellt. Mein System verfügt über 16GB Ram und liegt bei Hetzner MYSQL und PHP sind die letzten gültigen Versionen

• Server-Version: 8.0.19 - MySQL Community Server - GP
• nginx/1.14.0
• Datenbank-Client Version: libmysql - mysqlnd 7.4.2
• PHP-Version: 7.4.2

und ich erneuere hiermit den Verdacht das "ORDER BY post.time DESC, post.postID DESC LIMIT 25" auch nur nach post.time ausreichend wäre was bei mir knapp 40% einsparen würde

Sodala da wäre ich mal wieder mit dem gleichen PRoblem und diesmal auch mit einer Lösung die hoffentlich auch umgesetzt wird !

# Time: 2020-11-18T12:11:36.869665Z
# User@Host: root[root] @ localhost []  Id:   740
# Query_time: 1.784043  Lock_time: 0.000093 Rows_sent: 1  Rows_examined: 1244797
SET timestamp=1605701495;
SELECT          time
FROM            wbb1_post
WHERE           threadID = '46939'
AND time > '1528443396'
ORDER BY        time LIMIT 1;
# Time: 2020-11-18T12:12:26.170519Z
# User@Host: root[root] @ localhost []  Id:   840
# Query_time: 1.841918  Lock_time: 0.000123 Rows_sent: 1  Rows_examined: 1244797
SET timestamp=1605701544;
SELECT          time
FROM            wbb1_post
WHERE           threadID = '46939'
AND time > '1528443396'
ORDER BY        time LIMIT 1;
# Time: 2020-11-18T12:13:10.619352Z
# User@Host: root[root] @ localhost []  Id:   951
# Query_time: 1.937856  Lock_time: 0.000086 Rows_sent: 1  Rows_examined: 1244797
SET timestamp=1605701588;
SELECT          time
FROM            wbb1_post
WHERE           threadID = '46939'
AND time > '1528443396'
ORDER BY        time LIMIT 1;
# Time: 2020-11-18T12:17:07.661899Z
# User@Host: root[root] @ localhost []  Id:  1453
# Query_time: 1.837239  Lock_time: 0.000137 Rows_sent: 1  Rows_examined: 1244797
SET timestamp=1605701825;
SELECT          time
FROM            wbb1_post
WHERE           threadID = '46939'
AND time > '1528443396'
ORDER BY        time LIMIT 1;

JA bitte lasst und das Problem dieses mal ECHT angehen mir geht das herumwurschteln mit Configs ets schon so auf die nerven.

SELECT time FROM wbb1_post WHERE threadID = '46939' AND time > '1528443396' ORDER BY time LIMIT 1

hat ja den Sinn den max Timestamp zu finden wenn ich das richtig sehe .... mir ist nicht ersichtlich warum diese Abfrage so ist wie sie ist nach wie vor. Aber ja meine Argumentation mit der PostID wurde ja abgelehnt was ja noch ok ist aber folgendes ist auf meinem System ebenfalls schneller !

Query_time: 1.841918 vs 0.0060

Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 0.0060 Sekunden.)
SELECT MAX(time) FROM wbb1_post WHERE threadID = '46939' AND time > '1528443396'

Könnten wir das bitte konstruktiv angehen danke und bitte wenn ein SQL schneller ist das gleiche macht lasst uns echt daran denken das umzusetzen danke.