Über den Autor

Robert Basic

Robert Basic ist Namensgeber und Gründer von BASIC thinking und hat die Seite 2009 abgegeben. Von 2004 bis 2009 hat er über 12.000 Artikel hier veröffentlicht.

24 Kommentare

  • Das verwendete INT-Feld dürfte 10 bis 12 Stellen haben. Da können noch ein paar Kommentare zusammenkommen.

    Kritisch wird bestenfalls die Suche. Wenn es lahmarschig wird, solltest nachschauen, welche Indexes existieren und ggf. passende Indexes (manchmal über mehrere Felder) erzeugen. Die brauchen zwar Plattenplatz, bringen aber wirklich Speed.

  • Kommt ganz drauf an, auf welches Nummernformat die ID in MySQL eingestellt ist. Im Normalfall steht sie auf Integer, da kommst Du locker bis zwei Milliarden – für’s Erste also kein Grund zur Sorge 😉

  • Bei meiner WordPress-Installation ist das ein BIGINT-Feld mit der Länge von 20 Bytes. Das macht insgesamt 2^8 (ein Byte) ^ 20 mögliche Zahlen, sprich: 7,3 * 10^47 positive Werte. Sollte also auch mit relativ hohem Spamaufkommen so ein bis zwei Monate reichen… 😉

  • Keine Ahnung, wie WP die Indexes selbst handhabt und wie die mit Plugins zu verbessern sind. Mir ist schon vorgekommen, dass der Datenbanknutzer keine Rechte hatte, Indexes zu erzeugen (mea culpa). Da muss man dann halt irgendwann von Hand ran. Wenn manche Queries etwas träge sind, kannst Du ja mal das Slow-Query-Log vornehmen und die fiesesten Abfragen ermitteln:

    http://techblog.tilllate.com/2006/12/23/optimierung-von-mysql-abfragen-der-slow-query-log/

    Ich vermute aber einfach mal, dass der Autor des ungenannten Plugins nix wesentlich anderes gemacht hat…

  • Also ich bezweifle dass bigint als type der ID verwendet wurde, sondern viel eher INT(10). Aber nicht irrefuehren lassen das heisst nicht dass 10 stellen zur verfuegung stehen denn ein INT ist 4 Byte gross:

    Signed max: 2147483647
    Unsigned max: 4294967295

    Wieso es nicht 10 stellen sind entnimmt man am besten der Doku ( http://dev.mysql.com/doc/refman/4.1/en/numeric-types.html ) aber kannst beruhigt sein, selbst problogger.com hat das maximum noch nicht ueberschritten ^^

  • und die WP ID ist vom Typ BIGINT (unsigned) also kannst bis IDs bis 4.294.967.295 produzieren.

    Bei dem Tempo in diesem Blog ist das aber sicher bald erreicht 😉

  • warum löschst du nicht die spam kommentare raus? wenn die den größten anteil an den kommentaren haben bringt das sicher auch etwas performace, gibt es auch plugins dazu – wenn du nicht direkt auf die DB willst

  • rofl:))
    @robert, Akismet löscht ja die Einträge, wie aber Michael bereits gesagt hat, es wird die nächsthöhere ID genommen, nicht die nächste freie ID ab 1. Logisch, alles andere wäre bisserl aufwendig.

  • @michael
    weiß ich es ging mir einfach darum das man durch das löschen der spam einträge weniger datensätze hat und dadurch evtl. bessere performance

    @robert
    ich kann es leider gerade nicht prüfen aber bist du dir da 100% sicher? kann sein das ich mich irre aber ich dachte die bleiben trotzdem in den untiefen der DB

  • Huhu 🙂

    Das mit den BIGINTs bei MySQL mag zwar stimmen, aber problematisch wird es bei der Frage wie WordPress in PHP mit den Integern umgeht.
    Integer in PHP sind 32 bit signed. Also um die 2 Milliarden. Je nachdem, wie WordPress programmiert ist, kann es zu einem Überlauf kommen.
    Bei bis zu 2.147.483.647 Kommentaren bist du aber auf der sicheren Seite 😉

  • @Seong, hey, hallo:)))) Wie gehts? Btw, danke für die Aufklärung, scheint ja noch genug Luft nach oben zu sein.
    @Martin, ja, richtig, einfach deswegen, um false positives wieder rausnehmen zu können, werden die Spameinträge nicht sofort gelöscht.

  • @Robert: Wenn wir dazu übergehen uns über deine Kommentare zu unterhalten, dann reicht so ein 32 bit signed INT nicht aus… pfff… lächerlich 😀

Kommentieren