Schwerwiegender Fehler: Maximale Ausführungszeit von 30 Sekunden in… \ model.php in Zeile 183 überschritten

Ich bin auf einem lokalen Rechner. Ich erhalte diesen Fehler nur beim erstmaligen Laden der Seite nach einem | Einfügen | Löschen. Dann wird es sehr schnell geladen. Wenn ich die Datenbank dann erneut ändere, erhalte ich beim ersten Mal (manchmal beim zweiten Mal) beim Zugriff auf die Seite diesen Fehler. Ich verstehe es nicht.

Warum erhalte ich diesen Fehler nur beim ersten Zugriff auf die Site nach dem Ändern der Datenbank?

$sth = $this->dbh->prepare("SELECT g.t_tree_c_parent AS gp ,h.t_tree_c_parent AS hp
                FROM t_tree a INNER JOIN (t_data b, t_data c, t_tree d, t_data e, t_data f, t_tree g, t_tree h, t_tree i) 
                ON a.t_tree_c_child=b.t_data_c_space
                AND b.t_data_c_object=c.t_data_c_object
                AND c.t_data_c_space=d.t_tree_c_child
                AND d.t_tree_c_parent=e.t_data_c_object
                AND e.t_data_c_space=f.t_data_c_object
                AND f.t_data_c_space=g.t_tree_c_child
                AND g.t_tree_c_parent=h.t_tree_c_child
                AND e.t_data_c_space=i.t_tree_c_child
                AND i.t_tree_c_parent=?
                WHERE a.t_tree_c_child=?");
$sth->execute(array($this->glob['children'], $child)); //  <- LINE:183

Ich werde diese Abfrage aufteilen, um sie zu testen. Aber ich frage, vielleicht fehlt mir etwas.

UPDATE von @ jcho360 gefragt:

CREATE TABLE `t_data` (
`t_data_c_space` VARCHAR(50) NOT NULL DEFAULT '0.00000000000',
`t_data_c_object` VARCHAR(50) NULL DEFAULT NULL,
`t_data_c_timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`t_data_c_space`)
 )
COLLATE='utf8_general_ci'
ENGINE=InnoDB;

CREATE TABLE `t_tree` (
`t_tree_c_parent` VARCHAR(50) NOT NULL,
`t_tree_c_child` VARCHAR(50) NOT NULL,
`t_tree_c_timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB;

In HeidiSQL für ein Kind (im Projekt befindet sich diese Abfrage in einer rekursiven Funktion):

2.137 sec das erste mal nach einem kleinen update in db dann 0,000 sec

Ich fange an zu glauben, dass dies das von Leandro Barreto vorgeschlagene Caching von MySQL ist.

Antworten auf die Frage(1)

Ihre Antwort auf die Frage