Ich habe eine Klasse, die als PHP-Gegenstück eine MySQL-Tabelle dienen soll.

Vorsicht, sowas bringt normalerweise Pech.

Du scheinst aus Erfahrung zu sprechen. Was für Pech denn?

Ja, ich muss das ein wenig relativieren. Was Du machen kannst ist selbstverstaendlich den ¨"kruden" Datenzugriff CRUDL in geeignete Module bzw. Klassen packen, also erst einmal abstrakt ein Objekt hochkommen lassen und erst dann mit einem Create bzw. INSERT oder einem Read bzw. SELECT oder einem Update bzw. einem UPDATE oder einem Delete bzw. DELETE kommen. Dann haettest Du "das SQL" im Klassenmodul, das waere OK. Allerdings Vorsicht mit unnoetigem Datenzugriff per SQL!
Wenn Du aber mit Stored Procedures arbeitest, die bereits den CRUD-Datenzugriff bereitstellen, dann empfehle ich den Verzicht auf den Datenzugriff irgendwie nachbauende Objekte.
Wovon ich auch abrate ist ein sich Aufbauen der Datenzugriffsobjekte zur Laufzeit, bspw. mithilfe von Schemaabfragen und anschliessender automatisierter Erstellung des CRUD-Datenzugriffs.
Anmerkung: CRUD ist heutzutage natuerlich eher CRUDL + Analyseabfragen.

Sinn soll sein, dass bei einer Änderung der Datenbank nicht allzuviel am Quellcode an den SQL-Anweisungen geändert werden muss.

Genau das geht eigentlich nicht, wenn Du alles doppelt moppelst, d.h. Du erzeugst Abhaengigkeiten.

Meinst Du mit Abhängigkeiten, dass ich, wenn ich der Tabelle ein Feld hinzufüge, auch meine Klasse entsprechend ergänzen muss? Aber in diesem Fall muss ich doch sowieso Änderungen im Code vornehmen.

Wenn Du - wie zuerst beschrieben - vorgehst, dann muesste das OK sein.

Wie lange bleibt denn ein Objekt erhalten und damit dessen Datenbankverbindung? Wenn ich die Variable mit unset() zerstöre, dann ist doch auch das Objekt weg, oder?

Warum laesst Du nicht anfaenglich ein selbstgebautes Verbindungsobjekt hochkommen oder nimmst das Angebotene?

Ich habe schon genug Anwendungen gesehen, die zuviele Verbindungen aufbauen. Ich sehe auch keinen Grund jerweils eine Datenverbindung in einem der den Tabellen nachgebildetetn Klassen auf- und ggf. abzubauen.