写代码这些年，我见过太多人把数据库的execute方法用得稀里糊涂。有人拿它当万能工具，什么SQL都往里塞；有人嫌它麻烦，宁愿拼字符串也不肯用参数化查询。其实execute的用法远比你想象的丰富，但前提是你得搞清楚它到底在干什么。我最早踩坑是在一个电商项目里，同事写了一段代码，直接拼接用户输入的搜索关键词到SQL里，结果上线第一天就被攻击了——一个简单的单引号注入，整个商品表差点被删光。那时候我才真正意识到，execute不只是“执行一条语句”那么简单，它背后藏着安全、性能、可维护性这些实实在的问题。
先说最基础的，execute到底能执行什么。很多新手以为它只能跑SELECT查询，其实不是。在Python的数据库接口规范（DB-API 2.0）里，execute可以处理任何SQL语句：INSERT、UPDATE、DELETE，甚至DDL语句如CREATE TABLE。关键区别在于，查询语句需要你手动获取结果集，而修改语句只返回影响行数。比如你执行一条UPDATE，execute返回的是一个整数，告诉你改了多少行。这个数字看似简单，但在实际业务里很有用——比如更新用户余额时，如果返回0，说明用户ID不存在或者余额没变，你就可以决定是报错还是忽略。我见过有人忽略这个返回值，结果数据不对了还在那debug了半天，发现是SQL写错了条件。
但execute最容易被忽略的，是它的参数化查询能力。很多人习惯用f-string拼SQL：“f'SELECT FROM users WHERE id = {userid}'”。这种写法在开发阶段看着挺方便，但一旦上线，就是等着被SQL注入。正确的做法是把参数作为第二个参数传给execute：cursor.execute(“SELECT FROM users WHERE id = %s”, (userid,))。注意，这里的%s是占位符，数据库驱动会自动帮你转义和引号处理。我见过一个团队，代码里全是f-string拼接，后来被安全审计打回重写，光改这个就花了三天。更坑的是，有些数据库的占位符不一样，MySQL用%s，PostgreSQL用%s或$1，SQLite也用%s，但如果你用错，可能执行时报错或者根本查不出数据。
说到execute的性能，很多人觉得它就是个单条语句执行器，其实不是。很多数据库驱动支持executemany方法，可以一次执行多条相同结构的SQL，只是参数不同。比如批量插入1000条用户数据，用循环一条条execute，要来回1000次网络往返；用executemany，底层会打包成一条批量语句发送，性能提升不止一个数量级。我做过测试，在MySQL里插入10万条记录，单条循环要35秒，executemany只要1.2秒。但有个坑：executemany不是所有数据库驱动都支持返回影响行数，有些驱动会返回None，你得自己算。另外，有些驱动在executemany内部其实是逐条执行的，只是封装了循环，这时候你要看文档确认。
execute还有一个容易被忽视的细节：事务管理。很多人以为execute执行完数据就写进去了，其实不是。默认情况下，很多数据库驱动（比如psycopg2 for PostgreSQL）是开启自动提交的，但有些不是（比如MySQL的Connector/Python默认关闭）。如果你不显式commit，数据只在当前连接的内存里，一旦连接断开就丢了。我有个朋友做支付系统，因为没commit，用户付了钱但订单状态没更新，差点被投诉到工商局。正确的做法是：执行完所有修改操作后，手动调用commit()，或者用with语句自动提交。但注意，如果中途出错，要记得rollback，否则连接会卡在异常状态，后续查询都会报错。
另外，execute返回的结果集处理也是个学问。很多人直接cursor.fetchall()一把抓，但数据量大的时候，内存会炸。比如你查一个几百万行的日志表，fetchall会把所有数据加载到内存里，程序直接OOM。更好的做法是用fetchmany(size)或者直接迭代cursor对象，每次取一批数据，处理完再取下一批。cursor本身就是一个迭代器，for row in cursor: 这样写，底层会分批从数据库取数据，不会一次性加载所有。但注意，有些数据库驱动不支持这种迭代，得用fetchmany手动控制。还有个技巧：如果你只需要一条数据，用fetchone()，别用fetchall()[0]，后者会浪费网络带宽和内存。
execute的错误处理很多人做得太糙。常见的做法是try-except一把抓，所有异常都当同一个错误处理。但数据库异常有很多种：连接超时、语法错误、主键冲突、死锁、权限不足……每种情况应该有不同的处理逻辑。比如主键冲突，你可能想忽略或者更新；死锁，你应该重试；语法错误，你得告诉开发者SQL写错了。建议至少捕获三个异常类：DatabaseError（数据库层面的错误，比如连接断开）、IntegrityError（约束违反，比如主键重复）、OperationalError（操作错误，比如表不存在）。每个异常写不同的处理分支。我见过一个系统，把所有异常都吞掉了，结果数据重复了也没人知道，直到客户投诉才发现。
说到底，execute就是一个接口，但怎么用好它，体现的是你对数据库、对系统、对业务的理解深度。别把它当成黑盒，也别过度封装。该参数化就参数化，该批量就批量，该commit就commit，该处理异常就处理异常。这些细节决定了你的代码是稳定可靠，还是随时可能炸雷。下次写execute的时候，停下来想一想：参数传对了吗？事务提交了吗？异常处理了吗？结果集怎么取？多花30秒思考，能省下后面几小时的debug时间。
