简介一份面向Web开发初学者与课程设计学生的PythonMySQL管理系统源码包。项目基于Flask框架搭建按app、main、manage.py等模块拆分业务逻辑入口脚本manage.py用于启动与初始化settings.py集中管理配置核心代码涵盖extensions.py扩展初始化、util.py工具函数、models.py数据建模并配套blog_db.sql数据库脚本与README文档导入数据库后即可完成本地环境部署。细看包内结构templates与static目录分离还包含日志目录与配置文件目录层级清晰适合学习Flask项目规范。资源共71个文件除10个Python源码文件外还有21个HTML页面、7个CSS样式、3个JS交互脚本以及字体、图标、图片、数据库脚本和日志等辅助文件整体仅807KB便于快速下载与二次修改。已有629人学习浏览可用作毕业设计、实训课设也能帮助理解FlaskMVC分层开发与MySQL数据库联动流程是完整的全栈练手项目。1. Python MySQL 管理系统先搞清楚这份代码包解决什么问题Python MySQL 管理系统是绕过重型框架直接落业务时最常用的一套组合也是课程设计和内部工具里出现频率最高的代码包。这份代码包给的不是演示页面而是一个完整可跑的增删改查骨架数据库初始化脚本、连接层封装、登录鉴权、业务表增删改查、分页搜索都齐了拿到手改表名和字段就能交付。适合三类人第一次用 Python 连数据库做后端的新手要给内部工具配数据管理界面的开发者以及课程设计想要一份规范参考的同学。下面按我拆包复现的顺序讲从环境搭到避坑再到二次开发每步都可抄。2. 环境与数据库准备把运行基础一次搭对2.1 版本选型Python 3.8 MySQL 5.7/8.0 怎么配不翻车这个代码包的核心栈是 Python 和 MySQL中间靠 pymysql 这个驱动通信pymysql 就是 Python 和 MySQL 之间的软件插件版本选不对后面全白搭。Python 3.8 以上基本都能跑我拆包时用的 3.10MySQL 建议 5.7 或 8.0 都行但 8.0 的默认认证插件和旧驱动有兼容问题具体解法放在第四章。依赖只需要一个pip install pymysql提示如果机器上装了多个 Python 版本确认 pip 指向的是你运行代码的解释器用python -m pip install pymysql更稳妥。装完用python -c import pymysql; print(pymysql.__version__)验证1.0 以上对 MySQL 8.0 的认证方式支持更好。这里有个选型提醒别在代码里混用 pymysql 和别的 MySQL 驱动两者的游标接口和参数占位符习惯不一样混用最容易翻车整套代码只认一个驱动。顺手把核心组件版本列一下组件版本建议说明Python3.83.10 实测无问题MySQL5.7 / 8.08.0 需 pymysql 1.0pymysql1.0纯 Python 驱动免编译DBUtils按需压测或并发场景再上连接池2.2 建库建表字段类型、字符集和索引的取舍代码包里带了一个 schema.sql拆包后第一件事就是把它跑进 MySQL。核心是两张表sys_user 存登录账号biz_item 存业务数据建表语句长这样CREATE DATABASE IF NOT EXISTS manage_sys DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE manage_sys; CREATE TABLE IF NOT EXISTS sys_user ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password_hash CHAR(64) NOT NULL COMMENT SHA256(saltpassword), salt CHAR(32) NOT NULL, role TINYINT NOT NULL DEFAULT 1 COMMENT 1普通用户 9管理员, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT登录用户表; CREATE TABLE IF NOT EXISTS biz_item ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, item_no VARCHAR(32) NOT NULL UNIQUE COMMENT 业务编号, name VARCHAR(128) NOT NULL, category VARCHAR(64) DEFAULT , status TINYINT NOT NULL DEFAULT 0, remark VARCHAR(255) DEFAULT , created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_created_at (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT业务数据表;库和表都显式指定 utf8mb4这是中文数据不乱码的前提第四章还有个连带坑。字段设计上有三个习惯值得抄一是主键用 INT UNSIGNED AUTO_INCREMENT简单稳定二是唯一约束直接写在 username 和 item_no 上比在代码里查重可靠三是 created_at 带默认值INSERT 时少写一个字段。索引我只在 created_at 上建了一个因为列表页常按时间倒序而这个量级的系统没必要每个字段都加索引索引越多写入越慢。2.3 连接层封装用上下文管理器管好连接和事务整个代码包最值得抄的模块是 db.py。它把连接参数集中在一个配置里用with语句管理连接生命周期顺带把事务的提交和回滚也管住了# db.py import pymysql from pymysql.cursors import DictCursor DB_CONFIG { host: 127.0.0.1, port: 3306, user: manage_app, password: ChangeMe_2024, database: manage_sys, charset: utf8mb4, autocommit: False, cursorclass: DictCursor, } class DB: def __enter__(self): self.conn pymysql.connect(**DB_CONFIG) return self.conn def __exit__(self, exc_type, exc_val, exc_tb): if exc_type: self.conn.rollback() self.conn.close() return False self.conn.commit() self.conn.close() return False这个封装解决三个实际问题。第一autocommit 设为 False写操作必须显式 commit避免半截失败留下脏数据第二异常时自动 rollback业务代码里不用每个函数都写 try/except第三DictCursor 让查询结果返回字典row[name]比row[1]可读性强得多。使用方式也很直白with DB() as conn, conn.cursor() as cur: cur.execute(SELECT COUNT(*) AS total FROM biz_item) print(cur.fetchone()[total])注意__exit__里的return False——它告诉解释器异常已经处理过但异常对象仍然会抛给上层业务调用方该捕获还是能捕获不会把错误吞掉。后面想扩容时把类内部改成从连接池取连接外部调用方一行都不用动。3. 核心功能拆解登录鉴权与增删改查的实现细节3.1 登录模块盐值哈希和参数化查询的一次完整示范登录是管理系统的门面代码包里的实现值得细看它同时解决了两个问题密码不能明文存、查询不能拼字符串。import hashlib import secrets import hmac def make_salt() - str: return secrets.token_hex(16) def hash_password(password: str, salt: str) - str: return hashlib.sha256((salt password).encode(utf-8)).hexdigest() def verify_password(password: str, salt: str, expected: str) - bool: actual hash_password(password, salt) return hmac.compare_digest(actual, expected) def login(username: str, password: str): with DB() as conn, conn.cursor() as cur: cur.execute( SELECT id, username, salt, password_hash, role FROM sys_user WHERE username%s, (username,) ) row cur.fetchone() if not row: return None if not verify_password(password, row[salt], row[password_hash]): return None return {id: row[id], username: row[username], role: row[role]}逻辑分三段先按用户名取回盐值和哈希再对输入密码做相同的“盐密码”SHA256 运算最后用 hmac.compare_digest 做等长比较。用 compare_digest 而不是是为了避免时序攻击这种细节在小系统里容易被忽略但代码包带了。登录成功后返回的字段里刻意不带 password_hash 和 salt避免会话对象把敏感字段带到业务层。还要注意 SQL 里的%s占位符——pymysql 会把(username,)这个元组参数转义后传入而不是拼进 SQL 字符串。3.2 增删改查lastrowid、rowcount 与事务的配合业务表的增删改查是代码包的主干三个写操作分别用 lastrowid 和 rowcount 返回影响信息def create_item(data: dict) - int: with DB() as conn, conn.cursor() as cur: cur.execute( INSERT INTO biz_item (item_no, name, category, status, remark) VALUES (%s, %s, %s, %s, %s), (data[item_no], data[name], data[category], data[status], data[remark]) ) return cur.lastrowid def update_item(item_id: int, data: dict) - int: with DB() as conn, conn.cursor() as cur: cur.execute( UPDATE biz_item SET name%s, category%s, status%s, remark%s WHERE id%s, (data[name], data[category], data[status], data[remark], item_id) ) return cur.rowcount def delete_item(item_id: int) - int: with DB() as conn, conn.cursor() as cur: cur.execute(DELETE FROM biz_item WHERE id%s, (item_id,)) return cur.rowcountcreate_item 返回新插入行的自增主键业务层可以直接拿它跳转详情页update 和 delete 返回受影响行数调用方据此判断“0 表示没匹配到数据”而不是报错。因为套了 db.py 的事务封装这三个函数里任何一个执行中抛异常连接自动回滚不会出现插入了一半的状态。还有一个容易被忽略的细节更新语句里每列都用参数占位没有一个值是用字符串拼接进去的这保证了下文搜索模块在拼 LIKE 时不会把注入风险带进来。3.3 分页搜索LIMIT 参数化和 LIKE 模糊匹配的正确姿势管理系统的列表页几乎都逃不过分页和搜索代码包里的 search_items 函数把两者合在了一起def search_items(keyword: str, page: int, page_size: int 20) - dict: offset (page - 1) * page_size like f%{keyword}% with DB() as conn, conn.cursor() as cur: cur.execute( SELECT * FROM biz_item WHERE name LIKE %s OR item_no LIKE %s ORDER BY id DESC LIMIT %s OFFSET %s, (like, like, page_size, offset) ) rows cur.fetchall() cur.execute( SELECT COUNT(*) AS total FROM biz_item WHERE name LIKE %s OR item_no LIKE %s, (like, like) ) total cur.fetchone()[total] return {list: rows, total: total, page: page, page_size: page_size}这里有两个易错点。一是LIKE %s的百分号是放在参数里而不是 SQL 里pymysql 不会把参数里的 % 当占位符处理所以 like 变量传%关键字%是安全的反过来如果把 % 写进 SQL 字符串再用%s占位百分号会和占位符语法冲突。二是 LIMIT 和 OFFSET 同样走参数化pymysql 会把 int 转成合法的字面量不需要担心注入。返回结构里 total 单独查一次 COUNT是为了让前端好算总页数数据量过万后 COUNT 会变慢届时的优化方向是改成“先 LIMIT 取一页再单独算总数”或加缓存这是后话。注意别图省事写LIMIT 99999这种偷懒翻页数据量上来后一次比一次慢属于给自己埋雷。4. 避坑指南连接、编码、事务与安全的五个实锤4.1 认证与连接类两个最容易横在门口的报错坑一MySQL 8.0 报 caching_sha2_password 认证失败。现象是程序启动后第一次查库就抛错提示默认认证插件不被支持SQL 客户端却连得通。原因是 MySQL 8.0 把默认认证插件换成了 caching_sha2_password而低版本 pymysql 不认识。解决有两路要么把 pymysql 升到 1.0 以上要么把账号的认证方式改回 mysql_native_passwordALTER USER manage_applocalhost IDENTIFIED WITH mysql_native_password BY ChangeMe_2024; FLUSH PRIVILEGES;改完用python -c import pymysql; pymysql.connect(host127.0.0.1, usermanage_app, passwordChangeMe_2024, databasemanage_sys)快速验证不报错就是通了。坑二运行几小时后报 MySQL server has gone away。现象是页面偶尔能开、偶尔白屏重启进程又恢复。原因是 MySQL 的 wait_timeout 默认 8 小时连接空闲过久被服务端断开客户端还拿着旧连接去查。解决思路是每次请求都重新建立连接——db.py 的上下文管理器天然规避了这个问题如果确实要长连接可以调大 wait_timeout或者每次查之前先SELECT 1做探活。我一般在这类代码包里直接保留“每次新建连接”的写法量级不大简单反而稳。4.2 编码与事务类数据看起来对结果全是坑坑三中文写入后变成问号。现象是页面上输入「订单」存进 MySQL 变成??读取回来也是乱码。原因是连接、库、表三级字符集不统一常见的是库表建成了 latin1 或 utf8而连接用了 utf8mb4。解决方法是把三处统一为 utf8mb4建库时指定、DDL 里写 DEFAULT CHARSETutf8mb4、连接配置里加charsetutf8mb4。改完后用SHOW CREATE TABLE biz_item;确认表级字符集再用SELECT HEX(name) FROM biz_item WHERE id1;抽查数据能查到正常的 UTF-8 字节序列才算真修好。坑四增删改执行成功但重启后数据没了。现象是程序完全没报错INSERT 返回了 idSELECT 也能查到但 MySQL 服务一重启数据就消失。原因是 autocommitFalse 时执行了写入却从没调用 commit事务还在未提交状态。代码包的事务封装里 commit 是放在__exit__正常路径上的但如果你自己写的业务代码绕开了 DB 类、直接pymysql.connect()就很容易漏掉 commit。排查方法是登录 MySQL 后另开一个会话SELECT * FROM biz_item;——未提交数据在当前会话可见、其他会话不可见修复就是补上conn.commit()或者把 autocommit 置为 True。4.3 安全类字符串拼接 SQL 是最大的定时炸弹坑五搜索框输入 OR 11直接拉出全表数据。现象是带引号和单引号的搜索词返回了意料之外的大批量结果严重时 DELETE 语句被拼出全表删除。原因是代码里用 f-string 或直接拼接 SQL 字符串。解决只有一条路全部改成参数化查询绝不在 SQL 里拼外部输入。# 错误写法能跑但一句话就能打穿 cur.execute(fSELECT * FROM biz_item WHERE name LIKE %{keyword}%) # 正确写法参数走占位符pymysql 负责转义 cur.execute( SELECT * FROM biz_item WHERE name LIKE %s, (f%{keyword}%,) )这种坑在小系统里平时不炸一旦炸就是数据被拖走或删库级别的损失。我排查这类代码包时有个习惯全局搜execute(后面的字符串凡是出现f或拼接的都标红重写。这五条看着基础但我在实际项目里见过前四条同时出现排查顺序基本就是先认证、再编码、再事务、最后查拼接按这个顺序来能少走半小时弯路。5. 初始化脚本与数据备份让代码包可直接交付5.1 一键初始化schema.sql 和 init_db.py 怎么配合代码包能不能直接给别人用就看初始化是否省心。包里带了 schema.sql 和 init_db.pyinit_db.py 读取 SQL 文件并执行# init_db.py import pymysql ADMIN_CONF { host: 127.0.0.1, port: 3306, user: root, password: your_root_password, charset: utf8mb4, } def run_sql_file(conn, path: str) - None: with open(path, r, encodingutf-8) as f: script f.read() with conn.cursor() as cur: for statement in script.split(;): statement statement.strip() if statement: cur.execute(statement) conn.commit() def seed_admin(conn) - None: salt make_salt() pwd_hash hash_password(admin123, salt) with conn.cursor() as cur: cur.execute( INSERT INTO sys_user (username, salt, password_hash, role) VALUES (%s, %s, %s, %s) ON DUPLICATE KEY UPDATE saltVALUES(salt), password_hashVALUES(password_hash), (admin, salt, pwd_hash, 9) ) conn.commit() if __name__ __main__: with pymysql.connect(**ADMIN_CONF) as conn: run_sql_file(conn, schema.sql) seed_admin(conn) print(初始化完成默认账号: admin / admin123)这里有一个典型脆弱点按分号切分 SQL 时如果 schema.sql 的注释里带分号脚本就会切错位置。我习惯的规避方式是在 schema.sql 里不写带分号的注释并把每条语句独立一行想更严谨就走多语句执行或存储过程。seed_admin 里用 ON DUPLICATE KEY UPDATE 保证重复执行不会报错密码哈希是 Python 侧生成再写入而不是写死在 SQL 里——这样每台机器初始化出来的盐值都不同。5.2 备份恢复mysqldump 一条命令和定时任务交付之后最怕数据丢。MySQL 自带的 mysqldump 足够覆盖这个小系统的体量备份和恢复各一条命令# 备份Linux / macOS mysqldump -u manage_app -p manage_sys backup_$(date %Y%m%d_%H%M%S).sql # 恢复 mysql -u manage_app -p manage_sys backup_20240601_120000.sql恢复前建议先确认目标库是空库避免新旧数据混在一起mysqldump 备份的是逻辑 SQL恢复时如果表已存在且有数据会直接叠加或报主键冲突我一般先DROP DATABASE再重建。Windows 下批处理要注意两点mysqldump.exe 在 MySQL 安装目录的 bin 下date 命令要用%date:~0,4%%date:~5,2%%date:~8,2%这类写法且要提前测一遍路径里的斜杠。想定时备份Linux 上写 cron 每天凌晨执行Windows 用任务计划程序调用一个 .bat。备份文件记得和源码分开存放别放在同一台机器同一个目录这个习惯救过我不少次。6. 跑通之后再做两件事验证清单与二次开发切入点拿到代码包先别急着改业务把下面清单走一遍确认骨架本身没毛病验证项操作预期结果登录输入 admin / admin123返回用户信息无异常新增提交一条业务记录返回自增 id列表可见搜索输入关键字返回匹配列表分页正确修改编辑名称或状态受影响行数1刷新后生效删除删除一条记录受影响行数1列表减少重启重启 Python 服务数据仍在登录正常这套流程十分钟能跑完但能筛掉八成环境问题。验证时重点看三处登录失败时是否返回明确错误而不是抛异常分页第二页是否真的翻页而不是重复第一页中文输入输出是否全程无乱码。这三处是这类代码包最容易藏问题的位置。二次开发的方向我按实际需要排了序。第一优先级是换业务表把 biz_item 复制成自己的表名改字段和 search_items 里的列名列表、详情、编辑三处联动改半小时能完成。第二优先级是加 Web 层现在代码包提供的是函数接口想做成浏览器访问就在外面套一层轻量 Web 框架路由里直接调用 create_item、search_items 这些函数参数校验放在路由层。第三优先级是安全加固把 SHA256 换成加盐的 bcrypt 或 argon2给登录加失败次数限制。换算法时只需要改 hash_password 和 verify_password 两个函数登录和建账号的调用方不用动这个松耦合设计是我拆包时觉得最舒服的地方。再补一个验证技巧改完表结构后用EXPLAIN SELECT * FROM biz_item WHERE item_no xxx;看索引是否命中type 列出现 ALL 就说明全表扫描该加索引了。这类小系统查一次 EXPLAIN 的成本极低但能把慢查询隐患提前排掉。这篇拆解对应的代码包拿到手后建议也按这套顺序来一遍。我从那以后每次拿到代码包都强制走一遍“先跑 schema、再验证单、再查 EXPLAIN、最后才动业务代码”的顺序顺序反了就会在环境问题上浪费时间很多玄学问题也多半出在这个环节。希望帮到你。本文还有配套的精品资源点击获取