MySQL Langsame Abfrage Lock_time = Jahre?

Question

Ich habe eine Menge von langsamen Abfrage-Logs gesehen, aber noch nie einen so: Warten mehr als 500.000 Jahre für eine Sperre

/usr/sbin/mysqld, Version: 5.1.46-log (SUSE MySQL RPM). started with: 
    Tcp port: 3306 Unix socket: /var/run/mysql/mysql.sock 
    Time     Id Command Argument 
    # Time: 160627 9:10:05 
    # User@Host: sysop[sysop] @ [127.0.0.1] 
    # Query_time: 3.768728 Lock_time: 0.034402 Rows_sent: 734 Rows_examined: 734 
    use asterisk; 
    SET timestamp=1467033005; 
    select PostID, lead_id, list_id from vdlist_temp where Posted is null; 
    # Time: 160627 10:35:11 
    # User@Host: sysop[sysop] @ [192.168.0.248] 
    # Query_time: 35.563521 Lock_time: 0.000054 Rows_sent: 1222017 Rows_examined: 2444034 
    SET timestamp=1467038111; 
    SELECT `vicidial_list`.`lead_id`, `vicidial_list`.`source_id` FROM `vicidial_list` ORDER BY `vicidial_list`.`source_id`; 
    # User@Host: sysop[sysop] @ [127.0.0.1] 
    # Query_time: 0.000095 Lock_time: 18446744073699.406250 Rows_sent: 2 Rows_examined: 1 
    SET timestamp=1467038111; 
    call spUpdate_VDList_from_temp(0, 0, 1324903); 
    # Time: 160627 10:35:12 
    # User@Host: sysop[sysop] @ [127.0.0.1] 
    # Query_time: 0.000055 Lock_time: 18446744073699.359375 Rows_sent: 0 Rows_examined: 0 
    SET timestamp=1467038112; 
    call spMoveXDrop(10376163); 
    # Time: 160627 11:26:14 
    # User@Host: sysop[sysop] @ [127.0.0.1] 
    # Query_time: 0.000057 Lock_time: 18446744073697.218750 Rows_sent: 3 Rows_examined: 0 
    SET timestamp=1467041174; 
    call spUpdate_VDList_from_temp(10795520, 616062301, 1955758); 

Dies scheint, ich habe Anfragen zu zeigen. (Ich habe die gespeicherte Prozedur geschrieben und ich bin nicht ganz so alt!) Irgendwie finde ich das nicht richtig. Dies sind alle MyISAM-Tabellen. (Nicht meine Wahl.) Ich machte eine mysqldump und Wiederherstellung der Datenbank, Neustart des Servers und ich sehe immer noch Sperrzeiten wie folgt.

Kann mir jemand einen Anhaltspunkt geben, wo ich nach dem Problem suchen kann? (Server Zeiten sind alle gut.)

EDIT: Diese MySql Version: 5.1.46-Protokoll, die mit einem OpenSource-Projekt Vicidial kommt. Es scheint klar zu sein, dass Lock_time ein Bug ist. Problem ist, dass ich das langsame Abfrageprotokoll ansehe, um Benutzerbeschwerden der langsamen Webserverantwort aufzuspüren. Ich hatte gehofft, dass jemand wissen würde, was diesen Fehler auslöst, um mir zu helfen, das tatsächliche Problem zu lokalisieren. Wie Sie aus dem Protokoll sehen können, haben die meisten langsamen Abfragen Lock_times. Sowohl gespeicherte Prozeduren als auch PHP-generierte Abfragen erzeugen die wahnsinnige Lock_time. Das einzige, was ich gemeinsam sehe, ist, dass sie alle aus der Tabelle vicidial_list auswählen oder aktualisieren. Ich ließ den Tisch fallen, ließ ihn fallen und baute ihn ohne Erfolg wieder auf.

Answer 1

Manchmal scheint die Uhr rückwärts zu laufen. Dies ist seit mehr als einem Jahrzehnt ein Problem. Es scheint harmlos zu sein. Ignoriere es als falschen Wert.

Beachten Sie, dass wenn ein -1 in einem BIGINT UNSIGNED gespeichert wird, Sie einen Wert sehr ähnlich dem 18446744073699.406250 erhalten, den Sie sehen.

Answer 2

Diese Abfragen sind nicht Bestandteil des VICIdial-Bestands, daher kann ich eine Abfrageoptimierung für die benutzerdefinierten Abfragen vorschlagen, die Sie ausführen möchten. In neueren Versionen unseres VICIbox-ISO-Installationsprogramms verwenden wir MariaDB und eine viel neuere Version, die viele Fehlerbehebungen und Optimierungen im Vergleich zur älteren Version von MySQL, die Sie verwenden, enthält.