简介：一套基于Java+SQLServer2008的网上书店管理系统课程设计项目，面向Java Web初学者及需完成课程设计、毕业设计的学生，实现会员在线购书与书店后台管理一体化。压缩包共460个文件，含198个gif动态图、88个jsp页面、76个jpg界面截图、29个java源文件与class编译文件，另附sql数据库脚本及xml配置等，整体约9.89MB，目录分层清晰，便于按模块取用。系统完整覆盖游客注册、图书检索、会员登录、购物车下单、订单查询，以及管理员图书维护、会员管理、订单审核发货、新闻与评论管理等功能，体现前台销售与后台管理双层架构。资源内提供项目源码、数据库脚本、页面素材与演示动画，可辅助理解JSP+Servlet+SQLServer开发流程、购物车与订单状态处理等关键实现。已有375人学习下载，适合作为课程设计参考或Java Web综合练手项目。
1. 网上书店系统是经典课设，但 Java+SQLServer2008 这套组合在真实简历里并不丢人
很多人一听到 SQLServer2008，第一反应是「这都什么年代了还用它」。可如果你打开招聘网站搜 java 面试题和 java 基础，会发现大量企业内部的 Web 系统仍然跑在 Windows Server + SQLServer 2008 R2 上。原因很简单：很多出版社、图书经销商的进销存系统是十多年前做的，数据库从 2000 升级到 2008 后就再没动过。基于 Java+SQLServer2008 实现 Web 网上书店管理系统，这个题目既覆盖了 JSP/Servlet、JDBC、事务、存储过程这些 java 基础里绕不开的点，又逼你把 SQLServer 2008 的方言搞明白——恰恰是面试八股文里最容易翻车的部分。
这篇文章我按自己做课设和给企业做小项目的习惯来讲，先给完整架构和建表脚本，再落登录、图书检索、购物车、下单扣库存这些核心功能。你会发现这套组合的难点不在 Java 而在数据库：SQLServer 2008 没有 OFFSET-FETCH，没有 STRING_AGG，没有延迟持久性，很多网上抄来的 MySQL 写法直接跑不通。我尽量把每个坑都指出来，让你照着做能一次跑通。
2. 先把架构立住：从 JSP/Servlet 到 SSM 的选型理由与数据库设计
2.1 为什么是这个组合，而不是 Spring Boot + MySQL
如果只看功能，网上书店管理系统用 Spring Boot + MySQL 五分钟就能把 CRUD 写出来。但课设或企业交接项目里指定 SQLServer2008，通常不是为了炫技，而是因为目标服务器上已经装好了 SQLServer 2008 R2，或者对接的旧系统只认这个库。所以技术选型的第一原则不是「哪个新用哪个」，而是「哪个在目标环境里跑得稳」。
常见做法是用轻量的三层架构：Web 层用 JSP + Servlet，业务层用普通 Java 类，数据层用 JDBC + 连接池，项目打成 WAR 包丢到 Tomcat 7 或 Tomcat 8。这套东西不需要 Spring 容器就能跑，对新手友好得多，也方便在答辩时讲清楚每一步。如果你更习惯 Spring，可以留到后期再加 Spring MVC，但数据库访问层我仍然建议 JDBC 而非 MyBatis——因为 SQLServer 2008 有一些方言特性，用 JDBC 直接写 SQL 能让你精确控制锁和事务，排查问题也少一层黑匣子。
有人问要不要用 Hibernate 自动建表。我的建议是不要。网上书店的订单表、库存表都有外键和约束，自动建表生成的索引和字段类型经常和存储过程对不上。老老实实用 SQL 脚本建表，以后写存储过程、做 Profiler 调优都看得见摸得着。
2.2 五张核心表的建表脚本：把订单状态机先定死
我一般会把表拆成五张：用户表、图书表、分类表、订单表、订单明细表。另外再加一张购物车表，但购物车我后面会讲它可能不落库。这里先给出最小可用的建表脚本，注意 SQLServer 2008 不支持NVARCHAR(MAX)以外的许多新语法，但下面这些写法都是 2008 能直接跑的。
-- 用户表 CREATE TABLE dbo.users ( user_id INT IDENTITY(1,1) PRIMARY KEY, login_name NVARCHAR(50) NOT NULL UNIQUE, password_hash NVARCHAR(128) NOT NULL, -- 存 SHA-256 十六进制串，不存明文 real_name NVARCHAR(50) NULL, phone NVARCHAR(20) NULL, created_at DATETIME NOT NULL DEFAULT GETDATE() ); -- 图书分类表 CREATE TABLE dbo.category ( cid INT IDENTITY(1,1) PRIMARY KEY, cname NVARCHAR(50) NOT NULL, parent_id INT NULL DEFAULT 0 -- 0 表示一级分类 ); -- 图书表 CREATE TABLE dbo.book ( book_id INT IDENTITY(1,1) PRIMARY KEY, cid INT NOT NULL REFERENCES dbo.category(cid), book_name NVARCHAR(100) NOT NULL, author NVARCHAR(50) NULL, publisher NVARCHAR(80) NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, sales_count INT NOT NULL DEFAULT 0, is_on_sale TINYINT NOT NULL DEFAULT 1, create_time DATETIME NOT NULL DEFAULT GETDATE() ); -- 订单表 CREATE TABLE dbo.orders ( order_id INT IDENTITY(1,1) PRIMARY KEY, order_no NVARCHAR(32) NOT NULL UNIQUE, -- 业务订单号，见 4.2 user_id INT NOT NULL REFERENCES dbo.users(user_id), total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0待支付 1已支付 2已发货 3已完成 4已取消 pay_time DATETIME NULL, create_time DATETIME NOT NULL DEFAULT GETDATE() ); -- 订单明细表 CREATE TABLE dbo.order_item ( item_id INT IDENTITY(1,1) PRIMARY KEY, order_id INT NOT NULL REFERENCES dbo.orders(order_id), book_id INT NOT NULL REFERENCES dbo.book(book_id), book_name NVARCHAR(100) NOT NULL, -- 冗余快照，防止图书改名影响历史订单 price DECIMAL(10,2) NOT NULL, -- 下单时快照价格 qty INT NOT NULL );这段脚本有三个点值得细说。第一，订单明细冗余了book_name和price，这是做电商系统的基本功——订单是快照，历史订单不能因为商品信息变更而改变。第二，orders.status用 TINYINT 表示状态机，靠应用层控制状态流转，比单纯用字符串更省空间，也方便写 SQL 统计。第三，stock用 INT，因为后续扣库存要配合事务和行锁，如果设计成无符号类型反而会让 JDBC 的getInt出现负数问题，得不偿失。
2.3 JDBC 连接池与事务边界：三层架构里最容易写废的一层
网上书店这种系统并发量不高，但连接池一定要配。因为 SQLServer 2008 默认允许的最大连接数是 32767，但每次新建数据库连接的开销在局域网内也要几十毫秒，高并发下单时如果每次都DriverManager.getConnection，数据库会频繁做登录认证，压测时 TPS 能差 5 倍以上。
我常用 DBCP 或 C3P0，虽然 Spring Boot 项目里推荐 HikariCP，但我们的目标环境是 Tomcat 7，DBCP 直接内嵌，零额外依赖。连接池参数我比较保守：初始 5，最大 20，maxWaitMillis设 3000，validationQuery用SELECT 1。SQLServer 2008 的SELECT 1没有性能问题，但要注意连接空闲超过 8 小时会被数据库端的登录超时掐断，所以必须配testWhileIdle=true和timeBetweenEvictionRunsMillis=60000，否则第二天上班第一个请求必报Connection is closed。
事务边界要划在三层架构的 Service 层，不要在 Servlet 里写conn.setAutoCommit(false)。因为一个 Servlet 可能调用多个 Service，比如「提交订单」要先写订单表、扣库存、写明细，这三个操作要么全成功要么全失败。我在 Service 用ThreadLocal持有当前线程的 Connection，保证同一个 Service 方法内的所有 DAO 都拿到同一个连接，提交或回滚都在 Service 层统一控制。这个模式看起来老，但非常稳，你后面换成 Spring 的@Transactional时也能快速理解它的原理。
3. 在 Web 工程里跑通用户登录与图书检索：最小可运行代码
3.1 项目骨架与 Maven 依赖：快照依赖别乱升
不管你是用 IDE 新建 Maven Web 项目还是手工建 Dynamic Web Project，最终结构建议是这样：src/main/java放 Servlet 和工具类，src/main/webapp放 JSP，src/main/resources放数据库配置。如果你是在校生做课设，没装 Maven 也可以直接用 Tomcat 的lib目录，但 Maven 能让你省掉到处找 jar 的麻烦。
这里只给三个关键依赖：javax.servlet-api（provided 作用域）、sqljdbc4驱动、commons-dbcp连接池。注意 SQLServer 的 JDBC 驱动在 Maven 中央仓库没有官方坐标，我一般把sqljdbc4.jar手动mvn install到本地仓库。
<dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.0.1</version> <scope>provided</scope> </dependency> <dependency> <groupId>commons-dbcp</groupId> <artifactId>commons-dbcp</artifactId> <version>1.4</version> </dependency>驱动这里要特别提醒：SQLServer 2008 配套的驱动是sqljdbc4，支持 JDBC 4.0，用Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver")加载即可。有些教程让你用sqljdbc或jtds，jtds 虽然兼容性好，但处理datetime和金额精度时偶尔行为不一致，我建议就用微软官方的 sqljdbc4，别在驱动上省事。Maven 依赖配好后，记得把 scope 设为provided的 servlet-api 排除出 WAR 包，Tomcat 自己带了一份，带上会造成类冲突。
3.2 登录接口：把 SQLServer 的密码散列和会话一起管起来
用户登录是最常见的入门功能，但也最容易出现「把明文密码存库」和「SQL 拼接注入」两个问题。我给出的做法是：密码用 SHA-256 加盐散列，登录时先查用户再比对散列值，不用数据库的对称加密函数，因为数据库函数的结果在跨实例迁移时可能不一致。
@WebServlet("/login") public class LoginServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String loginName = req.getParameter("loginName"); String password = req.getParameter("password"); if (loginName == null || password == null || loginName.trim().isEmpty() || password.trim().isEmpty()) { resp.sendError(400, "参数不完整"); return; } UserDao dao = new UserDao(); User user = dao.findByLoginName(loginName.trim()); String salt = "bookstore2024"; // 实际系统里每个用户独立盐值，存用户表 String hash = DigestUtils.sha256Hex(salt + password); if (user != null && user.getPasswordHash().equalsIgnoreCase(hash)) { HttpSession session = req.getSession(true); session.setAttribute("loginUser", user); session.setMaxInactiveInterval(30 * 60); resp.sendRedirect(req.getContextPath() + "/book/list"); } else { req.setAttribute("error", "用户名或密码错误"); req.getRequestDispatcher("/login.jsp").forward(req, resp); } } }这段代码的关键在三点。第一，DigestUtils.sha256Hex用 commons-codec，避免自己写 Byte 数组转十六进制的坑。第二，验证通过后不手动写 JSON 返回，而是直接sendRedirect，这是 Web 应用的常规流程——页面跳转让浏览器发起新请求，避免刷新时重复提交表单。第三，Session 超时设 30 分钟，并在后续订单提交前用过滤器统一检查loginUser是否存在，这比每个 Servlet 里重复判断要干净。
有个细节新手常踩：SQLServer 的字段排序规则如果是Chinese_PRC_CI_AS，那么equalsIgnoreCase和数据库的=对大小写的判断可能不一致。你会遇到「Java 里比对通过，数据库里查出来却是两条记录」的怪事。解决办法很简单，应用层只负责散列比对，不参与数据库的排序规则判断；建表时login_name加UNIQUE约束就够，不需要特意把排序规则改成CS_AS，因为系统里根本不该有两个仅有大小写差异的用户名。
3.3 图书分类与分页检索：TOP 分页在 SQLServer 2008 下的写法
图书列表页是网上书店的门面，必须支持按分类筛选、按书名模糊搜索、分页。SQLServer 2008 不支持LIMIT ? OFFSET ?，也不能用ROW_NUMBER()以外的窗口函数写法——不对，2008 其实是支持ROW_NUMBER()的，但写法比 MySQL 繁琐。最常见的是ROW_NUMBER() OVER (ORDER BY book_id)配合子查询分页。
SELECT * FROM ( SELECT ROW_NUMBER() OVER (ORDER BY b.book_id DESC) AS rn, b.book_id, b.book_name, b.author, b.price, b.stock, c.cname FROM dbo.book b INNER JOIN dbo.category c ON b.cid = c.cid WHERE b.is_on_sale = 1 AND (@cid = 0 OR b.cid = @cid) AND (@keyword = '' OR b.book_name LIKE '%' + @keyword + '%') ) AS t WHERE t.rn > 10 AND t.rn <= 20这段 SQL 的@cid和@keyword要作为 PreparedStatement 参数传入。为什么不建议动态拼接 WHERE 再执行？因为 SQLServer 的查询计划缓存会按 SQL 文本匹配，参数化查询能复用执行计划，拼接的 SQL 每次都不一样，缓存命中率低，并发稍高就会 CPU 飙升。另外LIKE '%' + @keyword + '%'这种写法无法用普通索引，数据量超过十万就要考虑全文索引，但网上书店课设到不了那个量级，不用过度设计。
Java 端调用时记得用setInt和setString，不要用setObject依赖驱动猜测类型。SQLServer 2008 的 JDBC 驱动对setObject传null有时会传成NVARCHAR默认值，导致参数类型不匹配或隐式转换报错。我有一个血泪经验：所有日期字段统一用java.sql.Timestamp传入，所有金额统一用BigDecimal，时间久了你会发现这能省下无数「莫名其妙的类型不匹配」。
3.4 购物车用 Session 还是表：两种方案的取舍
购物车实现有两个流派。课设里最省事的是放 Session，用户把书加进购物车，刷新页面、关浏览器重开就没了，但胜在不用建表。企业角度看，购物车一般要落库，因为用户可能换设备继续购买。我的建议是：如果标题只要求「网上书店管理系统」，购物车放 Session 完全够用，而且好答辩——你可以说这是为了减轻数据库压力；但如果你的项目简历上写着「分布式会话共享」，那就要用 Redis，SQLServer 只存最终订单。
用 Session 存购物车，我推荐直接存一个HashMap<Integer, Integer>，key 是book_id，value 是数量。注意不要存List<CartItem>，因为用户反复加购时你要遍历列表找相同book_id，而 Map 的put天然去重，逻辑简单很多。
// 加购接口片段 HttpSession session = req.getSession(); Map<Integer, Integer> cart = (Map<Integer, Integer>) session.getAttribute("cart"); if (cart == null) { cart = new HashMap<Integer, Integer>(); session.setAttribute("cart", cart); } int bookId = Integer.parseInt(req.getParameter("bookId")); int qty = 1; if (req.getParameter("qty") != null) { qty = Integer.parseInt(req.getParameter("qty")); } Integer old = cart.get(bookId); cart.put(bookId, old == null ? qty : old + qty);这段代码里的old == null ? qty : old + qty是关键，注意不能写成cart.getOrDefault(bookId, 0) + qty——除非你确定自己用的是 Java 8。很多课设环境还是 JDK 7，写getOrDefault会直接编译报错。另外，加购时要校验bookId存在且is_on_sale=1，我见过有人直接parseInt用户传的参数，传一个负数就进购物车，虽然最终下单时会再次校验，但最好前端和后台都做一层基本判断，别把安全性全押在最后一环。
4. 订单提交与库存扣减：SQLServer 2008 没有窗口函数也能做对
4.1 事务里先锁后改：with (updlock) 的用法
订单提交是整个系统最刺激的部分，也是 java 面试题里「怎么保证数据一致性」的标准考题。先说结论：在 SQLServer 2008 上，扣库存要用UPDATE dbo.book WITH (UPDLOCK, ROWLOCK) SET stock = stock - ? WHERE book_id = ? AND stock >= ?，并放在显式事务里。UPDLOCK告诉 SQLServer 在更新前就加更新锁，而不是先加共享锁再升级；ROWLOCK防止锁升级到页锁或表锁。
为什么必须写AND stock >= ?？因为这是数据库层的乐观防超卖。先查一次库存再在应用层判断，这个「查」和「改」之间可能有另一个事务把库存改没了；而单条 UPDATE 带上库存条件，受影响行数为 0 就说明库存不足，应用层回滚事务即可。这是一个非常经典的「控制并发修改」手法，比 SELECT FOR UPDATE 更高效——FOR UPDATE 在 SQLServer 里其实对应 UPDLOCK，但直接写 UPDATE 少一次往返。
Connection conn = dataSource.getConnection(); try { conn.setAutoCommit(false); // 1. 扣库存 String deductSql = "UPDATE dbo.book WITH (UPDLOCK, ROWLOCK) " + "SET stock = stock - ? WHERE book_id = ? AND stock >= ?"; PreparedStatement psDeduct = conn.prepareStatement(deductSql); for (CartItem item : items) { psDeduct.setInt(1, item.qty); psDeduct.setInt(2, item.bookId); psDeduct.setInt(3, item.qty); int rows = psDeduct.executeUpdate(); if (rows == 0) { throw new RuntimeException("库存不足: bookId=" + item.bookId); } } // 2. 写订单、写明细（省略） conn.commit(); } catch (Exception e) { conn.rollback(); throw new RuntimeException("下单失败", e); } finally { conn.setAutoCommit(true); conn.close(); }这里有个容易翻车的地方：conn.setAutoCommit(true)一定要放在 finally 里恢复，否则连接归还连接池后仍是手动提交状态，下一个请求复用这个连接时会把别的业务逻辑也包进一个莫名的事务里。我见过线上问题就是连接池连接没重置提交状态，导致一个读操作提交了半个事务。如果你用 DBCP，可以在配置里加defaultAutoCommit=true兜底，但最可靠的还是每次用完恢复现场。
4.2 订单号的生成：时间戳+序列的拼接避开并发重复
订单号看起来简单，但自动增长 ID 直接暴露给用户会有问题：别人通过订单号差值推断你一天的订单量。我习惯用业务订单号order_no，格式是yyyyMMddHHmmss加三位随机数加用户 ID。比如20250615143022123_10086，最后一段是用户ID，这样同一个用户在同一秒内的订单至少从随机数上区分。
但随机数有碰撞可能。更稳的做法是创建一张订单号序列表，用事务里UPDATE的方式取号，避免依赖IDENTITY的间隙。不过课设阶段，我推荐一个轻量方案：时间戳精确到毫秒加上用户ID，再在数据库端做唯一约束。只要你的系统不是同一用户同一毫秒下两单，这个方案不会撞。
-- 生成订单号的 SQL 片段（Java 端拼好传入） DECLARE @order_no NVARCHAR(32); SET @order_no = CONVERT(VARCHAR(8), GETDATE(), 112) -- yyyyMMdd + REPLACE(CONVERT(VARCHAR(12), GETDATE(), 114), ':', '') + RIGHT('000' + CAST(@userId AS VARCHAR(10)), 3);这段 SQL 取的是数据库服务器当前时间，不是应用服务器时间。为什么强调用数据库时间？因为如果应用服务器和数据库服务器时间不同步，比如差了 5 分钟，你生成的订单号可能比前一个单还小，排序会乱。分布式环境当然有雪花算法，但那是另一套体系；单机 SQLServer 就用数据库时间最稳。注意114格式返回的是HH:mi:ss:mm，替换掉冒号后得到 8 位时分秒毫秒，拼接起来订单号全长 8+8+3=19 位，放到NVARCHAR(32)里绰绰有余。
4.3 用存储过程把下单三步包起来，Java 端只调一个接口
如果你只想在答辩时显得系统很专业，就把下单逻辑写成存储过程。存储过程的好处是：数据库端本地执行，避免 Java 和数据库之间多次网络往返；事务可以直接写在存储过程内部，Java 端不用手动管事务边界；SQLServer 2008 对存储过程的执行计划缓存也比对 JDBC 预编译的批处理更稳定。
CREATE PROCEDURE dbo.sp_create_order @userId INT, @orderNo NVARCHAR(32), @itemList NVARCHAR(4000), -- 格式: bookId:qty;bookId:qty @totalAmount DECIMAL(10,2) OUTPUT AS BEGIN SET NOCOUNT ON; DECLARE @bookId INT, @qty INT, @price DECIMAL(10,2); DECLARE @ptr INT = 1, @currentQty INT; SET @totalAmount = 0; IF OBJECT_ID('tempdb..#temp_items') IS NOT NULL DROP TABLE #temp_items; CREATE TABLE #temp_items (book_id INT, qty INT); -- 解析 itemList 写入临时表，此处略去解析循环 -- 检查每一项库存并扣减 DECLARE item_cursor CURSOR FOR SELECT book_id, qty FROM #temp_items; OPEN item_cursor; FETCH NEXT FROM item_cursor INTO @bookId, @qty; WHILE @@FETCH_STATUS = 0 BEGIN UPDATE dbo.book WITH (UPDLOCK, ROWLOCK) SET stock = stock - @qty WHERE book_id = @bookId AND stock >= @qty; IF @@ROWCOUNT = 0 BEGIN RAISERROR('库存不足', 16, 1); ROLLBACK; RETURN; END SELECT @price = price FROM dbo.book WHERE book_id = @bookId; SET @totalAmount = @totalAmount + @price * @qty; FETCH NEXT FROM item_cursor INTO @bookId, @qty; END CLOSE item_cursor; DEALLOCATE item_cursor; INSERT INTO dbo.orders (order_no, user_id, total_amount, status, create_time) VALUES (@orderNo, @userId, @totalAmount, 0, GETDATE()); END GO这个存储过程示例里我故意没写全解析字符串的循环，实际做的时候可以用CHARINDEX+SUBSTRING逐段解析，也可以让 Java 端直接把明细拼成 XML 传进来，用 SQLServer 的sp_xml_preparedocument解析。我的建议是简化：Java 端把bookId:qty循环调两次接口也未尝不可，但如果你想展示存储过程能力，解析部分一定要自己完整写出来并测试，别在答辩现场临时调试。
存储过程的一个副作用是调试成本高。Java 里报错你能看堆栈，存储过程报错只知道行号。所以我一般只在「下单」这种强一致性的核心路径上用存储过程，其他查询还是用 JDBC 直接写 SQL。另外，存储过程里RAISERROR后必须ROLLBACK，否则 SQLServer 会把错误返回给客户端但事务保持打开，连接池里的连接状态就脏了。
5. 部署与避坑：JDBC 驱动、端口、字符集和 SQLServer 2008 的常见问题排查
5.1 现象：ClassNotFoundException 或连接超时
class not found 一般是sqljdbc4.jar没放进 Tomcat 的lib或 WAR 包的WEB-INF/lib。很多人只把 jar 加在了 IDE 的 classpath 里，打包时没带上。解决：检查WEB-INF/lib下是否有sqljdbc4.jar，或者直接把它放到 Tomcat 的lib目录一劳永逸。另一个常见原因是 jar 包和驱动类名不匹配——老版sqljdbc.jar的类名是com.microsoft.jdbc.sqlserver.SQLServerDriver，而sqljdbc4.jar才是com.microsoft.sqlserver.jdbc.SQLServerDriver，两个驱动混用会给你制造非常低级的报错。
连接超时则要先确认 SQLServer 的 TCP/IP 协议是否启用。SQLServer 2008 安装后默认可能只开了 Shared Memory 和 Named Pipes，Java 走的是 TCP 1433。打开 SQL Server 配置管理器，找到「SQL Server 网络配置 → 协议 → TCP/IP」，右键启用，并重启 SQL Server 服务。这一步能解决 70% 的「本地能连，Java 连不上」问题。
5.2 现象：中文乱码，页面和库里都不对
中文乱码要分清是哪种。如果 JSP 页面显示乱码但数据库里正确，是 JSP 的pageEncoding和request.setCharacterEncoding没配对；如果数据库里存的就是乱码，那是 JDBC URL 没带字符集参数或建表字段类型用错了。SQLServer 2008 的 JDBC URL 要这样写：
jdbc:sqlserver://localhost:1433;DatabaseName=bookstore;sendStringParametersAsUnicode=truesendStringParametersAsUnicode=true是默认值，但一旦你把它设成 false，所有setString都会按数据库默认排序规则转换，中文大概率变问号。另外建表时字符串字段最好用NVARCHAR而不是VARCHAR，因为NVARCHAR用 UCS-2 存储，能保证 Java 的String和数据库直接对应。如果你已经建了VARCHAR表，修改字段类型要用：
ALTER TABLE dbo.book ALTER COLUMN book_name NVARCHAR(100) NOT NULL;注意ALTER COLUMN不能和约束一起改，如果字段上有索引或默认值，先删约束再改类型，改完再加回来。这个操作在测试环境先演练一遍，别在正式库上直接跑。
5.3 现象：TCP 1433 连不上，本地却能通
这是典型的 Windows 防火墙拦截。开发机上你自己的 IDE 能连，是因为 IDE 进程和 SQLServer 在同一台机器，走的是 Shared Memory；换到另一台机器跑 Tomcat 就连不上。解决：在 Windows 防火墙入站规则里放行 1433 端口，或者放行sqlservr.exe程序。
还有一种更隐蔽的原因：SQLServer 2008 的默认实例名是MSSQLSERVER，如果只安装了命名实例，JDBC URL 要写成jdbc:sqlserver://host:1433;instanceName=你的实例名。不带instanceName时驱动会在 SQL Browser 服务里找默认实例，如果 SQL Browser 没启动，就会出现「能 ping 通但连接超时」的玄学问题。我的建议是：单独实例就直接用host\实例名的方式写在 URL 的instanceName参数里，别依赖 SQL Browser。
5.4 现象：数据库文件版本比当前实例高，附加不上
这个坑概率不高但杀伤力极大。你在开发机装了 SQLServer 2008 R2，从网上下载了一个bookstore.mdf数据库文件，附加时报错「数据库版本 661 高于当前实例支持的 655」。661 是 SQLServer 2008 R2 的文件版本号，655 是 2008 SP1 的。想解决有两个办法：一个是升级你的 SQLServer 2008 到 SP3 以上，另一个是找一台高版本 SQLServer 把数据库降级备份再恢复。后者步骤麻烦，我建议直接装 2008 R2 或以上版本，课设环境的兼容性压力最小。
另外，附加数据库时mdf和ldf文件要放同一个目录，如果ldf丢失，附加时可以选择「不附加日志文件」，让 SQLServer 重建日志。但新建日志会丢失历史日志记录，对课设无所谓，对正式系统千万别这么干。网上书店系统如果从旧机器迁移数据库，最稳的方式是备份成.bak文件，然后RESTORE，不要直接拷mdf。
5.5 现象：使用 PreparedStatement 批量插入慢得离谱
往订单明细表插 50 条记录，一条一条执行就要 50 个往返，慢很正常。解决方案是用 JDBC 的批量addBatch，但 SQLServer 2008 驱动对批量插入的默认行为是逐条提交，跑起来快不了多少。真正能提效的是改 JDBC URL 加rewriteBatchedStatements=true参数——不过这个参数是 MySQL 的，SQLServer 没用。SQLServer 2008 支持表值参数（TVP），但需要 JDBC 驱动 6.0 以上，而 sqljdbc4 并不支持。
我的实践做法是：订单明细不逐条插，而是拼成一条多行 VALUES 插入。SQLServer 2008 支持INSERT INTO table VALUES ... , ...这种多行写法，但最多 1000 行。订单明细一般不会超过 1000 条，所以足够用。Java 端拼 SQL 时注意用StringBuilder，并且所有值都要来自setXxx会变得麻烦——可以改用PreparedStatement的setString拼整个 SQL，因为明细里的book_name和price来自数据库查询结果，不存在注入风险，拼接时只要注意单引号转义即可。
6. 把这些代码升级成可验收的系统：日志、幂等和压测验证
6.1 给下单接口加一个业务流水号，让重复请求只生效一次
前端的「提交订单」按钮如果没做防重复，用户双击或网络重试会让你生成两笔订单。最常见的解决办法是前端按钮置灰，但后端必须自己兜底——加一个幂等键。做法是用户打开订单确认页时，后端生成一个bizToken放进 Session，下单接口要求带上这个 token。下单成功后把 token 标记为已使用，如果在已使用状态下再收到相同 token，直接返回「订单已提交」。
这里有个细节：如果你的系统以后接微服务，Session 里的 token 不跨服务，就要换成数据库表存 token 并加唯一约束。单机课设用 Session 就够，但你要知道这个设计为什么存在——这也是 java 面试八股文里常问的「幂等性怎么保证」。
6.2 用 SQL Server Profiler 抓慢查询，先处理索引缺失
开发时数据量小，感觉不出来慢查询。验收或答辩前，我强烈建议用 SQL Server Profiler 跑一次典型流程：登录、搜索、加购、下单。Profiler 可以记录每条 SQL 的耗时和读取行数，重点看两处：
第一，图书列表页的LIKE '%keyword%'查询，扫描行数如果接近全表，就该给book_name加普通索引——加了也快不了多少，因为前置通配符用不上索引，但至少覆盖索引扫描比聚集索引扫描略好。第二，订单查询按user_id查，如果表里没有索引，全表扫描在订单量过万后就很明显。加索引 SQL 如下：
CREATE INDEX idx_book_cid ON dbo.book(cid, is_on_sale); CREATE INDEX idx_orders_user_id ON dbo.orders(user_id, create_time);注意idx_book_cid把cid放前面、is_on_sale放后面，因为查询条件是cid = ? AND is_on_sale = 1，多列索引最左前缀原则下这样能走索引。不要对book_name建太多索引，因为网上书店的搜索词无法预测，索引维护成本大于收益。
6.3 一个小工具类：模拟 50 个用户并发下单验证库存不超卖
验收系统「靠不靠谱」，最简单的方法是写一个多线程模拟并发下单。我常用的方式是 Java 的CountDownLatch让 50 个线程同时发起下单请求，每个线程买同一本书 1 件，初始库存 50，最后检查库存是否为 0、订单数是否为 50。
final int THREADS = 50; final CountDownLatch start = new CountDownLatch(1); final CountDownLatch end = new CountDownLatch(THREADS); for (int i = 0; i < THREADS; i++) { new Thread(() -> { try { start.await(); // 调用下单服务，传入固定 userId 和 bookId orderService.createOrder(1, 3, 1); } catch (Exception e) { // 记录失败数 } finally { end.countDown(); } }).start(); } start.countDown(); end.await(); // 查询最终库存和订单数，断言等于预期值跑这个测试时，如果你发现最终订单数少于 50 且库存剩余，说明你的库存扣减逻辑在并发下丢了更新；如果订单数超过 50 或者库存变成负数，说明stock >= ?条件没生效。这两个问题我在帮人排查时都见过：前者是因为代码里「先查库存再更新」没有加锁，后者是因为 UPDATE 语句漏写了库存条件。跑完并发测试再去看 Profiler 的锁等待事件，你就能直观感受到UPDLOCK和普通 UPDATE 的差别。
这个工具类建议直接放在测试包里，不要放到线上 JSP 里。我习惯写成 JUnit 测试类，用随机生成的 userId 去压测，避免污染正式用户数据。跑通之后，整个系统的核心链路——登录、搜索、加购、下单、扣库存——就都有了可验收的证据，答辩或交接时把并发测试结果一贴，比写一万字设计文档都管用。
最后说一句个人习惯：我每做完一个这种系统，都会在本地留一份完整的建表 SQL、一份 JDBC 工具类和并发测试代码，下次再碰到 SQLServer 2008 的老项目直接复用，能省掉大半踩坑时间。希望帮到你。
本文还有配套的精品资源，点击获取
