fileformat.html

sqlite3源码,适合作为嵌入式（embedded）

        <tr><td>20     <td>1<td>
            Number of bytes of unused space at the end of each database
            page. Usually this field is set to 0. If it is non-zero, then 
            it contains the number of bytes that are left unused at the
            end of every database page (see section
            <cite>pages_and_page_types</cite> for a description of a
            database page).

        <tr><td>21     <td>1<td>
             Maximum fraction of an index tree page to use for 
            embedded content. This value is used to determine the maximum
            size of a B-Tree cell to store as embedded content on a
            page that is part of an index B-Tree. Refer to section 
            <cite>index_btree_cell_format</cite> for details.

        <tr><td>22     <td>1<td>
            Minimum fraction of an index B-Tree page to use for
            embedded content when an entry uses one or more overflow pages.
            This value is used to determine the portion of a B-Tree cell 
            that requires one or more overflow pages to store as embedded
            content on a page that is part of an index B-Tree. Refer to
            section <cite>index_btree_cell_format</cite> for details.

        <tr><td>23     <td>1<td>
            Minimum fraction of an table B-Tree leaf page to use for
            embedded content when an entry uses one or more overflow pages.
            This value is used to determine the portion of a B-Tree cell 
            that requires one or more overflow pages to store as embedded
            content on a page that is a leaf of a table B-Tree. Refer to
            section <cite>table_btree_cell_format</cite> for details.

        <tr><td>24..27 <td>4<td>
            <p style="margin-top:0">
            The file change counter. Each time a database transaction is
            committed, the value of the 32-bit unsigned integer stored in
            this field is incremented.
            <p style="margin-bottom:0">
            SQLite uses this field to test the validity of its internal
            cache. After unlocking the database file, SQLite may retain
            a portion of the file cached in memory. However, since the file
            is unlocked, another process may use SQLite to modify the 
            contents of the file, invalidating the internal cache of the
            first process. When the file is relocked, the first process can
            check if the value of the file change counter has been modified
            since the file was unlocked. If it has not, then the internal
            cache may be assumed to be valid and may be reused.

        <tr><td>32..35 <td>4<td>
            Page number of first freelist trunk page. 
            For more details, refer to section <cite>free_page_list</cite>.

        <tr><td>36..39 <td>4<td>
            Number of free pages in the database file.
            For more details, refer to section <cite>free_page_list</cite>.

        <tr><td>40..43 <td>4<td>
            The schema version. Each time the database schema is modified (by
            creating or deleting a database table, index, trigger or view)
            the value of the 32-bit unsigned integer stored in this field
            is incremented.

        <tr><td>44..47 <td>4<td>
            <p style="margin-top:0">
	    Schema layer file-format. This value is similar to the
            "read-version" and "write-version" fields at offsets 18 and 19
            of the database file header. If SQLite encounters a database
            with a schema layer file-format value greater than the file-format
            that it understands (currently 4), then SQLite will refuse to
            access the database.
            <p>
            Usually, this value is set to 1. However, if any of the following
            file-format features are used, then the schema layer file-format
            must be set to the corresponding value or greater:
            <ol start=2 style="margin-bottom:0">
              <li> Implicit NULL values at the end of table records 
                   (see section <cite>table_btree_content</cite>).
	      <li> Implicit default (non-NULL) values at the end of table
                   records (see section <cite>table_btree_content</cite>).
	      <li> Descending indexes (see section
                   <cite>index_btree_compare_func</cite>) and Boolean values
		   in database records (see section <cite>record_format</cite>,
                   serial types 8 and 9).
            </ol>
            

        <tr><td>48..51 <td>4<td>
            Default pager cache size. This field is used by SQLite to store
            the recommended pager cache size to use for the database.

        <tr><td>52..55 <td>4<td>
            For auto-vacuum capable databases, the numerically largest 
            root-page number in the database. Since page 1 is always the
	    root-page of the schema table (section <cite>schema_table</cite>),
            this value is always non-zero for auto-vacuum databases. For
            non-auto-vacuum databases, this value is always zero.

        <tr><td>56..59 <td>4<td>
            (constant) Database text encoding. A value of 1 means all 
            text values are stored using UTF-8 encoding. 2 indicates
            little-endian UTF-16 text. A value of 3 means that the database
            contains big-endian UTF-16 text.  

        <tr><td>60..63 <td>4<td>
            The user-cookie value. A 32-bit integer value available to the
            user for read/write access.

        <tr><td>64..67 <td>4<td>
            The incremental-vacuum flag. In non-auto-vacuum databases this
            value is always zero. In auto-vacuum databases, this field is
            set to 1 if "incremental vacuum" mode is enabled. If incremental
            vacuum mode is not enabled, then the database file is reorganized
            so that it contains no free pages (section
            <cite>free_page_list</cite>) at the end of each database
            transaction. If incremental vacuum mode is enabled, then the
            reorganization is not performed until explicitly requested
            by the user.

      </table>
      <p>
        The four byte block beginning at offset 28 is unused. As is the
        32 byte block beginning at offset 68.
      </p>

      <p>
	Some of the following requirements state that certain database header
        fields must contain defined constant values, even though the sqlite 
        database file format is designed to allow various values. This is
        done to artificially constrain the definition of a 
        <i>well-formed database</i> in order to make implementation and 
        testing more practical.

      <p class=req id=H30030>
          The first 16 bytes of a well-formed database file contain the UTF-8
encoding of the string "SQLite format 3" followed by a single
nul-terminator byte.

      <p>
        Following the 16 byte magic string in the file header is the
	<i>page size</i>, a 2-byte field. See section
        <cite>pages_and_page_types</cite> for details.

      <p class=req id=H30040>
          The 19th byte (byte offset 18), the <i>file-format write version</i>,
of a well-formed database file contains the value 0x01.
      <p class=req id=H30050>
          The 20th byte (byte offset 19), the <i>file-format read version</i>,
of a well-formed database file contains the value 0x01.

      <p class=req id=H30060>
          The 21st byte (byte offset 20), the number of unused bytes on each
page, of a well-formed database file shall contain the value 0x00.

      <p class=req id=H30070>
          The 22nd byte (byte offset 21), the maximum fraction of an index
B-Tree page to use for embedded content, of a well-formed database
file shall contain the value 0x40.
      <p class=req id=H30080>
          The 23rd byte (byte offset 22), the minimum fraction of an index
B-Tree page to use for embedded content when using overflow pages,
of a well-formed database file contains the value 0x20.
      <p class=req id=H30090>
          The 24th byte (byte offset 23), the minimum fraction of a table
B-Tree page to use for embedded content when using overflow pages,
of a well-formed database file contains the value 0x20.
      <p class=req id=H30100>
          The 4 byte block starting at byte offset 24 of a well-formed
database file contains the <i>file change counter</i> formatted
as a 4-byte big-endian integer.

      <p>
        Following the <i>file change counter</i> in the database header are
        two 4-byte fields related to the database file <i>free page list</i>.
        See section <cite>free_page_list</cite> for details.

      <p class=req id=H30110>
          The 4 byte block starting at byte offset 40 of a well-formed
database file contains the <i>schema version</i> formatted
as a 4-byte big-endian integer.

      <p class=req id=H30120>
          The 4 byte block starting at byte offset 44 of a well-formed
database file, the <i>schema layer file format</i>, contains a
big-endian integer value between 1 and 4, inclusive.

      <p class=req id=H30130>
          The 4 byte block starting at byte offset 48 of a well-formed
database file contains the <i>default pager cache size</i> formatted
as a 4-byte big-endian integer.

      <p class=req id=H30140>
          The 4 byte block starting at byte offset 52 of a well-formed
database file contains the <i>auto-vacuum last root-page</i>
formatted as a 4-byte big-endian integer. If this value is non-zero,
the database is said to be an <i>auto-vacuum database</i>.

      <p class=req id=H30150>
          The 4 byte block starting at byte offset 56 of a well-formed
database file, the <i>text encoding</i> contains a big-endian integer
value between 1 and 3, inclusive.

      <p class=req id=H30160>
          The 4 byte block starting at byte offset 60 of a well-formed
database file contains the <i>user cookie</i> formatted
as a 4-byte big-endian integer.

      <p class=req id=H30170>
          The 4 byte block starting at byte offset 64 of a well-formed
database file, the <i>incremental vaccum flag</i> contains a big-endian
integer value between 0 and 1, inclusive.

      <p class=req id=H30180>
          In a well-formed non-autovacuum database (one with a zero stored
in the 4-byte big-endian integer value beginning at byte offset
52 of the database file header, the incremental vacuum flag is
set to 0.

    <h3 id="pages_and_page_types">Pages and Page Types</h3>
      <p>
        The entire database file is divided into pages, each page consisting
        of <i>page-size</i> bytes, where <i>page-size</i> is the 2-byte 
        integer value stored at offset 16 of the file header (see above).
        The <i>page-size</i> is always a power of two between 512 
        (2<sup>9</sup>) and 32768 (2<sup>15</sup>). SQLite database files
        always consist of an exact number of pages.
      <p>
        Pages are numbered beginning from 1, not 0. Page 1 consists of
        the first <i>page-size</i> bytes of the database file. The file header
        described in the previous section consumes the first 100 bytes of page
        1.
      <p>
        Each page of the database file is one of the following:
      <ul>
        <li><b>A B-Tree page</b>. B-Tree pages are part of the tree 
            structures used to store database tables and indexes.
        <li><b>An overflow page</b>. Overflow pages are used by particularly
            large database records that do not fit on a single B-Tree page.
        <li><b>A free page</b>. Free pages are pages within the database file
            that are not being used to store meaningful data.
        <li><b>A "pointer-map" page</b>. In auto-vacuum capable databases
            (databases for which the 4 byte big-endian integer stored at
            byte offset 52 of the file header is non-zero) some pages are
            permanently designated "pointer-map" pages. See section 
            <cite>pointer_map_pages</cite> for details.
        <li><b>The locking page</b>. The database page that starts at
            byte offset 2<sup>30</sup>, if it is large enough to contain
            such a page, is always left unused.
      </ul>

      <p class=req id=H30190>
          The <i>database page size</i> of a well-formed database, stored as a
2-byte big-endian unsigned integer at byte offset 16 of the file,
shall be an integer power of 2 between 512 and 32768, inclusive.
      <p class=req id=H30200>
          The size of a <i>well formed database file</i> shall be an integer
multiple of the <i>database page size</i>.
      <p class=req id=H30210>
          Each page of a <i>well formed database file</i> is exactly one of a
<i>B-Tree page</i>, an <i>overflow page</i>, a <i>free page</i>, a
<i>pointer-map page</i> or the <i>locking page</i>.
      <p class=req id=H30220>
          The database page that starts at byte offset 2<sup>30</sup>, the
<i>locking page</i>, is never used for any purpose.
        

    <h3 id=schema_table>The Schema Table</h3>
      <p>
        Apart from being the page that contains the file-header, page 1 of
        the database file is special because it is the root page of the
        B-Tree structure that contains the schema table data. From the SQL
        level, the schema table is accessible via the name "sqlite_master".
      <p>
        The exact format of the B-Tree structure and the meaning of the term
        "root page" is discussed in section <cite>btree_structures</cite>.