Python操作SQLite实战：连接、游标与提交的银行模型

很多初学者在Python里跑通第一条SQL后，仍然对connect和execute这两行代码背后的机制一知半解。Syntax Pilot频道的FreeSQL系列第二集用一个「去银行办业务」的比喻，把Python与数据库交互的完整链条拆解得相当清楚。本文结合该教程的核心内容，梳理从建立连接到提交事务的关键环节，并指出几个高频踩坑点。

用银行柜台理解六个核心步骤

教程把Python访问数据库的过程映射为一次银行访问：走进支行对应sqlite3.connect()，它返回一个连接对象，是程序与某个数据库之间的活链接；柜台职员用手指按住账本、记住当前行，对应cursor()，游标负责发送SQL并逐行遍历结果；递上业务单对应execute()，一次只发送一条SQL语句；取回答案对应fetchone()（取下一行）和fetchall()（取回剩余全部行组成的列表）；签字确认对应commit()，让改动永久生效；办完离开对应close()，结束连接。

完整的代码骨架就是这六步：导入模块、连接、创建游标、执行、取数、提交并关闭。因为SQLite是Python标准库自带的嵌入式数据库，无需安装、也无需启动服务器，这让它成为学习SQL语法的零成本起点。

内存数据库为何会「消失」

教程中第一个演示用的是:memory:这个特殊名称。它创建的是一个纯内存数据库，只存在于RAM中，连接一关闭，整个数据库就被删除；而且每次重新connect都会得到一个全新的空库。

视频里先建表、插入一条「pay fees」、提交并关闭，再重新连接读取，结果报出no such table。不少人会误以为自己忘了提交，其实问题出在数据库本身就是临时的。教程把这个特性比作离开房间就被擦干净的白板——适合做快速测试，但不适合保存数据。

要持久化，就把:memory:换成文件名，比如school.db。文件不存在时SQLite会自动创建；第一次连接把数据写进文件，第二次连接就能从文件里读回来。整个数据库——所有表、所有行、以及schema——都装在这一个普通文件里，可以复制、备份、甚至邮件发送，这正是SQLite「单文件数据库」的含义。

SQLite 的数据库在 SQLite 中表现为一个文件，但 SQLite 本身是一个嵌入式数据库引擎，它并非以「服务进程」的方式运行。这意味着当你通过 Python 的 sqlite3 模块连接数据库时，实际发生的过程是：Python 通过 C 语言绑定直接与 SQLite 库交互，库负责读写磁盘上的数据库文件。关于 :memory:，它其实是 SQLite 一个特殊的文件名约定，告知引擎在内存中创建临时数据库，而非在文件系统中创建文件。每次连接 :memory: 都会启动一个全新的数据库实例，即便是在同一进程内多次连接，彼此也不共享数据。若需要在多个连接之间共享内存数据库，可以使用 file:test?mode=memory&cache=shared 这种 URI 格式，但通常只在测试或特殊场景中使用。

忘记commit：最危险的无报错陷阱

第二个演示故意删掉commit那一行。程序运行不报任何错误，但读回来是一个空列表：建表语句生效了，插入的提醒却不见了。

原因在于Python的sqlite3中，插入操作会开启一个事务，事务可以理解为一组等待你签字的改动。不提交就关闭连接，等于把未签字的单据撕掉，改动被丢弃。而建表语句之所以幸存，是因为Python默认模式下只对行级改动等待签字。教程借此强调一条简单规则：只要改动了数据，就必须调用commit。事务的完整机制留到后续章节展开，但这条规则足以避开最常见的坑。

Python 的 sqlite3 模块默认采用「自动提交」还是「手动提交」的行为取决于版本和设置。在 Python 3.6 之前，isolation_level 的默认值为 ``（空字符串），表示 autocommit 模式关闭，即开启隐式事务；从 Python 3.6 开始，默认值为 "DEFERRED"，这意味着事务在第一次执行数据修改语句时才真正开始，直到显式调用 commit() 或 rollback() 才结束。由于 CREATE TABLE 等 DDL 语句在 SQLite 中不会触发隐式事务，因此它们会立即生效，而 INSERT 等 DML 语句则受事务控制。这正是教程中「建表语句幸存、插入丢失」的根本原因。理解这一点，就能明白为什么仅仅调用 commit 是必须的，而关闭连接并不会自动提交。

游标、语句与注释的边界

演示中向students表插入两行后，连续调用三次fetchone()，依次得到第一行、第二行、以及None——每次调用都会让「职员的手指」下移一行，取完后再取就是Python表示「什么都没有」的None。换成fetchall()则一次性把剩余行收进列表，若没有数据就是空列表。预期只有一条结果（比如按名字查某个学生）时用fetchone()，要全部结果时用fetchall()。

语句层面有两个细节值得记住。其一，execute()只能执行一条语句，把两条语句塞进同一个execute会触发ProgrammingError；要跑一整段脚本，应该用executescript()，每条语句以分号结尾。其二，注释有两种写法：--注释到行尾，/* */可以跨多行，数据库会完全跳过它们。

大小写也容易混淆。SQL关键字和SQLite的表名都不区分大小写，视频里把小写的insert和大小写混写的insert都试了一遍，两行都成功写入，全大写的select也照常工作。但引号里的文本值区分大小写——用小写a去搜Asha，结果为空。

SQL命令的五个家族与方言差异

教程把SQL命令归为五类子语言，用学校场景帮助记忆：DDL（数据定义语言）设计表结构，包括create、alter、drop；DML（数据操纵语言）改动行数据，包括insert、update、delete；DQL（数据查询语言）负责提问，即select——有些教材把select归入DML，两种划分都常见；DCL（数据控制语言）决定谁能做什么，grant授权、revoke收回；TCL（事务控制语言）签收或撤销一组改动，begin、commit、rollback，rollback就是「把单据撕掉」。

方言差异在这里体现得很明显。在SQLite里执行grant会直接报语法错误，因为SQLite根本没有用户概念——它就是一个文件，谁能打开文件谁就能读。grant和revoke属于MySQL、PostgreSQL这类客户端-服务器数据库，教程预告会在安全相关章节再谈。

SQL 方言指的是不同数据库系统在标准 SQL 基础上所做的扩展和修改。除了 SQLite 不支持 GRANT/REVOKE 之外，各数据库在数据类型、函数名、分页语法、字符串连接符等方面也存在差异。例如，SQLite 使用 || 进行字符串连接，而 MySQL 使用 CONCAT() 函数；分页查询在 SQLite 和 PostgreSQL 中用 LIMIT ... OFFSET ...，而 SQL Server 使用 OFFSET ... FETCH。学习时应记住：标准 SQL 是共同基础，但具体到某个数据库时，需查阅其文档以确认语法。这也解释了为什么教程强调「SQLite 是学习 SQL 的零成本起点」——它支持标准 SQL 的核心部分，同时避免了许多复杂特性。

SQLite Shell：点命令不是SQL

除了Python，还可以用SQLite自带的shell直接输入SQL。它有一类以点开头的特殊命令，如果在Python里发送点命令，会得到near ".": syntax error——点命令是给shell程序本身的指令，数据库从未听说过它们。

一次真实会话大致是这样的：在终端输入sqlite3加文件名启动CLI；.tables列出文件中的表；.schema students显示建表语句；普通SQL照常以分号结尾执行。默认输出用竖线分隔列；忘记分号时shell会显示...续行提示，等待语句剩余部分；.headers on打印列名；.mode table画出整齐的方框，.mode column则对齐但不加框，同一条查询可读性差别很大。点命令不需要分号，因为它们不是SQL。

其他数据库也有类似的shell：PostgreSQL的叫psql，特殊命令以反斜杠开头（如\dt列出表）；MySQL的shell就直接叫mysql，使用show tables、describe这类类SQL命令。区别在于psql和mysql是客户端，需要地址、用户名和密码去连服务器，而SQLite只是打开一个文件。

今日陷阱汇总与自测

教程最后把坑点集中列了一遍：内存数据库随连接关闭而消失；忘记commit改动会无声无息地蒸发，这是最危险的一个；execute只跑一条语句，多条要用executescript；点命令只在shell里有效，绝不能混入SQL。

视频末尾留了一道自测题：students表有两行，先fetchall()再fetchone()，会打印什么？答案是None——fetchall已经取走全部剩余行，游标的「手指」停在末尾，下一次fetchone自然什么也找不到。课后作业是建一个包含三条笔记的日记数据库，逐条读回，并观察不写commit时丢掉了什么。下一集将正式讲解select：挑选列、在查询里做运算、重命名列，以及列名叫order时埋下的陷阱。