MySQL Performance Messung verwirrend

[toom]

Ich versuche zur Zeit herauszufinden, wie ich die Leistung von meiner MySQL DB steigern kann. Ich habe eine Webapp programmiert die auf Hibernate/MySQL basiert. Als storage engine verwende ich MyISAM. Um zu überprüfen, wie gut oder auch schlecht meine Tabellen sind, habe ich ein kleines Testprogramm geschrieben. Ich habe ein Tabelle "Owner" die im wesentlichen meine Benutzer darstellen. Wenn ein Nutzer sich anmelden möchte, dann muss er seine E-Mail Adresse eingeben und ein Passwort. Die Abfrage in der DB sieht dann ungefähr so aus:

select * form owners where email = 'email@example.com';

Ich habe zwei Testszenarien.
1. Die Tabelle komplett ohne Indizes, außer dem Primär Schlüssel (long Zahl)
2. Die Tabelle wobei die Spalte email indiziert ist.

Nun habe ich ein Testprogramm geschrieben, das grob folgendes macht:

1. Erstelle 10000 test Owners identifiziert durch emails '100000@example.com' bis '109999@example.com'
2. Führe 10000 select queries auf der Tabelle aus indem zufällige E-Mail Adressen im Bereich von '100000@example.com' bis '109999@example.com' zufällig erzeugt werden.
3. Messe die Zeit.
4. Wiederhole diesen Vorgang indem wieder 10000 neue Owners hinzugefügt werden und führe wieder 10000 Abfragen durch auf 20000 Ownern.

Führe Schritt 1-4 aus bis 100000 Owner erstellt wurden.

Ergebnis
Im Falle ohne Index (Fall A) sieht das Resultat so aus:
10000 queries, 8.07 secs, 10000 owners
10000 queries, 7.66 secs, 20000 owners
10000 queries, 7.784 secs, 30000 owners
10000 queries, 7.664 secs, 40000 owners
10000 queries, 7.792 secs, 50000 owners
10000 queries, 7.682 secs, 60000 owners
10000 queries, 7.726 secs, 70000 owners
10000 queries, 7.742 secs, 80000 owners
10000 queries, 7.687 secs, 90000 owners
10000 queries, 7.678 secs, 100000 owners

Und im Falle mit einem Index auf der Spalte email (Fall B) sieht es so aus:

10000 queries, 8.52 secs, 10000 owners
10000 queries, 8.647 secs, 20000 owners
10000 queries, 7.762 secs, 30000 owners
10000 queries, 7.896 secs, 40000 owners
10000 queries, 7.715 secs, 50000 owners
10000 queries, 7.663 secs, 60000 owners
10000 queries, 7.789 secs, 70000 owners
10000 queries, 7.817 secs, 80000 owners
10000 queries, 7.723 secs, 90000 owners
10000 queries, 7.712 secs, 100000 owners


Mich wundern hier gleich zwei Sachen:
Erstens:
In der MySQL Doku steht:
"Without an index, MySQL must begin with the first row and then read through the entire table to find the relevant rows. The larger the table, the more this costs. "
MySQL :: MySQL 5.1 Reference Manual :: 7.2.3 Speed of SELECT Queries

Nun, meine Tabelle benutzt keine Indizes in Fall A und trotzdem konstant, was die Geschwindigkeit angeht. Eigentlich erwarte ich, dass bei 20000 Owner die Abfragen doppelt so lange dauern sollten wie im Falle von 10000 Ownern.

Zweitens:
Offensichtlich hat der Index überhaupt keine Einfluss auf die Leistungsfähigkeit. Wie ist das zu erklären?

 

[Roger Wilco]

Sind die Datensätze klein genug, damit sie allesamt in den Speicher passen? Hast du den Query Cache (de)aktiviert? Wie sieht das konkrete Schema der Tabelle aus?

 

[toom]

Hi, das Schema sieht so aus

+------------------+--------------+------+-----+---------+----------------+
| Field            | Type         | Null | Key | Default | Extra          |
+------------------+--------------+------+-----+---------+----------------+
| id               | bigint(20)   | NO   | PRI | NULL    | auto_increment | 
| accountNumber    | varchar(255) | NO   |     | NULL    |                | 
| accountOwner     | varchar(255) | NO   |     | NULL    |                | 
| address          | varchar(255) | NO   |     | NULL    |                | 
| addressAddOn     | varchar(255) | YES  |     | NULL    |                | 
| bankName         | varchar(255) | NO   |     | NULL    |                | 
| bankNumber       | varchar(255) | NO   |     | NULL    |                | 
| city             | varchar(255) | NO   |     | NULL    |                | 
| company          | bit(1)       | NO   |     | NULL    |                | 
| cookie           | varchar(255) | YES  |     | NULL    |                | 
| credit           | double       | NO   |     | NULL    |                | 
| eMail            | varchar(255) | NO   | UNI | NULL    |                | 
| houseNumber      | int(11)      | NO   |     | NULL    |                | 
| name             | varchar(255) | NO   |     | NULL    |                | 
| password         | varchar(255) | NO   |     | NULL    |                | 
| phone            | varchar(255) | NO   |     | NULL    |                | 
| registrationDate | datetime     | NO   |     | NULL    |                | 
| surname          | varchar(255) | NO   |     | NULL    |                | 
| zipcode          | varchar(255) | NO   |     | NULL    |                | 
+------------------+--------------+------+-----+---------+----------------+

MOD: Bitte [noparse]

...

[/noparse]-Tags um Ausgaben, Code, etc. verwenden (im Editor auch mit '#' erreichbar). Danke!

In meiner Testdatenbank ist bisher nur diese Tabelle enthalten. Ich weiss nicht ob ich überhaupt irgendeinen Cache aktiviert oder deaktiviert habe. Wo kann ich das nachschauen?

 

[Roger Wilco]

+------------------+--------------+------+-----+---------+----------------+
| Field            | Type         | Null | Key | Default | Extra          |
+------------------+--------------+------+-----+---------+----------------+
| eMail            | varchar(255) | NO   | UNI | NULL    |                | 
+------------------+--------------+------+-----+---------+----------------+

Die Spalte `eMail` ist UNIQUE, d. h. auf ihr ist implizit ein Index gesetzt. Damit hast du bei deinem Benchmark zweimal die gleiche indizierte Spalte abgefragt.

 

[toom]

Danke für die Infos.