https://dev.mysql.com /doc/refman/5.7/en/create-table-generated-columns.html
Es ist vernünftig, dass der Ausdruck für eine generierte Spalte nur referenzieren kann Spalten innerhalb derselben Zeile. Die generierte Spalte darf keine Unterabfragen verwenden oder auf andere Tabellen oder Funktionen mit nicht deterministischer Ausgabe verweisen.
Angenommen, generierte Spalten haben tabellenübergreifende Verweise unterstützt. Betrachten Sie insbesondere den Fall von STORED generierte Spalten.
Wenn Sie eine Tabelle aktualisieren, müsste MySQL auch alle Verweise in generierten Spalten an anderer Stelle in der Datenbank aktualisieren, wenn sie auf die von Ihnen aktualisierte Zeile verweisen. Es wäre komplex und teuer für MySQL, all diese Referenzen aufzuspüren.
Ziehen Sie dann in Betracht, indirekte Verweise über gespeicherte Funktionen hinzuzufügen.
Bedenken Sie dann, dass Ihre Aktualisierung eine InnoDB-Tabelle in einer Transaktion betrifft, die generierte Spalte sich jedoch möglicherweise in einer Nicht-Transaktionstabelle (MyISAM, MEMORY, ARCHIVE usw.) befindet. Sollte sich Ihre Aktualisierung in diesen generierten Spalten widerspiegeln, wenn Sie sie vornehmen? Was ist, wenn Sie zurückrollen? Soll Ihr Update zum Zeitpunkt der Festschreibung widergespiegelt werden? Wie sollte MySQL dann Änderungen "in die Warteschlange stellen", um sie auf diese Tabellen anzuwenden? Was passiert, wenn mehrere Transaktionen Aktualisierungen festschreiben, die sich auf die generierte Spaltenreferenz auswirken? Wer sollte gewinnen, derjenige, der die Änderung zuletzt angewendet hat, oder derjenige, der zuletzt festgeschrieben hat?
Aus diesen Gründen ist es nicht praktikabel oder effizient, generierten Spalten zu erlauben, auf etwas anderes als die Spalten derselben Zeile in derselben Tabelle zu verweisen.
