简介：这份数据库课程设计资料围绕“员工信息管理系统”展开，基于Python与MySQL实现，面向需要完成数据库课程设计、课程作业或入门数据库应用开发的学生。内容覆盖需求分析、E-R图与数据流图设计、员工与部门等表结构规划，以及通过pymysql连接数据库并完成增删改查、JOIN查询和事务处理的完整思路，适合用来对照理解从概念设计到代码落地的过程。压缩包共9个文件，约6.71MB，包含2个py源码脚本、2个doc课程设计报告与说明文档、4个png系统界面及设计图、1个md说明文件，类型精简但覆盖源码、文档和图示。已有4344人学习，读者可从中获得可运行的参考源码、课程设计报告框架、数据库设计图示与常见异常处理和安全注意事项，便于快速搭建自己的课程设计项目并查漏补缺。
1. 员工信息管理系统源码拆解：Python + MySQL 在课程设计里能落地到什么程度
这套数据库课程设计里的员工信息管理系统源码，用 Python + MySQL 把员工档案、部门、岗位、薪资和考勤串成一条能跑通的管理链路。它不是只交作业的演示壳子：登录、增删改查、条件检索、统计报表都有对应实现。适合正在做课程设计、需要一份能改的数据库项目底稿的人，也适合刚学完 SQL 想看看 Python 怎么把表连到界面上的开发者。真正值得看的不是界面，而是它怎么处理外键、唯一约束和事务；很多课程设计源码第一眼能跑，第二眼就发现删一条部门记录会把员工卡死，这套代码的价值就在于把这些边界提前写进了表结构和 service 层。
2. 项目结构与环境落地：从目录树到 MySQL 建库的完整跑通路径
拿到一套 Python + MySQL 的员工信息管理系统源码，最怕的是直接双击main.py，然后被一堆连接错误和缺表提示拦住。比较稳的顺序是先把目录职责看明白，再建库建表，最后改配置启动。课程设计项目通常不会把工程做得特别重，但分层是否清楚，直接决定后面加字段、加审批、加导出时会不会把代码改成一锅粥。
2.1 源码目录怎么读：dao、service、ui、config 各管什么
这类项目常见的目录组织是dao管 SQL、service管业务校验和事务、ui管界面、config管连接参数。别看文件不多，职责一分开，排错时就能快速定位是 SQL 写错、参数没传对，还是界面事件绑错了。下面这张表是我读这类源码时先扫一遍的清单，字段名可能略有差异，但骨架基本一致。
| 路径 | 职责 | 改动频率 |
|---|---|---|
main.py | 程序入口，初始化窗口或启动 Web 服务 | 低 |
config.py | MySQL 主机、端口、库名、字符集 | 每次换环境要改 |
db.py | 连接封装、提交回滚、游标类型 | 低 |
dao/employee_dao.py | 员工表增删改查、分页 SQL | 中 |
service/employee_service.py | 参数校验、唯一性判断、事务边界 | 高 |
ui/main_window.py | 表格渲染、按钮事件、表单弹窗 | 中 |
sql/init.sql | 建库建表、初始部门岗位 | 首次运行必用 |
requirements.txt | Python 依赖，常见是pymysql | 低 |
dao层不要塞业务判断，这是课程设计里最容易翻车的地方。比如“工号不能重复”看起来像 SQL 的事，实际上应该由数据库唯一索引兜底，service 层负责把IntegrityError翻译成用户能看懂的提示。ui层也不要去拼 SQL，否则换一个界面就得重写一遍查询。目录不用追求大厂标准，但一条请求从按钮到数据库再回到表格，路径要清楚。
如果源码里没有service层，只有dao和ui，也不用急着重构。先看dao里有没有把连接、提交、回滚封装好；没有的话，补一个db.py比大改目录更划算。课程设计项目最怕过度设计，五张表的小系统拆十几个包，最后自己都找不到入口。
2.2 建库建表：员工、部门、岗位、薪资、考勤五张核心表
建表是整个项目的地基。员工信息管理系统常见的五张核心表是部门、岗位、员工、薪资、考勤，再加一张登录用户表。下面这份 SQL 可以直接作为sql/init.sql的骨架，字段长度和约束按课程设计场景够用，重点是主键、唯一约束、外键和金额类型要写对。
-- 建库时统一 utf8mb4，避免姓名、部门名里的中文出现乱码 CREATE DATABASE IF NOT EXISTS employee_mgmt DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE employee_mgmt; -- 部门表：部门名唯一，避免重复录入 CREATE TABLE department ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL UNIQUE, manager VARCHAR(32) DEFAULT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB; -- 岗位表：岗位挂在部门下，基础薪资用于后续薪资核算参考 CREATE TABLE position ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, level TINYINT NOT NULL DEFAULT 1, base_salary DECIMAL(10,2) NOT NULL DEFAULT 0.00, dept_id INT NOT NULL, CONSTRAINT fk_position_dept FOREIGN KEY (dept_id) REFERENCES department(id) ON DELETE RESTRICT, UNIQUE KEY uk_position_dept_name (dept_id, name) ) ENGINE=InnoDB; -- 员工主表：工号唯一，状态 1 在职、0 离职 CREATE TABLE employee ( id INT PRIMARY KEY AUTO_INCREMENT, emp_no VARCHAR(20) NOT NULL UNIQUE, name VARCHAR(32) NOT NULL, gender VARCHAR(8) DEFAULT NULL, phone VARCHAR(20) DEFAULT NULL, email VARCHAR(64) DEFAULT NULL, dept_id INT NOT NULL, position_id INT NOT NULL, hire_date DATE NOT NULL, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, CONSTRAINT fk_employee_dept FOREIGN KEY (dept_id) REFERENCES department(id) ON DELETE RESTRICT, CONSTRAINT fk_employee_position FOREIGN KEY (position_id) REFERENCES position(id) ON DELETE RESTRICT, KEY idx_employee_dept (dept_id), KEY idx_employee_name (name) ) ENGINE=InnoDB; -- 薪资表：按员工和月份唯一，保留历史发放记录 CREATE TABLE salary ( id INT PRIMARY KEY AUTO_INCREMENT, employee_id INT NOT NULL, month CHAR(7) NOT NULL, base DECIMAL(10,2) NOT NULL DEFAULT 0.00, bonus DECIMAL(10,2) NOT NULL DEFAULT 0.00, deduction DECIMAL(10,2) NOT NULL DEFAULT 0.00, total DECIMAL(10,2) NOT NULL DEFAULT 0.00, CONSTRAINT fk_salary_employee FOREIGN KEY (employee_id) REFERENCES employee(id) ON DELETE CASCADE, UNIQUE KEY uk_salary_emp_month (employee_id, month) ) ENGINE=InnoDB; -- 考勤表：按员工和日期唯一，一天只留一条记录 CREATE TABLE attendance ( id INT PRIMARY KEY AUTO_INCREMENT, employee_id INT NOT NULL, work_date DATE NOT NULL, check_in TIME DEFAULT NULL, check_out TIME DEFAULT NULL, status VARCHAR(16) NOT NULL DEFAULT '正常', CONSTRAINT fk_attendance_employee FOREIGN KEY (employee_id) REFERENCES employee(id) ON DELETE CASCADE, UNIQUE KEY uk_attendance_emp_date (employee_id, work_date) ) ENGINE=InnoDB; -- 登录用户表：password_hash 存盐和摘要，不存明文 CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE, password_hash VARCHAR(255) NOT NULL, role VARCHAR(16) NOT NULL DEFAULT 'clerk', employee_id INT DEFAULT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_users_employee FOREIGN KEY (employee_id) REFERENCES employee(id) ON DELETE SET NULL ) ENGINE=InnoDB;这段 SQL 的逻辑是先把部门、岗位建好，再建员工，最后建薪资和考勤，顺序不能反，否则外键找不到父表。DECIMAL(10,2)用来存金额，别用FLOAT，课程设计里算工资出现5999.999这种尾数很难解释。emp_no和username上的唯一索引是硬约束，界面校验只能算第一道门。ON DELETE RESTRICT表示部门下还有员工时不允许删部门，ON DELETE CASCADE用在薪资和考勤上，删员工时连带清掉明细，具体取舍看业务要求。
参数上，VARCHAR(64)对部门名和岗位名足够，VARCHAR(20)对工号足够，别一上来全用TEXT。status TINYINT比字符串更适合做在职状态，查询快，索引也小。month CHAR(7)存2025-06这种格式，比存两个整数字段更好查。字符集统一utf8mb4，连接配置里也要写一致，只改表不改连接照样乱码。
2.3 配置与启动：改一处连接参数，跑起 main.py
建完库之后，把连接参数收口到config.py。很多课程设计源码把主机、密码写死在每个 DAO 文件里，换一台电脑就要全局搜索替换，这种坑完全可以在启动前避开。
# config.py import os import pymysql # 本地开发用环境变量覆盖，换机器时不用改代码 DB_CONFIG = { "host": os.getenv("DB_HOST", "127.0.0.1"), "port": int(os.getenv("DB_PORT", "3306")), "user": os.getenv("DB_USER", "root"), "password": os.getenv("DB_PASSWORD", "123456"), # 改成自己的 MySQL 密码 "database": os.getenv("DB_NAME", "employee_mgmt"), "charset": "utf8mb4", "cursorclass": pymysql.cursors.DictCursor, }这段配置做两件事：把连接参数集中到一个字典里，把查询结果默认转成字典。DictCursor很实用，界面层拿到的就是row["name"]，不用记字段下标。os.getenv让同一份代码可以在本机、实验室机器、答辩电脑上切换，只改环境变量或者临时改默认值。密码不要提交到公开仓库，课程设计里至少做到不把它写进 UI 文件。
启动顺序建议固定成下面这样。先建虚拟环境，再装依赖，再导入 SQL，最后跑入口。每一步失败都能单独排查，不会把环境问题和代码问题混在一起。
# 在项目根目录创建虚拟环境 python -m venv venv # Windows 激活 venv\Scripts\activate # macOS / Linux 激活 source venv/bin/activate # 安装数据库驱动，源码里常见的是 pymysql pip install pymysql # 导入建库建表脚本，按提示输入 MySQL 密码 mysql -u root -p < sql/init.sql # 启动程序 python main.py这里的python -m venv venv是为了隔离依赖，pip install pymysql只装驱动，后面如果源码用了openpyxl做导出，再补对应包。mysql -u root -p < sql/init.sql要求当前目录下有sql/init.sql，如果路径不同就改成实际路径。python main.py跑不起来时，先确认当前终端激活的是不是刚才那个虚拟环境，再看报错是缺模块还是连不上库。
提示：第一次跑先不要改界面代码，按“建库、导数据、改配置、启动”的顺序走一遍，能登录再谈功能。
2.4 首次登录与初始化数据：别让空库把你挡在门外
空库直接启动，最常见的结果是登录页能打开但没有账号，或者部门下拉框一片空白。初始化数据要补两类：基础部门和岗位，以及一个可登录的管理员账号。部门岗位可以直接用 SQL 插入，管理员密码不要存明文，用 Python 生成哈希再写进去。
# tools/make_password.py import hashlib import os def hash_password(password: str) -> str: # 每个账号独立盐值，格式为“盐的十六进制$摘要的十六进制” salt = os.urandom(16) digest = hashlib.pbkdf2_hmac("sha256", password.encode("utf-8"), salt, 120000) return f"{salt.hex()}${digest.hex()}" if __name__ == "__main__": print(hash_password("admin123"))这段代码用pbkdf2_hmac生成密码摘要，盐值随机，迭代次数写成 120000。跑一次把输出复制到users表的password_hash字段，登录时再用同样的盐和迭代次数校验。参数上，sha256是摘要算法，salt必须每个用户不同，迭代次数不要低到几千，课程设计里 10 万级以上更稳妥。明文密码只出现在初始化脚本里，不落到数据库。
初始化部门岗位可以这样写：
INSERT INTO department (name, manager) VALUES ('行政部', 'A同学'), ('技术部', 'B同学'), ('财务部', 'C同学'); INSERT INTO position (name, level, base_salary, dept_id) VALUES ('行政专员', 1, 5000.00, 1), ('Python开发', 3, 9000.00, 2), ('会计', 2, 7000.00, 3);插入完再启动程序，登录页用管理员账号进去，先建一个员工，再查一次列表，最后加一条薪资记录。这个顺序能同时验证employee、salary和界面刷新链路。如果登录成功但主界面表格空白，先查employee表有没有数据，再查查询条件是不是默认带了status = 1。初始账号建议首次登录后改密码，课程设计答辩时也不至于把密码写在 PPT 上。
3. 核心模块拆解：一次员工档案新增请求在 Python 与 MySQL 之间怎么走
员工信息管理系统看起来是表单加表格，真正容易出问题的是“一次新增”背后的链路：界面收集参数，service 校验，dao 执行 SQL，数据库约束兜底，异常再回到界面。把这条件链路拆开看，后面加字段、加审批、加导入导出都有地方下手。
3.1 数据库连接封装：PyMySQL 连接池与上下文管理
课程设计项目不一定上连接池，但连接一定要有统一的打开和关闭方式。最常见的事故是 DAO 里conn.commit()写了一半，异常分支直接return，连接没关，跑几次就卡住。用上下文管理器包一层，提交、回滚、关闭集中处理。
# db.py import pymysql from contextlib import contextmanager from config import DB_CONFIG @contextmanager def get_conn(): conn = pymysql.connect(**DB_CONFIG) try: yield conn conn.commit() # 正常结束统一提交 except Exception: conn.rollback() # 任何异常回滚，避免半条数据 raise finally: conn.close() # 一定要关连接 def query_all(sql, params=None): with get_conn() as conn: with conn.cursor() as cur: cur.execute(sql, params or ()) return cur.fetchall()这段代码的逻辑是：进入with时建立连接，业务代码执行 SQL，正常退出提交，异常退出回滚，最后关闭连接。params or ()让不传参数的查询也能执行。参数上，DB_CONFIG里的cursorclass已经指定了DictCursor，所以fetchall()返回字典列表；charset必须是utf8mb4，和建库语句保持一致。
如果项目查询很频繁，可以在这一层加一个简单的连接池，但课程设计规模没必要上复杂池化。更值得做的是把query_all、execute、query_one三个函数写全，DAO 层只关心 SQL，不关心连接生命周期。遇到“程序跑一会儿就卡死”的问题，先查这里有没有漏关连接，比查界面事件快得多。
3.2 员工新增：参数校验、唯一约束与事务边界
新增员工是整套系统里最典型的写操作。界面传过来的字典可能缺字段、工号重复、部门 ID 不存在，这些都不应该等到数据库报错才提示。service 层先做必填和格式校验，dao 层再执行插入，数据库唯一索引做最后一道保险。
# service/employee_service.py import re import pymysql from db import get_conn def create_employee(data: dict) -> int: required = ["emp_no", "name", "dept_id", "position_id", "hire_date"] for key in required: if not str(data.get(key, "")).strip(): raise ValueError(f"{key} 不能为空") if not re.match(r"^[A-Za-z0-9-]{4,20}$", data["emp_no"]): raise ValueError("工号只能是 4 到 20 位字母、数字或短横线") try: with get_conn() as conn: with conn.cursor() as cur: # 先确认部门存在，给出比外键报错更友好的提示 cur.execute("SELECT id FROM department WHERE id=%s", (data["dept_id"],)) if not cur.fetchone(): raise ValueError("部门不存在") sql = """ INSERT INTO employee (emp_no, name, gender, phone, email, dept_id, position_id, hire_date, status) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, 1) """ cur.execute(sql, ( data["emp_no"], data["name"], data.get("gender"), data.get("phone"), data.get("email"), data["dept_id"], data["position_id"], data["hire_date"], )) return cur.lastrowid except pymysql.err.IntegrityError as exc: # 唯一索引冲突通常来自工号重复 raise ValueError("工号已存在，请换一个") from exc这段代码分三层拦截：必填校验、工号格式校验、部门存在性校验。cur.lastrowid返回新员工主键，界面可以用它刷新详情。IntegrityError单独捕获，把数据库的英文报错转成中文提示。参数上，data.get("gender")这类可空字段允许不传，hire_date要求YYYY-MM-DD格式，传错会在数据库层报日期错误，界面最好用日期控件兜住。
事务边界放在get_conn()里，插入成功才提交，插入失败自动回滚。这里没有多表写入，所以事务看起来不显眼；等到后面加“员工入职同时生成薪资初始化记录”，这个边界就很重要了。课程设计里经常出现员工表插进去了、薪资表没插进去，最后对不上账，血泪经验就是写操作尽量走同一个上下文。
3.3 分页查询与条件检索：把 WHERE 拼接做成可控的 SQL
员工列表要支持姓名、工号、部门筛选，还要分页。最容易写错的不是 SQL 语法，而是把用户输入直接拼进WHERE，轻则查不出数据，重则被一条带引号的字符串搞崩。正确做法是条件子句由代码控制，值全部用参数占位。
# dao/employee_dao.py def search_employees(keyword="", dept_id=None, page=1, size=10): where = ["e.status = 1"] params = [] if keyword: # 关键字只匹配姓名和工号，占位符由驱动转义 where.append("(e.name LIKE %s OR e.emp_no LIKE %s)") like = f"%{keyword}%" params.extend([like, like]) if dept_id: where.append("e.dept_id = %s") params.append(dept_id) where_sql = " AND ".join(where) offset = (page - 1) * size sql = f""" SELECT e.id, e.emp_no, e.name, d.name AS dept_name, p.name AS position_name, e.hire_date FROM employee e JOIN department d ON d.id = e.dept_id JOIN position p ON p.id = e.position_id WHERE {where_sql} ORDER BY e.id DESC LIMIT %s OFFSET %s """ params.extend([size, offset]) return query_all(sql, params)这段代码里，where列表只拼固定片段，用户输入全部进params。LIKE %s的通配符放在值里，不放 SQL 里。LIMIT %s OFFSET %s也走参数，page从 1 开始，size控制每页条数。参数上，dept_id为空表示不按部门筛，keyword为空表示查全部在职员工。
分页还要配一个总数查询，否则界面不知道有几页。总数 SQL 用同样的where_sql，但不要ORDER BY和LIMIT。如果数据量很小，先查全量再切片也能跑，但课程设计答辩时老师问“数据多了怎么办”，有LIMIT和COUNT更站得住。注意LIKE '%关键字%'前面的%会让普通索引失效，姓名搜索数据量大时会慢，后面第 4 章会讲怎么取舍。
3.4 登录与权限：密码哈希、会话状态和角色字段
登录模块不要存明文密码，这一点没有商量余地。课程设计里常见password VARCHAR(32)直接存admin123，查库一眼就能看到。改成哈希之后，登录逻辑变成“取盐、重算摘要、恒定时间比较”，代码不多，但能避免很多低级问题。
# service/auth_service.py import hashlib import hmac from db import query_all def verify_password(password: str, stored: str) -> bool: # stored 格式：盐的十六进制$摘要的十六进制 salt_hex, digest_hex = stored.split("$", 1) salt = bytes.fromhex(salt_hex) digest = hashlib.pbkdf2_hmac("sha256", password.encode("utf-8"), salt, 120000) return hmac.compare_digest(digest.hex(), digest_hex) def login(username: str, password: str): rows = query_all( "SELECT id, username, password_hash, role, employee_id FROM users WHERE username=%s", (username,), ) if not rows: raise ValueError("用户名或密码错误") user = rows[0] if not verify_password(password, user["password_hash"]): raise ValueError("用户名或密码错误") # 会话状态由界面层保存，角色决定能看到哪些菜单 return { "user_id": user["id"], "username": user["username"], "role": user["role"], "employee_id": user["employee_id"], }这段代码的关键是hmac.compare_digest，它用恒定时间比较摘要，避免普通==带来的时序差异。stored.split("$", 1)把盐和摘要分开，盐是十六进制字符串，转回字节再参与计算。参数上，role可以设计成admin、clerk两类，管理员能改薪资，普通文员只能看档案。employee_id关联员工表，方便后续做“我的信息”页面。
会话状态不要放数据库连接里，也不要用全局变量到处传。桌面端可以在主窗口对象上挂一个current_user字典，Web 端放 session。课程设计不要求完整 RBAC，但至少做到未登录不能进主界面，普通角色看不到薪资修改按钮。界面隐藏按钮只是体验，service 层还要再判一次角色，否则改个参数就能绕过。
3.5 统计报表：一条 GROUP BY 查询怎么变成界面数字
员工统计常见两个指标：每个部门的人数、每个月的平均薪资。这两个数字用一条GROUP BY就能出来，但要注意LEFT JOIN保留空部门，AVG会自动忽略 NULL。下面这条 SQL 可以直接给统计页用。
-- 按部门统计在职人数和指定月份的平均薪资 SELECT d.name AS dept_name, COUNT(e.id) AS headcount, AVG(s.total) AS avg_salary FROM department d LEFT JOIN employee e ON e.dept_id = d.id AND e.status = 1 LEFT JOIN salary s ON s.employee_id = e.id AND s.month = %s GROUP BY d.id, d.name ORDER BY headcount DESC;这条查询的逻辑是：以部门为主表，左连接在职员工，再左连接指定月份的薪资记录。COUNT(e.id)只数有员工的行，空部门显示 0；AVG(s.total)只对有薪资记录的人求平均，没有记录的部门返回 NULL。参数%s传2025-06这种月份字符串。界面拿到Decimal类型后要转成浮点数再格式化，否则表格里可能显示一长串小数。
如果统计页还要看岗位分布，再补一条按position_id分组的查询，不要试图一条 SQL 返回所有维度。课程设计里数据量不大，两条查询足够。把统计 SQL 放在dao/report_dao.py，界面只负责把结果填进表格或图表。后面加导出 Excel 时，直接复用这两个查询结果，不用再写一遍业务逻辑。
4. 数据库设计复盘：表关系、索引和那些课程设计里最容易漏的约束
员工信息管理系统的功能不复杂，但数据库设计最能体现课程设计的水平。表关系清不清楚、约束有没有兜住、索引有没有加对，决定了后面加功能时是顺手还是拆墙。这一章不重复建表语句，专门看几个容易被忽略的取舍。
4.1 员工主表与部门岗位的关联：外键要不要开
课程设计里常见两种极端：一种是不建外键，员工表里随便填dept_id，删部门也不管；另一种是外键全开，但删除逻辑没写，界面上一点删除就报错。比较稳妥的做法是核心关系开外键，删除策略按业务选RESTRICT或CASCADE，界面提前给出提示。
员工表里的dept_id和position_id是必填外键，部门被员工引用时不能直接删，这是RESTRICT的价值。薪资和考勤挂在员工下，删员工时连带删除明细，用CASCADE更合理。外键不是用来替代业务校验的，service 层仍然要先查部门是否存在，给出“部门不存在”这种可读提示，而不是把1452 Cannot add or update a child row直接抛给用户。
-- 删除部门前先查引用，避免直接撞外键 SELECT COUNT(*) AS cnt FROM employee WHERE dept_id = %s; -- 没有员工引用时才执行删除 DELETE FROM department WHERE id = %s;这段检查的逻辑是“先查后删”，参数分别是部门 ID。COUNT(*)大于 0 时界面提示“该部门下还有员工，不能删除”。如果业务允许软删除，可以在department加status字段，删除变成更新状态，外键继续保留。课程设计答辩时，老师很可能会问“删除部门时员工怎么办”，提前把这条链路讲清楚比现场 debug 强。
4.2 索引怎么加：工号、姓名、部门 ID 的查询差异
索引不是越多越好。员工表上，emp_no有唯一索引，等值查询很快；dept_id上加了普通索引，按部门筛选能走索引；name上的普通索引对LIKE '%张%'这种前置通配符帮助不大。课程设计里数据少，感不感知得到无所谓，但设计报告里要能解释清楚。
| 查询场景 | 可用索引 | 说明 |
|---|---|---|
WHERE emp_no = ? | uk_emp_no | 唯一索引，等值命中 |
WHERE dept_id = ? | idx_employee_dept | 部门筛选常用 |
WHERE name LIKE '张%' | idx_employee_name | 前缀匹配可能命中 |
WHERE name LIKE '%张%' | 无有效索引 | 前置通配符导致全表扫描 |
ORDER BY id DESC LIMIT 10 | 主键 | 分页按主键排序成本低 |
如果列表默认按入职时间倒序，可以加idx_employee_hire_date，但不要给每个字段都建索引。写操作多的时候，索引维护也有成本。比较务实的做法是先把高频查询列出来，再决定加哪几个。EXPLAIN是验证索引是否生效的工具，跑一条查询看type和key列，比凭感觉猜靠谱。
EXPLAIN SELECT e.id, e.name FROM employee e WHERE e.dept_id = 2 AND e.status = 1 ORDER BY e.id DESC LIMIT 10;这条EXPLAIN用来观察部门筛选有没有走idx_employee_dept，排序有没有额外文件排序。参数换成实际部门 ID 即可。如果key是 NULL，说明优化器没选索引，数据量小的时候正常，数据量大就要考虑联合索引(dept_id, status, id)。课程设计不要求调优到极致，但至少要能说出“为什么这个字段加索引”。
4.3 薪资与考勤表：历史记录和当前状态的拆法
薪资和考勤最容易犯的错是把“当前值”和“历史记录”混在一张表里。员工表里放一个current_salary，发一次工资改一次，历史就没了；考勤表里只存当天状态，月底统计又拿不到整月数据。正确做法是薪资按employee_id + month唯一，考勤按employee_id + work_date唯一，每次记录都是历史的一部分。
-- 查某员工最近六个月的薪资 SELECT month, base, bonus, deduction, total FROM salary WHERE employee_id = %s ORDER BY month DESC LIMIT 6; -- 查某部门某月的考勤异常次数 SELECT e.name, COUNT(*) AS abnormal_count FROM attendance a JOIN employee e ON e.id = a.employee_id WHERE e.dept_id = %s AND a.work_date BETWEEN %s AND %s AND a.status <> '正常' GROUP BY e.id, e.name;第一条查询按员工 ID 取最近六个月，month是CHAR(7)，倒序排列即可。第二条按部门和时间范围统计异常次数，BETWEEN包含首尾日期。参数上，时间范围建议由界面选择月初和月末，不要用字符串拼接。薪资表的total可以由base + bonus - deduction算出来，也可以在插入时算好存进去，课程设计里存下来更方便报表查询，但要在 service 层保证计算一致。
考勤状态不要用太多枚举值，正常、迟到、早退、请假、缺卡这几类够用。状态字段用VARCHAR(16)比TINYINT可读性好，课程设计展示时更直观。如果后面要加请假审批，再单独建leave_request表，不要往考勤表里塞审批流字段。
4.4 初始化 SQL 与迁移脚本：让同学拿到就能建库
一套源码能不能被同学顺利跑起来，很大程度上取决于 SQL 脚本组织。把建库建表、初始数据、后续变更分开，后面加字段时不用重新导全库。常见做法是sql/init.sql负责结构和基础数据，sql/seed.sql负责演示数据，sql/migrations/放增量脚本。
| 脚本 | 作用 | 执行时机 |
|---|---|---|
sql/init.sql | 建库、建表、基础部门岗位 | 首次部署 |
sql/seed.sql | 演示员工、薪资、考勤 | 需要样例数据时 |
sql/migrations/001_add_audit.sql | 增加审计日志表 | 二次开发升级 |
迁移脚本要写成可重复执行的形式，至少做到“执行前先判断”。MySQL 里可以用CREATE TABLE IF NOT EXISTS，加字段没有IF NOT EXISTS时可先查information_schema。课程设计不要求上迁移框架，但把变更脚本按序号命名，答辩时能说清楚每一步改了什么。初始化脚本里不要写死本机绝对路径，也不要把密码写进去，导入命令由使用者自己执行。
5. 避坑与排查：源码跑不起来时，先查这五个地方
员工信息管理系统这类课程设计源码，报错大多集中在环境、连接、字符集、外键和界面刷新五类。下面这五条踩坑记录按“现象、原因、解决”写，基本覆盖从第一次启动到增删改查能用之间最常见的卡点。
5.1 现象：启动报 ModuleNotFoundError: No module named 'pymysql'
原因：依赖装到了系统 Python，当前终端跑的却是另一个解释器；或者虚拟环境创建了但没激活。Windows 上尤其常见，pip install pymysql成功，python main.py还是找不到模块，因为pip和python指向不同目录。
解决：先确认解释器和 pip 是不是一对。用下面三条命令看路径，再决定用python -m pip安装。
# 看当前 python 路径 python -c "import sys; print(sys.executable)" # 看 pip 对应哪个 python pip -V # 用当前解释器安装，避免 pip 和 python 不匹配 python -m pip install pymysqlsys.executable输出的是当前解释器绝对路径，pip -V会显示 pip 绑定的 Python 路径，两者目录一致才说明是一套。python -m pip install pymysql比直接pip install更稳，它强制用当前解释器装包。如果源码用了mysql-connector-python，把包名换掉即可，不要同时装两个驱动还混着 import。装完再跑一次python -c "import pymysql; print(pymysql.__version__)"，能打印版本才算装对。
5.2 现象：1045 Access denied for user 'root'@'localhost'
原因：config.py里的密码不对，或者 MySQL 只允许localhost登录，而代码连的是127.0.0.1；也有可能是 MySQL 服务根本没启动。报错里的using password: YES表示带了密码但被拒绝，using password: NO表示没读到密码。
解决：先用命令行客户端验证同一组账号密码能不能连上，再回头改配置。
# 先确认 MySQL 服务在运行，再测试连接 mysql -h 127.0.0.1 -P 3306 -u root -p # 如果能连上，检查 config.py 里的 host、port、user、password # 注意环境变量 DB_PASSWORD 可能覆盖了默认值命令行能连、Python 连不上，重点查环境变量和配置文件加载顺序。os.getenv("DB_PASSWORD", "123456")只要环境里存在DB_PASSWORD，默认值就不生效。可以在启动前打印一次配置，但不要把密码完整打印到日志里。密码里含@、#这类字符时，命令行和配置文件都要注意转义，最省事的办法是先用简单密码排除变量。
5.3 现象：插入中文报 1366 Incorrect string value，或者界面显示问号
原因：数据库、表、连接三处字符集不一致。建库用了utf8mb4，表可能还是latin1；连接配置写了utf8，和表的utf8mb4不匹配；或者客户端终端编码不对。中文姓名、部门名一进去就变问号，后面查询条件也跟着失效。
解决：从库到连接逐层检查，统一成utf8mb4。
-- 查看库、表、连接相关字符集 SHOW VARIABLES LIKE 'character_set%'; SHOW CREATE TABLE employee; -- 已有表改成 utf8mb4 ALTER TABLE employee CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; ALTER TABLE department CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;SHOW VARIABLES LIKE 'character_set%'里重点看character_set_database、character_set_client、character_set_connection。SHOW CREATE TABLE看表定义末尾的CHARSET。连接配置里的charset必须写utf8mb4，不能只写utf8。改完表之后，旧连接要重开，程序重启一次再试。终端本身如果是 GBK，命令行插入中文也可能乱，尽量用图形客户端或者 Python 脚本导入初始数据。
5.4 现象：1451 Cannot delete or update a parent row: a foreign key constraint fails
原因：删除部门或岗位时，员工表里还有记录引用它。外键策略是RESTRICT，数据库直接拒绝删除。这个报错本身是保护，不是 bug；真正的问题是界面没有提前提示，用户看到英文错误不知道怎么办。
解决：删除前先查引用数量，有引用就提示，或者改成软删除。
-- 删除部门前查引用 SELECT COUNT(*) AS cnt FROM employee WHERE dept_id = %s; -- 如果业务允许软删除，给部门加状态字段 ALTER TABLE department ADD COLUMN status TINYINT NOT NULL DEFAULT 1; UPDATE department SET status = 0 WHERE id = %s;COUNT(*)大于 0 时不要执行DELETE，界面弹窗提示“该部门下还有员工”。软删除的做法是把status置 0，查询部门下拉框时只取status = 1的记录，历史员工仍然能关联到原部门。课程设计里两种都能接受，关键是删除按钮背后要有判断，不能把数据库报错直接甩给用户。血泪经验是：外键报错不可怕，可怕的是为了“能删”把外键全关了，最后员工表里一堆不存在的部门 ID。
5.5 现象：新增员工成功，但列表不刷新；或者改完数据再查还是旧值
原因：界面层没有在写入成功后重新查询；或者事务没提交，连接关闭时回滚了；也有可能是分页参数还停留在旧页码，新员工排在后页看不到。桌面端还常见 UI 线程里执行了长查询，界面卡住让人以为没刷新。
解决：把“写入”和“刷新”绑在同一个事件处理里，写入成功后重置到第一页再查。
# ui/employee_page.py 里的新增回调示例 def on_add_success(self): # 新增后回到第一页，按默认排序能看到最新记录 self.page = 1 self.load_table() def on_add_clicked(self): data = self.form.get_data() try: employee_service.create_employee(data) self.on_add_success() except ValueError as exc: self.show_error(str(exc))这段代码的逻辑是：service 返回成功才刷新，失败只提示不刷新。self.page = 1避免新记录在最后一页看不到，load_table()重新走查询。参数上，form.get_data()要确保字段名和 service 里的required一致。如果刷新后仍然没有，查get_conn()有没有提交，或者employee表的status是不是被写成了 0。别在 UI 线程里 sleep 等数据库，桌面端卡顿多半是查询太重或者连接没关。
6. 二次开发落地：给员工系统加一个“离职审批 + 操作审计”的改造思路
课程设计源码跑通之后，最值得练手的二次开发不是换界面皮肤，而是加一条带状态流转的业务。离职审批比新增员工更接近真实系统：员工有在职、待离职、已离职状态，审批动作要写审计日志，还要保证更新和日志在同一个事务里。下面这套改法不重，足够把 service 层和数据库设计串起来。
6.1 先改表再改代码：新增字段与状态机
先给employee加离职状态和原因，再建一张审计日志表。状态字段用TINYINT或VARCHAR(16)都行，关键是取值固定：1在职、2待审批、3已离职。审计表记录谁在什么时间把哪个员工从什么状态改成了什么状态。
ALTER TABLE employee ADD COLUMN leave_status TINYINT NOT NULL DEFAULT 1, ADD COLUMN leave_reason VARCHAR(255) DEFAULT NULL; CREATE TABLE audit_log ( id INT PRIMARY KEY AUTO_INCREMENT, operator VARCHAR(32) NOT NULL, action VARCHAR(32) NOT NULL, target_id INT NOT NULL, before_status TINYINT, after_status TINYINT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB;这段 SQL 的leave_status默认 1，老数据不受影响；leave_reason允许为空。audit_log不挂外键到员工表，避免员工删除后日志跟着消失，target_id只存业务 ID。执行前先备份，课程设计里也可以把这两段放进sql/migrations/001_add_leave.sql。
6.2 审批流的轻量实现：service 层加一个状态流转方法
审批方法只做三件事：校验当前状态、更新员工状态、写审计日志。三件事放在同一个get_conn()上下文里，任何一步
本文还有配套的精品资源，点击获取
