Zuerst sollte erwähnt werden, dass MySQL im Normalfall pro Query nur EINEN pro Tabelle Index auf einmal nutzen kann (es gibt Ausnahmen, merged-index, aber nur unter bestimmten Umständen in bestimmten Queries).

Ein Beispiel für den Einsatz eines Index über mehrere Spalten, wäre z.B. das folgende:

Eine Tabelle, in welcher Nachrichten zwischen Benutzern aufbewahrt werden, folgende Spalten sind vorhanden:

ID (int), receiverUserID(int), senderUserID(int), subject(varchar), text(text), time(int)

Wollen wir nun alle Nachrichten finden, die User 123 an User 234 geschickt hat und das Ergebnis noch nach Zeit sortieren, brauchen wir folgendes Query:

SELECT ID, subject, text, time
FROM message
WHERE receiverUserID = 234 AND senderUserID = 123
ORDER BY time ASC

Zuerst fällt auf, dass man die Nachrichten nach ID sortieren kann, was im Normalfall besser ist, als nach time, da wir davon ausgehen, dass die ID sich von Nachricht zu Nachricht um eins erhöht und die neusten somit die höchsten IDs haben.

Ohne das Wissen, dass es mehrspaltige Indizes gibt, würde man einen Index auf receiverUserID oder senderUserID legen, alternativ sogar beides, allerdings würde MySQL dann nur einen von beiden nutzen.
Also legt man einen über beide an, was bei großen Datenmengen einen extremen Geschwindigkeitsschub bringen kann.

Um die Sortierung nun auch noch über den Index zu regeln, könnten man als dritte Spalte nun noch die ID in den Index aufnehmen, was allerdings nur sinnig ist, wenn man davon ausgeht, dass das Ergebnis wirklich viele Ergebnisse erzielen wird.

Es gibt definitiv keine Konfiguration, die allgemeingültig ist, aber ich versuche hiermit eine Hilfestellung zu geben, wie man die besten Werte für die eigenen Bedürfnisse findet.

Nicht nur der Server spielt eine Rolle, auch die Storage-Engine, um sich viel Stress zu ersparen, sollte man im vorraus planen, was man braucht und für welche Engine man sich entscheidet. Auch hier gibt es keine Universallösung, jede hat ihre Vor- und Nachteile, aber darauf will ich in diesem Eintrag nicht eingehen.

Da ich für das aktuell laufende Projekt nur InnoDB einsetze, beziehen sich die Ratschläge auf eine reine InnoDB Konfiguration und sollten ab MySQL Version 5.0 funktionieren.

“innodb_dirty_pages_pct”
Gibt an, wie viele  InnoDB-Buffer-Pages im RAM vorhanden sein dürfen, ohne auf Festplatte geschrieben worden zu sein. Standard ist 90%, was für die meisten Umgebungen absolut OK sein sollte.

“thread_cache_size”
Wie viele Threads dürfen sich im Cache befinden? Jede Verbindung zum Server braucht einen eigenen Thread, ist die Verbindung beendet, kann der Thread im Cache gelagert werden und steht der nächsten Verbindung zur Verfügung. Threads zu erstellen ist unnötiger Overhead, “SHOW GLOBAL STATUS” auf der MySQL Konsole gibt in der Variable “threads_created” aus, wie viele Threads erstellt werden. Dieser Wert sollte um maximal 10 pro Sekunde steigen, steigt er schneller, kann der Thread-cache vergrößert werden.

“table_definition_cache”
Sollte größer oder gleich der Anzahl der vorhandenen Tabellen sein um unnötigen I/O Overhead zu ersparen.

“innodb_open_files”
Sollte größer oder gleich der Anzahl der vorhandenen .ibd Dateien im MySQL-Datenverzeichnis sein (bei Debian meistens /var/lib/mysql).

“innodb_log_buffer_size”
Die globale Variable “innodb_os_log_written” hilft hier bei der Ermittlung eines sinnvollen Wertes, der Wert sollte nicht zu schnell steigen, hier kann I/O Performance gewonnen werden.

“skip_name_resolve”
Sollte aktiv sein, damit nicht für jeden Client 2 DNS-Lookups stattfinden, gleichzeitig bedeutet dies, dass Berechtigungen nur noch auf IP und nicht auf Hostnamen-Ebene verteilt werden können.

“innodb_flush_method”
Falls ein Hardware-Raid mit ordentlichem Cache und Battery-Backup genutzt wird, sollte hier 0_direct eingestellt werden, um zu verhindern, dass OS-Buffer genutzt werden, welche das Logfile unbrauchbar machen könnten, wenn der Server abstürzt.

“innodb_flush_log_at_trx”
Sollte auf 1 gestellt werden, damit jede beendete Transaktion sofort im Binarylog landet, um Datenverlust zu verhindern, falls der Server abstürzt. Der Wert 1 ist der beste Kompromiss zwischen Performance und Datensicherheit!

Diverse Key-Buffers und andere Caches (ausgenommen dem Query-Cache) können sehr klein gehalten werden (nicht abschalten, MySQL nutzt MyISAM für die Metatabellen). Hier würde nur sinnlos RAM belegt werden!

Auf Linux-Systemen sollte die swappiness noch auf 0 oder 1 gestellt werden, um zu verhindern, dass der Kernel MySQL Buffers in den SWAP-Space verschiebt, falls diese länger nicht genutzt werden. Swap-I/O ist weitaus schlimmer als normaler HDD-I/O, da MySQL “denkt” es würde mit schnellem RAM arbeiten, welcher in Wirklichkeit aber auf der HDD im Swap zu finden ist. Auf Debian-Systemen kann man diesen Wert mittels /etc/sysctl.conf setzen (vm.swappiness = 0) und danach “sysctl -p” ausführen.

Der restlich verfügbare Arbeitsspeicher sollte dem InnoDB-Buffer-Pool zur Verfügung gestellt werden, ist dieser groß genug, kann auf nahezu alle HDD-Leseabfragen verzichtet werden und es entsteht nahezu nur noch Schreib-I/O.

Es gibt noch weitere Einstellungen bezüglich des InnoDB-Tablespace und allgemeinen Einstellungen, falls hier noch Intresse besteht, hinterlasst nen Kommentar, werde dann versuchen zeitnah einen weiteren Beitrag zu schreiben.

class Address {
  /*diverse Properties, hauptsächlich Strings*/
}
class MethodSpecial extends Method {
  /*diverse andere Properties*/
}
abtract class Method {
  protected $address;
  public function setAddress(Address $address){
    $this->address = $address;
  }
}

$address = new Address(.....);
$method = new SpecialMethod(....);
$method->setAddress($address);

$string = serialize($method);

Gibt man $string mit einem einfachen echo aus, fällt auf, dass hier komische Sonderzeichen vorhanden sind, speichert man das ganze in ein TEXT Feld in einer Tabelle, werden aus diesen Zeichen Sternchen. Das unserialize schlägt fehl.

Nun gibt es zwei Ansätze, dieses Problem zu lösen:
1. base64_encode und base64_decode: einfach den String vorher kodieren und dann speichern, beim auslesen dann erst dekodieren und danach deserialisieren.
2. GLOB bzw. BLOB statt TEXT als Feldtyp nutzen (nicht von mir getestet, der Tip wurde mit von einem Bekannten gegeben)

Welche Möglichkeit man nutzt, hängt davon, ob man eben einfach nur ein kurzes Query abfeuern will oder ob es für die Applikation an sich nötig ist.
Problem an der zweiten Lösung ist, dass diese immer in einem Full-table-scan endet, da jedes Textfeld in einen binären Datentyp umgewandelt werden muss, um zu suchen. Hier ein Beispiel:

SELECT * FROM data
WHERE field COLLATE utf8_bin = 'Abc'

Umgekehrt geht das ganze natürlich auch, falls man case-unsnsitiv in einem binären Datentyp suchen will.

Für den Fall, dass ein GROUP BY aber sein muss, das Ergebnis aber keiner Sortierung bedarf, sollte man ein ORDER BY NULL hinzufügen, da MySQL das grupperte Ergebnis sortiert, durch das Sortieren nach NULL, verhindert man dies und kann das Query unter Umständen noch beschleunigen.

SELECT a, COUNT(b) FROM test_table GROUP BY a ORDER BY NULL;

        /**
         * clusterName
         *  -> master / slave[Number[0,1,n]
         *  --> host
         *  --> port (optional)
         *  --> prio (only for slave, >0)
         */
        $databaseClusters = array(
                "main" => array(   /* Clustername */
                        "master" => array(
                                "host" => "10.0.0.100",
                                 ),
                        ),
                        "slave1" => array(
                                "host" => "10.0.0.101",
                                "prio" => 50,  /*mehr Last*/
                                 ),
                        ),
                        "slave2" => array(
                                "host" => "10.0.0.102",
                                "prio" => 20, /*weniger Last*/
                                 ),
                        ),
        );

function getSlave($cluster)
        {
                // gibt es nur einen Server im Array, wird dieser zurückgeliefert
                if(count($databaseClusters[$cluster]) == 1)
                {
                        return "master";
                }
                else
                {
                        $slaves = array();
                        $sum = 0;
                        for($i = 0; $i < count($databaseClusters[$cluster]); $i++)
                        {
                                for($h = 0; $h <= $databaseClusters[$cluster]["slave$i"]["prio"]; $h++)
                                {
                                         array_push($slaves, "slave$i");
                                }
                                $sum += $databaseClusters[$cluster]["slave$i"]["prio"];
                        }
                        return $slaves[rand(0,$sum)];
                }
        }

Es wird ein Array erstellt, worin der erste Server 50 mal und der zweite 20 mal Vertreten ist, dann wird ein Zufälliges Element (0-69) herausgepickt. Es gibt gewiss andere Methoden, aber diese Funktioniert für uns einwandfrei, bin aber immer für bessere Vorschläge offen!

Server 2 (Kernel 2.6.24)

Hier ist noch zu erwähnen, dass 100% CPULast bedeutet, dass alle 8 Kerne ausgelastet sind, also 8*100%.

Nach genauerer Analyse, stellten wir fest, dass die 8 CPU-Kerne auf Server 2 ziemlich gleichmäßig ausgelastet wurden (15-20%), auf Server 1 bekam allerdings nur der erste Kern eine Last von bis zu 100%.
Grund hierfür ist (sehr wahrscheinlich), dass der neuere Kernel Threading unterstützt, der alte zwar auch, aber nicht in einem für MySQL nutzbarem Rahmen.

Rechnet man nun die CPU-Last auf Server 2 (neuer Kernel) mal 8 (pro CPUKern), stellt man fest, dass das Ergebnis in etwa der Last des ersten CPU Kerns von Server 1 (alter Kernel) entspricht.

Fazit: in absehbarer Zeit wird Server 1 auf Debian/Lenny upgegraded.

Das Problem, das auftrat und, meiner Meinung nach, nur schlecht Dokumentiert ist, ist das Betreiben von mehreren, unabhängigen MySQL Instanzen auf einerm Server.

Das normale Datenverzeichnis “/var/lib/mysql” muss “aufgeteilt” werden, für jede Instanz, ein Unterverzeichnis: /var/lib/mysql/db1 – db5

Dasselbe geschiet mit den Konfigurationsverzeichnissen: /etc/mysql/db1 – db5

Das init.d Script /etc/init.d/mysql muss für jede Instanz einmal vorhanden sein (/etc/init.d/mysql_db1 – mysql_db5) und danach angepasst werden. Ich führe hier NUR die Änderungen auf, der Rest bleibt, wie er vorher schon war:

export HOME=/etc/mysql_db1

if [ ! -r /etc/mysql_db1/my.cnf ]; then
log_warning_msg “$0: WARNING: /etc/mysql_db1/my.cnf (…)”
echo “WARNING: /etc/mysql_db1/my.cnf cannot be read. (…)” | $ERR_LOGGER
fi

/usr/bin/mysqld_safe –log-bin=mysql-bin-db1.log –datadir=/var/lib/mysql/db1 –socket=/var/run/mysqld/mysqld_db1.sock –port=3307 > /dev/null 2>&1 &

output=$(/etc/mysql_db1/debian-start)

if [ -f /etc/mysql_db1/debian-log-rotate.conf ]; then
echo “/etc/mysql_db1/debian-log-rotate.conf is (..)” | $ERR_LOGGER -p daemon.info
fi

Nachteil hierbei ist, dass mysql nicht mehr über /etc/init.d/mysql_db1 stop zu stoppen ist. Der Prozess muss gekillt werden (kill [PID]), wodurch er runterfährt. Der Port muss für jede Instanz ein anderer sein.

In der my.cnf der jeweiligen Instanzen müssen noch alle Pfade, sowie Ports angepasst werden.

Will man sich mit der Konsole verbinden, muss ein zusätzlicher Parameter hinzugefügt werden.

mysql -uUSER -pPASS –socket=/var/run/mysql_db1.sock