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>
 | 
						|
 | 
						|
 |