14.7.1. Description of the FEDERATED Storage Engine
When you create a FEDERATED table, the server
creates a table format file in the database directory. The file
begins with the table name and has an .frm
extension. No other files are created, because the actual data
is in a remote table. This differs from the way that storage
engines for local tables work.
For local database tables, data files are local. For example, if
you create a MyISAM table named
users, the MyISAM handler
creates a data file named users.MYD. A
handler for local tables reads, inserts, deletes, and updates
data in local data files, and rows are stored in a format
particular to the handler. To read rows, the handler must parse
data into columns. To write rows, column values must be
converted to the row format used by the handler and written to
the local data file.
With the MySQL FEDERATED storage engine,
there are no local data files for a table (for example, there is
no .MYD file). Instead, a remote database
stores the data that normally would be in the table. The local
server connects to a remote server, and uses the MySQL client
API to read, delete, update, and insert data in the remote
table. Data retrieval is initiated via a SELECT * FROM
tbl_name SQL statement. To
read the result, rows are fetched one at a time by using the
mysql_fetch_row() C API function, and then
converting the columns in the SELECT result
set to the format that the FEDERATED handler
expects.
The flow of information is as follows:
SQL calls issued locally
MySQL handler API (data in handler format)
MySQL client API (data converted to SQL calls)
Remote database -> MySQL client API
Convert result sets (if any) to handler format
Handler API -> Result rows or rows-affected count to
local
