333 lines
		
	
	
		
			15 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
			
		
		
	
	
			333 lines
		
	
	
		
			15 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
| <!DOCTYPE html>
 | |
| <html><head>
 | |
| <meta name="viewport" content="width=device-width, initial-scale=1.0">
 | |
| <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 | |
| <link href="sqlite.css" rel="stylesheet">
 | |
| <title>Architecture of SQLite</title>
 | |
| <!-- path= -->
 | |
| </head>
 | |
| <body>
 | |
| <div class=nosearch>
 | |
| <a href="index.html">
 | |
| <img class="logo" src="images/sqlite370_banner.gif" alt="SQLite" border="0">
 | |
| </a>
 | |
| <div><!-- IE hack to prevent disappearing logo --></div>
 | |
| <div class="tagline desktoponly">
 | |
| Small. Fast. Reliable.<br>Choose any three.
 | |
| </div>
 | |
| <div class="menu mainmenu">
 | |
| <ul>
 | |
| <li><a href="index.html">Home</a>
 | |
| <li class='mobileonly'><a href="javascript:void(0)" onclick='toggle_div("submenu")'>Menu</a>
 | |
| <li class='wideonly'><a href='about.html'>About</a>
 | |
| <li class='desktoponly'><a href="docs.html">Documentation</a>
 | |
| <li class='desktoponly'><a href="download.html">Download</a>
 | |
| <li class='wideonly'><a href='copyright.html'>License</a>
 | |
| <li class='desktoponly'><a href="support.html">Support</a>
 | |
| <li class='desktoponly'><a href="prosupport.html">Purchase</a>
 | |
| <li class='search' id='search_menubutton'>
 | |
| <a href="javascript:void(0)" onclick='toggle_search()'>Search</a>
 | |
| </ul>
 | |
| </div>
 | |
| <div class="menu submenu" id="submenu">
 | |
| <ul>
 | |
| <li><a href='about.html'>About</a>
 | |
| <li><a href='docs.html'>Documentation</a>
 | |
| <li><a href='download.html'>Download</a>
 | |
| <li><a href='support.html'>Support</a>
 | |
| <li><a href='prosupport.html'>Purchase</a>
 | |
| </ul>
 | |
| </div>
 | |
| <div class="searchmenu" id="searchmenu">
 | |
| <form method="GET" action="search">
 | |
| <select name="s" id="searchtype">
 | |
| <option value="d">Search Documentation</option>
 | |
| <option value="c">Search Changelog</option>
 | |
| </select>
 | |
| <input type="text" name="q" id="searchbox" value="">
 | |
| <input type="submit" value="Go">
 | |
| </form>
 | |
| </div>
 | |
| </div>
 | |
| <script>
 | |
| function toggle_div(nm) {
 | |
| var w = document.getElementById(nm);
 | |
| if( w.style.display=="block" ){
 | |
| w.style.display = "none";
 | |
| }else{
 | |
| w.style.display = "block";
 | |
| }
 | |
| }
 | |
| function toggle_search() {
 | |
| var w = document.getElementById("searchmenu");
 | |
| if( w.style.display=="block" ){
 | |
| w.style.display = "none";
 | |
| } else {
 | |
| w.style.display = "block";
 | |
| setTimeout(function(){
 | |
| document.getElementById("searchbox").focus()
 | |
| }, 30);
 | |
| }
 | |
| }
 | |
| function div_off(nm){document.getElementById(nm).style.display="none";}
 | |
| window.onbeforeunload = function(e){div_off("submenu");}
 | |
| /* Disable the Search feature if we are not operating from CGI, since */
 | |
| /* Search is accomplished using CGI and will not work without it. */
 | |
| if( !location.origin || !location.origin.match || !location.origin.match(/http/) ){
 | |
| document.getElementById("search_menubutton").style.display = "none";
 | |
| }
 | |
| /* Used by the Hide/Show button beside syntax diagrams, to toggle the */
 | |
| function hideorshow(btn,obj){
 | |
| var x = document.getElementById(obj);
 | |
| var b = document.getElementById(btn);
 | |
| if( x.style.display!='none' ){
 | |
| x.style.display = 'none';
 | |
| b.innerHTML='show';
 | |
| }else{
 | |
| x.style.display = '';
 | |
| b.innerHTML='hide';
 | |
| }
 | |
| return false;
 | |
| }
 | |
| </script>
 | |
| </div>
 | |
| <div class=fancy>
 | |
| <div class=nosearch>
 | |
| <div class="fancy_title">
 | |
| Architecture of SQLite
 | |
| </div>
 | |
| </div>
 | |
| 
 | |
| 
 | |
| 
 | |
| 
 | |
| <h1>Introduction</h1>
 | |
| 
 | |
| 
 | |
| <p>This document describes the architecture of the SQLite library.
 | |
| The information here is useful to those who want to understand or
 | |
| modify the inner workings of SQLite.
 | |
| </p>
 | |
| 
 | |
| <div class="rightsidebar border2px imgcontainer">
 | |
| <img src="images/arch2.gif"></img>
 | |
| </div>
 | |
| 
 | |
| <p>
 | |
| A nearby diagram shows the main components of SQLite
 | |
| and how they interoperate.  The text below
 | |
| explains the roles of the various components.
 | |
| </p>
 | |
| 
 | |
| <h1>Overview</h1>
 | |
| 
 | |
| <p>SQLite works by compiling SQL text into <a href="opcode.html">bytecode</a>, then running
 | |
| that bytecode using a virtual machine.
 | |
| 
 | |
| <p>The <a href="c3ref/prepare.html">sqlite3_prepare_v2()</a> and related interfaces act as a compiler
 | |
| for converting SQL text into bytecode.  The <a href="c3ref/stmt.html">sqlite3_stmt</a> object is
 | |
| a container for a single bytecode program using to implement a single
 | |
| SQL statement.  The <a href="c3ref/step.html">sqlite3_step()</a> interface passes a bytecode program
 | |
| into the virtual machine, and runs the program until it either completes,
 | |
| or forms a row of result to be returned, or hits a fatal error, or is
 | |
| <a href="c3ref/interrupt.html">interrupted</a>.
 | |
| 
 | |
| <h1>Interface</h1>
 | |
| 
 | |
| <p>Much of the <a href="c3ref/intro.html">C-language Interface</a> is found in source
 | |
| files <a href='https://sqlite.org/src/file/src/main.c'>main.c</a>, <a href='https://sqlite.org/src/file/src/legacy.c'>legacy.c</a>, and
 | |
| <a href='https://sqlite.org/src/file/src/vdbeapi.c'>vdbeapi.c</a>
 | |
| though some routines are
 | |
| scattered about in other files where they can have access to data 
 | |
| structures with file scope.  
 | |
| The <a href="c3ref/free_table.html">sqlite3_get_table()</a> routine is implemented in <a href='https://sqlite.org/src/file/src/table.c'>table.c</a>.
 | |
| The <a href="c3ref/mprintf.html">sqlite3_mprintf()</a> routine is found in <a href='https://sqlite.org/src/file/src/printf.c'>printf.c</a>.
 | |
| The <a href="c3ref/complete.html">sqlite3_complete()</a> interface is in <a href='https://sqlite.org/src/file/src/complete.c'>complete.c</a>.
 | |
| The <a href="tclsqlite.html">TCL Interface</a> is implemented by <a href='https://sqlite.org/src/file/src/tclsqlite.c'>tclsqlite.c</a>.
 | |
| 
 | |
| <p>To avoid name collisions, all external
 | |
| symbols in the SQLite library begin with the prefix <b>sqlite3</b>.
 | |
| Those symbols that are intended for external use (in other words,
 | |
| those symbols which form the API for SQLite) add an underscore, and
 | |
| thus begin with <b>sqlite3_</b>.  Extension APIs sometimes add the
 | |
| extension name prior to the underscore; for example:
 | |
| <b>sqlite3rbu_</b> or <b>sqlite3session_</b>.</p>
 | |
| 
 | |
| <h1>Tokenizer</h1>
 | |
| 
 | |
| <p>When a string containing SQL statements is to be evaluated it is
 | |
| first sent to the tokenizer.
 | |
| The tokenizer breaks
 | |
| the SQL text into tokens and hands those tokens
 | |
| one by one to the parser.  The tokenizer is hand-coded in 
 | |
| the file <file>tokenize.c</b>.
 | |
| 
 | |
| <p>Note that in this design, the tokenizer calls the parser.  People
 | |
| who are familiar with YACC and BISON may be accustomed to doing things the
 | |
| other way around — having the parser call the tokenizer.  Having
 | |
| the tokenizer call the parser is better, though, because it can be made
 | |
| threadsafe and it runs faster.</p>
 | |
| 
 | |
| <h1>Parser</h1>
 | |
| 
 | |
| <p>The parser assigns meaning to tokens based on
 | |
| their context.  The parser for SQLite is generated using the
 | |
| <a href="lemon.html">Lemon parser generator</a>.
 | |
| Lemon does the same job as YACC/BISON, but it uses
 | |
| a different input syntax which is less error-prone.
 | |
| Lemon also generates a parser which is reentrant and thread-safe.
 | |
| And Lemon defines the concept of a non-terminal destructor so
 | |
| that it does not leak memory when syntax errors are encountered.
 | |
| The grammar file that drives Lemon and that defines the SQL language
 | |
| that SQLite understands is found in <a href='https://sqlite.org/src/file/src/parse.y'>parse.y</a>.
 | |
| 
 | |
| <p>Because
 | |
| Lemon is a program not normally found on development machines, the
 | |
| complete source code to Lemon (just one C file) is included in the
 | |
| SQLite distribution in the "tool" subdirectory.
 | |
| </p>
 | |
| 
 | |
| <h1>Code Generator</h1>
 | |
| 
 | |
| <p>After the parser assembles tokens into a parse tree,
 | |
| the code generator runs to analyze the parser tree and generate
 | |
| <a href="opcode.html">bytecode</a> that performs the work of the SQL statement.
 | |
| The <a href="c3ref/stmt.html">prepared statement</a> object is a container for this bytecode.
 | |
| There are many files in the code generator, including:
 | |
| <a href='https://sqlite.org/src/file/src/attach.c'>attach.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/auth.c'>auth.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/build.c'>build.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/delete.c'>delete.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/expr.c'>expr.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/insert.c'>insert.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/pragma.c'>pragma.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/select.c'>select.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/trigger.c'>trigger.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/update.c'>update.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/vacuum.c'>vacuum.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/where.c'>where.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/wherecode.c'>wherecode.c</a>, and
 | |
| <a href='https://sqlite.org/src/file/src/whereexpr.c'>whereexpr.c</a>.
 | |
| In these files is where most of the serious magic happens.
 | |
| <a href='https://sqlite.org/src/file/src/expr.c'>expr.c</a> handles code generation for expressions.
 | |
| <b>where*.c</b> handles code generation for WHERE clauses on
 | |
| SELECT, UPDATE and DELETE statements.  The files <a href='https://sqlite.org/src/file/src/attach.c'>attach.c</a>,
 | |
| <a href='https://sqlite.org/src/file/src/delete.c'>delete.c</a>, <a href='https://sqlite.org/src/file/src/insert.c'>insert.c</a>, <a href='https://sqlite.org/src/file/src/select.c'>select.c</a>, 
 | |
| <a href='https://sqlite.org/src/file/src/trigger.c'>trigger.c</a>
 | |
| <a href='https://sqlite.org/src/file/src/update.c'>update.c</a>, and <a href='https://sqlite.org/src/file/src/vacuum.c'>vacuum.c</a> handle the code generation
 | |
| for SQL statements with the same names.  (Each of these files calls routines
 | |
| in <a href='https://sqlite.org/src/file/src/expr.c'>expr.c</a> and <a href='https://sqlite.org/src/file/src/where.c'>where.c</a> as necessary.)  All other
 | |
| SQL statements are coded out of <a href='https://sqlite.org/src/file/src/build.c'>build.c</a>.
 | |
| The <a href='https://sqlite.org/src/file/src/auth.c'>auth.c</a> file implements the functionality of
 | |
| <a href="c3ref/set_authorizer.html">sqlite3_set_authorizer()</a>.</p>
 | |
| 
 | |
| <p>The code generator, and especially the logic in <b>where*.c</b>
 | |
| and in <a href='https://sqlite.org/src/file/src/select.c'>select.c</a>, is sometimes called the
 | |
| <a href="optoverview.html">query planner</a>.  For any particular SQL statement, there might be
 | |
| hundreds, thousands, or millions of different algorithms to compute
 | |
| the answer.  The query planner is an AI that strives to select the
 | |
| best algorithm from these millions of choices.
 | |
| 
 | |
| <h1>Bytecode Engine</h1>
 | |
| 
 | |
| <p>The <a href="opcode.html">bytecode</a> program created by the code generator is run by
 | |
| a virtual machine.
 | |
| 
 | |
| <p>The virtual machine itself is entirely contained in a single
 | |
| source file <a href='https://sqlite.org/src/file/src/vdbe.c'>vdbe.c</a>.  The
 | |
| <a href='https://sqlite.org/src/file/src/vdbe.h'>vdbe.h</a> header file defines an interface
 | |
| between the virtual machine and the rest of the SQLite library and
 | |
| <a href='https://sqlite.org/src/file/src/vdbeInt.h'>vdbeInt.h</a> which defines structures and interfaces that
 | |
| are private the virtual machine itself.
 | |
| Various other <b>vdbe*.c</b> files are helpers to the virtual machine.
 | |
| The <a href='https://sqlite.org/src/file/src/vdbeaux.c'>vdbeaux.c</a> file contains utilities used by the virtual
 | |
| machine and interface modules used by the rest of the library to
 | |
| construct VM programs.  The <a href='https://sqlite.org/src/file/src/vdbeapi.c'>vdbeapi.c</a> file contains external
 | |
| interfaces to the virtual machine such as the 
 | |
| <a href="c3ref/bind_blob.html">sqlite3_bind_int()</a> and <a href="c3ref/step.html">sqlite3_step()</a>.  Individual values
 | |
| (strings, integer, floating point numbers, and BLOBs) are stored
 | |
| in an internal object named "Mem" which is implemented by
 | |
| <a href='https://sqlite.org/src/file/src/vdbemem.c'>vdbemem.c</a>.</p>
 | |
| 
 | |
| <p>
 | |
| SQLite implements SQL functions using callbacks to C-language routines.
 | |
| Even the built-in SQL functions are implemented this way.  Most of
 | |
| the built-in SQL functions (ex: <a href="lang_corefunc.html#abs">abs()</a>, <a href="lang_aggfunc.html#count">count()</a>,
 | |
| <a href="lang_corefunc.html#substr">substr()</a>, and so forth) can be found in <a href='https://sqlite.org/src/file/src/func.c'>func.c</a> source
 | |
| file.
 | |
| Date and time conversion functions are found in <a href='https://sqlite.org/src/file/src/date.c'>date.c</a>.
 | |
| Some functions such as <a href="lang_corefunc.html#coalesce">coalesce()</a> and <a href="lang_corefunc.html#typeof">typeof()</a> are implemented
 | |
| as bytecode directly by the code generator.
 | |
| </p>
 | |
| 
 | |
| <h1>B-Tree</h1>
 | |
| 
 | |
| <p>An SQLite database is maintained on disk using a B-tree implementation
 | |
| found in the <a href='https://sqlite.org/src/file/src/btree.c'>btree.c</a> source file.  A separate B-tree is used for
 | |
| each table and index in the database.  All B-trees are stored in the
 | |
| same disk file.  The <a href="fileformat2.html">file format</a> details are stable and well-defined and
 | |
| are guaranteed to be compatible moving forward.</p>
 | |
| 
 | |
| <p>The interface to the B-tree subsystem and the rest of the SQLite library
 | |
| is defined by the header file <a href='https://sqlite.org/src/file/src/btree.h'>btree.h</a>.
 | |
| </p>
 | |
| 
 | |
| <h1>Page Cache</h1>
 | |
| 
 | |
| <p>The B-tree module requests information from the disk in fixed-size
 | |
| pages.  The default <a href="pragma.html#pragma_page_size">page_size</a> is 4096 bytes but can be any power of
 | |
| two between 512 and 65536 bytes.
 | |
| The page cache is responsible for reading, writing, and
 | |
| caching these pages.
 | |
| The page cache also provides the rollback and atomic commit abstraction
 | |
| and takes care of locking of the database file.  The
 | |
| B-tree driver requests particular pages from the page cache and notifies
 | |
| the page cache when it wants to modify pages or commit or rollback
 | |
| changes. The page cache handles all the messy details of making sure
 | |
| the requests are handled quickly, safely, and efficiently.</p>
 | |
| 
 | |
| <p>The primary page cache implementation is in the
 | |
| <a href='https://sqlite.org/src/file/src/pager.c'>pager.c</a> file.  <a href="wal.html">WAL mode</a> logic is in the separate
 | |
| <a href='https://sqlite.org/src/file/src/wal.c'>wal.c</a>.  In-memory caching is implemented by the
 | |
| <a href='https://sqlite.org/src/file/src/pcache.c'>pcache.c</a> and <a href='https://sqlite.org/src/file/src/pcache1.c'>pcache1.c</a> files.
 | |
| The interface between page cache subsystem
 | |
| and the rest of SQLite is defined by the header file <a href='https://sqlite.org/src/file/src/pager.h'>pager.h</a>.
 | |
| </p>
 | |
| 
 | |
| <h1>OS Interface</h1>
 | |
| 
 | |
| <p>
 | |
| In order to provide portability between across operating systems,
 | |
| SQLite uses abstract object called the <a href="vfs.html">VFS</a>.  Each VFS provides methods
 | |
| for opening, read, writing, and closing files on disk, and for other
 | |
| OS-specific task such as finding the current time, or obtaining randomness
 | |
| to initialize the built-in pseudo-random number generator.
 | |
| SQLite currently provides VFSes for unix (in the <a href='https://sqlite.org/src/file/src/os_unix.c'>os_unix.c</a>
 | |
| file) and Windows (in the <a href='https://sqlite.org/src/file/src/os_win.c'>os_win.c</a> file).
 | |
| </p>
 | |
| 
 | |
| <h1>Utilities</h1>
 | |
| 
 | |
| <p>
 | |
| Memory allocation, caseless string comparison routines, 
 | |
| portable text-to-number conversion routines, and other utilities
 | |
| are located in <a href='https://sqlite.org/src/file/src/util.c'>util.c</a>.
 | |
| Symbol tables used by the parser are maintained by hash tables found
 | |
| in <a href='https://sqlite.org/src/file/src/hash.c'>hash.c</a>.  The <a href='https://sqlite.org/src/file/src/utf.c'>utf.c</a> source file contains Unicode
 | |
| conversion subroutines.
 | |
| SQLite has its own private implementation of 
 | |
| <a href="printf.html">printf()</a> (with
 | |
| some extensions) in <a href='https://sqlite.org/src/file/src/printf.c'>printf.c</a> and its own
 | |
| pseudo-random number generator (PRNG) in <a href='https://sqlite.org/src/file/src/random.c'>random.c</a>.
 | |
| </p>
 | |
| 
 | |
| <h1>Test Code</h1>
 | |
| 
 | |
| <p>
 | |
| Files in the "src/" folder of the source tree whose names begin with
 | |
| <b>test</b> are for testing only and are not included in a standard
 | |
| build of the library.
 | |
| </p>
 | |
| 
 | |
| 
 |