Lord Gurke
Nur echt mit 32 Zähnen
Hallo,
ich habe hier ein obskures Phänomen, dem ich irgendwie nicht hinterhergestiegen komme:
Es gibt eine Tabelle:
Wenn ich da nun z.B. Fotos aus einem Album abrufe, die nicht als gelöscht markiert sind:
Nun ist die Festplatte manchmal ein wenig träge und ich wollte der Geschwindigkeit wegen die Tabelle partitionieren:
Die gute Nachricht ist: Die Abfragen *SIND* danach in der Tat schneller.
Die schlechte Nachricht: Es werden auch nicht mehr alle Daten zurückgeliefert, obwohl sie weiterhin in der Tabelle enthalten sind:
Frage ich ohne "WHERE `Deleted` = 0" ab, erhalte ich scheinbar alle Datensätze zurück:
Man beachte z.B. die Datensatz-ID 553, die in der vorherigen Abfrage hätte auftauchen müssen!
Ich habe die Tabelle bereits geprüft, repariert, optimiert, mit einem NULL-Alter neu bauen lassen...
Angeblich ist die Tabelle und der Index fehlerfrei.
Jetzt frage ich mich: Was könnte ich noch tun, um die Tabelle zwar partitioniert zu lassen, aber wieder alle Datensätze zu erhalten?
Ich verwende die aktuellste MySQL-Version aus Debian 7 (heute Upgrade gemacht, das Problem bestand aber schon vorher):
Hat jemand eine Idee, was da schiefläuft?
Danke!
NACHTRAG:
Nach einem "REMOVE PARTITIONS" funktionieren die Abfragen wieder wie gehabt - die Daten scheinen tatsächlich nicht wirklich verloren zu gehen, MySQL unterschlägt sie mir bloß.
ich habe hier ein obskures Phänomen, dem ich irgendwie nicht hinterhergestiegen komme:
Es gibt eine Tabelle:
Code:
mysql> DESCRIBE `images`;
+----------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------------+--------------+------+-----+---------+----------------+
| ID | int(11) | NO | PRI | NULL | auto_increment |
| BaseName | varchar(128) | NO | MUL | NULL | |
| FileNameOnServer | varchar(96) | NO | MUL | NULL | |
| Width | int(11) | NO | | NULL | |
| Height | int(11) | NO | | NULL | |
| Photographer | varchar(255) | NO | MUL | NULL | |
| Album | int(11) | NO | MUL | NULL | |
| ShotDate | datetime | NO | MUL | NULL | |
| Deleted | tinyint(1) | NO | MUL | 0 | |
| MD5Hash | varchar(48) | YES | MUL | NULL | |
| EXIFData | blob | YES | | NULL | |
| BaseRight | int(11) | NO | | 0 | |
| OwnerID | int(11) | YES | MUL | NULL | |
| OrderPrio | int(11) | NO | MUL | 1 | |
| OrigFileDownloadable | tinyint(1) | NO | | 1 | |
| ThumbOnS3 | tinyint(1) | NO | | 0 | |
| MidsizeOnS3 | tinyint(1) | NO | | 0 | |
| OriginalOnS3 | tinyint(1) | NO | | 0 | |
+----------------------+--------------+------+-----+---------+----------------+
18 rows in set (0.03 sec)
mysql> SHOW TABLE STATUS LIKE "images" \G
*************************** 1. row ***************************
Name: images
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 5480
Avg_row_length: 46213
Data_length: 253247488
Max_data_length: 0
Index_length: 3407872
Data_free: 6291456
Auto_increment: 6028
Create_time: 2014-06-15 19:47:19
Update_time: NULL
Check_time: NULL
Collation: latin1_swedish_ci
Checksum: NULL
Create_options: pack_keys=1 delay_key_write=1
Comment:
1 row in set (0.00 sec)
Code:
mysql> SELECT `ID`, `BaseName`, `Deleted` FROM `images` WHERE `Album` = 1 AND `Deleted` = 0 ORDER BY `ID` ASC;
+-----+--------------+---------+
| ID | BaseName | Deleted |
+-----+--------------+---------+
| 214 | DSCF0960.JPG | 0 |
| 215 | DSCF0741.JPG | 0 |
| 216 | DSCF0936.JPG | 0 |
| 217 | DSCF0894.JPG | 0 |
| 218 | DSCF0873.JPG | 0 |
| 220 | DSCF0857.JPG | 0 |
| 222 | DSCF0867.JPG | 0 |
| 223 | DSCF0716.JPG | 0 |
| 224 | DSCF0667.JPG | 0 |
| 225 | DSCF0820.JPG | 0 |
| 226 | DSCF0791.JPG | 0 |
| 227 | DSCF0889.JPG | 0 |
| 228 | DSCF0817.JPG | 0 |
| 229 | DSCF0781.JPG | 0 |
| 230 | DSCF0750.JPG | 0 |
| 231 | DSCF0923.JPG | 0 |
| 232 | DSCF0743.JPG | 0 |
| 233 | DSCF0992.JPG | 0 |
| 234 | DSCF0948.JPG | 0 |
| 235 | DSCF0865.JPG | 0 |
| 236 | DSCF0828.JPG | 0 |
| 238 | DSCF0710.JPG | 0 |
........
| 552 | DSC_1324.JPG | 0 |
| 553 | DSC_1339.JPG | 0 |
| 554 | DSC_1334.JPG | 0 |
| 555 | DSC_1338.JPG | 0 |
+-----+--------------+---------+
291 rows in set (0.00 sec)
Code:
mysql> ALTER TABLE `images` PARTITION BY HASH(`ID`) PARTITIONS 6;Die schlechte Nachricht: Es werden auch nicht mehr alle Daten zurückgeliefert, obwohl sie weiterhin in der Tabelle enthalten sind:
Code:
mysql> SELECT `ID`, `BaseName`, `Deleted` FROM `images` WHERE `Album` = 1 AND `Deleted` = 0 ORDER BY `ID` ASC;
+-----+--------------+---------+
| ID | BaseName | Deleted |
+-----+--------------+---------+
| 216 | DSCF0936.JPG | 0 |
| 222 | DSCF0867.JPG | 0 |
| 228 | DSCF0817.JPG | 0 |
| 234 | DSCF0948.JPG | 0 |
| 240 | DSCF0701.JPG | 0 |
| 246 | DSCF0664.JPG | 0 |
| 252 | DSCF0886.JPG | 0 |
| 264 | DSCF0816.JPG | 0 |
| 270 | DSCF0840.JPG | 0 |
| 282 | DSCF0660.JPG | 0 |
| 288 | DSCF0930.JPG | 0 |
| 294 | DSCF0775.JPG | 0 |
| 300 | DSCF0774.JPG | 0 |
| 306 | DSCF0917.JPG | 0 |
| 312 | DSCF0808.JPG | 0 |
| 318 | DSCF0915.JPG | 0 |
| 324 | DSCF0993.JPG | 0 |
| 342 | DSCF0715.JPG | 0 |
| 348 | DSCF0778.JPG | 0 |
| 354 | DSCF0961.JPG | 0 |
| 360 | DSCF0928.JPG | 0 |
| 366 | DSCF0809.JPG | 0 |
| 372 | DSCF0962.JPG | 0 |
| 378 | DSCF0679.JPG | 0 |
| 384 | DSCF0671.JPG | 0 |
| 396 | DSCF0659.JPG | 0 |
| 402 | DSCF0702.JPG | 0 |
| 408 | DSCF0698.JPG | 0 |
| 414 | DSCF0988.JPG | 0 |
| 426 | DSCF0929.JPG | 0 |
| 432 | DSCF0951.JPG | 0 |
| 444 | DSCF0866.JPG | 0 |
| 450 | DSCF0784.JPG | 0 |
| 456 | DSCF0677.JPG | 0 |
| 462 | DSCF0692.JPG | 0 |
| 468 | DSCF0682.JPG | 0 |
| 474 | DSCF0906.JPG | 0 |
| 480 | DSCF0685.JPG | 0 |
| 492 | DSCF0834.JPG | 0 |
| 498 | DSCF0680.JPG | 0 |
| 504 | DSCF0877.JPG | 0 |
| 510 | DSCF0711.JPG | 0 |
| 522 | DSCF0831.JPG | 0 |
| 528 | DSCF0844.JPG | 0 |
| 534 | DSC_1329.JPG | 0 |
| 540 | DSC_1318.JPG | 0 |
| 546 | DSC_1328.JPG | 0 |
| 552 | DSC_1324.JPG | 0 |
+-----+--------------+---------+
48 rows in set (0.01 sec)
Code:
mysql> SELECT `ID`, `BaseName`, `Deleted` FROM `images` WHERE `Album` = 1 ORDER BY `ID` ASC;
+-----+--------------+---------+
| ID | BaseName | Deleted |
+-----+--------------+---------+
| 74 | DSCF0979.JPG | 1 |
| 75 | DSCF0960.JPG | 1 |
| 76 | DSCF0741.JPG | 1 |
| 77 | DSCF0936.JPG | 1 |
| 78 | DSCF0894.JPG | 1 |
| 79 | DSCF0873.JPG | 1 |
| 80 | DSCF0697.JPG | 1 |
| 81 | DSCF0857.JPG | 1 |
| 82 | DSCF0830.JPG | 1 |
| 83 | DSCF0867.JPG | 1 |
| 84 | DSCF0716.JPG | 1 |
| 85 | DSCF0667.JPG | 1 |
| 86 | DSCF0820.JPG | 1 |
| 87 | DSCF0791.JPG | 1 |
| 88 | DSCF0889.JPG | 1 |
......
| 548 | DSC_1326.JPG | 0 |
| 549 | DSC_1335.JPG | 0 |
| 550 | DSC_1327.JPG | 0 |
| 551 | DSC_1323.JPG | 0 |
| 552 | DSC_1324.JPG | 0 |
| 553 | DSC_1339.JPG | 0 |
| 554 | DSC_1334.JPG | 0 |
| 555 | DSC_1338.JPG | 0 |
+-----+--------------+---------+
482 rows in set (0.00 sec)Ich habe die Tabelle bereits geprüft, repariert, optimiert, mit einem NULL-Alter neu bauen lassen...
Angeblich ist die Tabelle und der Index fehlerfrei.
Jetzt frage ich mich: Was könnte ich noch tun, um die Tabelle zwar partitioniert zu lassen, aber wieder alle Datensätze zu erhalten?
Ich verwende die aktuellste MySQL-Version aus Debian 7 (heute Upgrade gemacht, das Problem bestand aber schon vorher):
Code:
mysql> SHOW VARIABLES LIKE "%version%";
+-------------------------+----------------------+
| Variable_name | Value |
+-------------------------+----------------------+
| innodb_version | 5.5.37 |
| protocol_version | 10 |
| slave_type_conversions | |
| version | 5.5.37-0+wheezy1-log |
| version_comment | (Debian) |
| version_compile_machine | x86_64 |
| version_compile_os | debian-linux-gnu |
+-------------------------+----------------------+
7 rows in set (0.02 sec)Danke!
NACHTRAG:
Nach einem "REMOVE PARTITIONS" funktionieren die Abfragen wieder wie gehabt - die Daten scheinen tatsächlich nicht wirklich verloren zu gehen, MySQL unterschlägt sie mir bloß.
Last edited by a moderator: