簡(jiǎn)介「游泳館管理系統(tǒng)」是一套面向高校計(jì)算機(jī)與數(shù)據(jù)庫(kù)課程設(shè)計(jì)的Java項(xiàng)目源碼適合正在完成課程作業(yè)、練習(xí)企業(yè)級(jí)應(yīng)用開(kāi)發(fā)的學(xué)生參考。系統(tǒng)圍繞會(huì)員信息、在線預(yù)約、泳道與更衣室等場(chǎng)地調(diào)度、收費(fèi)記賬及財(cái)務(wù)報(bào)表展開(kāi)包含會(huì)員等級(jí)、預(yù)約沖突處理、場(chǎng)地狀態(tài)維護(hù)等業(yè)務(wù)點(diǎn)并配有基于ER模型的數(shù)據(jù)庫(kù)設(shè)計(jì)可幫助理解實(shí)體關(guān)系、數(shù)據(jù)一致性與界面實(shí)現(xiàn)思路。壓縮包共1286個(gè)文件、約3.81MB主要由htm頁(yè)面、class字節(jié)碼與java源碼構(gòu)成另含jar、sql及mdf/ldf數(shù)據(jù)庫(kù)文件覆蓋前端頁(yè)面、程序代碼與建庫(kù)腳本。已有1536人學(xué)習(xí)讀者可借助源碼梳理會(huì)員、預(yù)約、場(chǎng)地與收費(fèi)模塊的調(diào)用關(guān)系對(duì)照SQL與MDF/LDF文件理解建庫(kù)過(guò)程并補(bǔ)全需求分析、系統(tǒng)設(shè)計(jì)與測(cè)試文檔積累Java數(shù)據(jù)庫(kù)項(xiàng)目經(jīng)驗(yàn)。1. 一套跑在瀏覽器里的泳池前臺(tái)游泳館管理系統(tǒng)的真實(shí)邊界上個(gè)月有個(gè)做場(chǎng)館運(yùn)營(yíng)的朋友拿著 Excel 來(lái)找我說(shuō)暑假一天賣(mài)三百多張票晚上對(duì)賬對(duì)了兩個(gè)小時(shí)最后還漏了三張次卡沒(méi)扣。這種場(chǎng)景下一個(gè)用 Java 寫(xiě)的游泳館管理系統(tǒng)干的事其實(shí)很樸素把會(huì)員、票卡、場(chǎng)次、泳道、入場(chǎng)核銷(xiāo)和日結(jié)報(bào)表收進(jìn)一個(gè)后臺(tái)前臺(tái)掃碼放行后臺(tái)自動(dòng)記賬中間不靠人手抄。它適合兩類(lèi)人一類(lèi)是做課程設(shè)計(jì)、想找一個(gè)業(yè)務(wù)閉環(huán)完整、表結(jié)構(gòu)不至于太寒酸的 Java 項(xiàng)目另一類(lèi)是小型場(chǎng)館想拿一份能跑起來(lái)的底子改成自己的。邊界也得先說(shuō)清它不做硬件閘機(jī)直連不接真實(shí)支付渠道核銷(xiāo)和記賬是核心報(bào)表是加分項(xiàng)剩下的靠二次開(kāi)發(fā)補(bǔ)。2. 技術(shù)棧與工程骨架Spring Boot 分層怎么落到目錄上2.1 技術(shù)選型這套組合為什么成了默認(rèn)答案這個(gè)項(xiàng)目的技術(shù)組合基本是 Java 生態(tài)里做中小型管理系統(tǒng)的標(biāo)準(zhǔn)配置Spring Boot 做容器和自動(dòng)裝配MyBatis-Plus 做持久層MySQL 8 存業(yè)務(wù)數(shù)據(jù)Redis 可選用來(lái)放登錄 token 和場(chǎng)次余量緩存前端可以是 Vue2 Element UI 的前后端分離也可以是 Thymeleaf 服務(wù)端渲染。選 Spring Boot 的理由很直接一個(gè)main方法就能把 Tomcat、數(shù)據(jù)源、事務(wù)管理器全帶起來(lái)不用再去寫(xiě)一堆 XML。選 MyBatis-Plus 而不是 JPA 的理由更實(shí)際場(chǎng)館類(lèi)系統(tǒng)的報(bào)表 SQL 特別多日結(jié)、月結(jié)、按場(chǎng)次統(tǒng)計(jì)人次這些用 JPA 的 Criteria 寫(xiě)出來(lái)又長(zhǎng)又難調(diào)而 MyBatis-Plus 保留了手寫(xiě) SQL 的自由同時(shí)把單表 CRUD 用BaseMapper省掉了。代碼生成器跑一遍entity、mapper、service、controller 四層骨架就出來(lái)了對(duì)課設(shè)這種時(shí)間緊的場(chǎng)景幾乎是救命稻草。前端走分離還是走模板取決于你要不要給閘機(jī)側(cè)留接口。分離方案里后臺(tái)管理頁(yè)面和前臺(tái)核銷(xiāo)頁(yè)面共用一套axios封裝接口層用 JWT 做無(wú)狀態(tài)鑒權(quán)攔截器里解析 token 塞進(jìn)ThreadLocalService 層隨時(shí)能拿到當(dāng)前操作人。模板方案省一個(gè)工程但核銷(xiāo)頁(yè)要單獨(dú)做移動(dòng)端適配時(shí)會(huì)很難受我一般還是傾向分離。權(quán)限這塊項(xiàng)目里通常是sys_user、sys_role、sys_menu、sys_user_role、sys_role_menu五張表登錄后查出菜單樹(shù)渲染側(cè)邊欄接口層用自定義注解RequirePerm(member:add)配合 AOP 做校驗(yàn)。不要一上來(lái)就上 Spring Security 全套配置量會(huì)吃掉你一半的調(diào)試時(shí)間用一個(gè) HandlerInterceptor 加注解足夠撐住這個(gè)體量。2.2 目錄結(jié)構(gòu)一個(gè)包一層看過(guò)去單模塊工程是這個(gè)項(xiàng)目最常見(jiàn)的形態(tài)分包按職責(zé)切不按業(yè)務(wù)切?？粗鴺闼氐钠饋?lái)找得到地方。swim-center ├── pom.xml ├── sql/ │ ├── schema.sql # 建表語(yǔ)句 │ └── data.sql # 字典、菜單、管理員初始數(shù)據(jù) └── src/main/ ├── resources/ │ ├── application.yml │ ├── application-dev.yml │ └── mapper/ # MyBatis XML復(fù)雜 SQL 放這里 └── java/com/example/swim/ ├── SwimApplication.java ├── common/ # Result、BizException、全局異常處理 ├── config/ # MybatisPlus、Jackson、WebMvc、跨域 ├── controller/ # 只做參數(shù)接收和結(jié)果包裝 ├── service/ │ └── impl/ # 業(yè)務(wù)邏輯和事務(wù)邊界都在這一層 ├── mapper/ # 繼承 BaseMapper 的接口 ├── entity/ # 和表一一對(duì)應(yīng) ├── dto/ # 入?yún)?duì)象帶校驗(yàn)注解 ├── vo/ # 出參對(duì)象拼裝展示字段 ├── task/ # 定時(shí)任務(wù)場(chǎng)次關(guān)閉、卡過(guò)期 └── util/ # 訂單號(hào)、二維碼、導(dǎo)出工具dto和vo分開(kāi)這件事很多課設(shè)項(xiàng)目會(huì)偷懶合并成 entity 直接用結(jié)果是前端一傳參就能改balance字段。分開(kāi)之后MemberCardDTO里根本不出現(xiàn)余額字段越權(quán)修改從入?yún)用婢捅欢伦×?。同樣vo用來(lái)拼memberName、sessionName這類(lèi)跨表展示字段避免在 entity 上掛一堆TableField(exist false)。service/impl是事務(wù)的唯一入口。Controller 不寫(xiě)TransactionalMapper 也不寫(xiě)事務(wù)邊界統(tǒng)一收在 Service 的公開(kāi)方法上異常往上拋全局異常處理器統(tǒng)一轉(zhuǎn)成Result。這套約定聽(tīng)著教條但項(xiàng)目一旦超過(guò)二十個(gè)接口沒(méi)有約定就會(huì)亂成一鍋粥。2.3 把項(xiàng)目跑起來(lái)配置、建庫(kù)、啟動(dòng)四步配置文件里真正需要改的其實(shí)只有三處數(shù)據(jù)源、時(shí)區(qū)、MyBatis 的 mapper 掃描路徑。剩下的照抄即可。server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver # serverTimezone 必須顯式指定否則 MySQL 8 下時(shí)間會(huì)整體偏移 url: jdbc:mysql://127.0.0.1:3306/swim_center?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: 123456 jackson: # 統(tǒng)一出參時(shí)間格式前端不用再自己格式化 date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml configuration: map-underscore-to-camel-case: true # 下劃線轉(zhuǎn)駝峰e(cuò)ntity 不用寫(xiě) TableField log-impl: org.apache.ibatis.logging.stdout.StdOutImpl參數(shù)含義逐個(gè)說(shuō)serverTimezoneAsia/Shanghai解決的是 JDBC 驅(qū)動(dòng)和 MySQL 服務(wù)端時(shí)區(qū)解釋不一致的問(wèn)題不加它LocalDateTime寫(xiě)進(jìn)去再讀出來(lái)可能差 8 小時(shí)allowPublicKeyRetrievaltrue是 MySQL 8 默認(rèn)加密插件在沒(méi)配 SSL 時(shí)的必需項(xiàng)不加會(huì)報(bào)Public Key Retrieval is not allowedmap-underscore-to-camel-case打開(kāi)后create_time自動(dòng)映射到createTime省掉大量TableField注解。啟動(dòng)步驟按順序走# 1. 建庫(kù)字符集必須是 utf8mb4否則會(huì)員昵稱里的表情符號(hào)存不進(jìn)去 mysql -uroot -p -e CREATE DATABASE swim_center DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci; # 2. 導(dǎo)入表結(jié)構(gòu)和初始數(shù)據(jù)順序不能反 mysql -uroot -p swim_center sql/schema.sql mysql -uroot -p swim_center sql/data.sql # 3. 編譯打包課設(shè)階段沒(méi)必要跑測(cè)試拖時(shí)間 mvn clean package -DskipTests # 4. 啟動(dòng)生產(chǎn)環(huán)境把 dev 換成 prod日志級(jí)別和連接池參數(shù)會(huì)跟著切 java -jar target/swim-center-1.0.0.jar --spring.profiles.activedev跑起來(lái)之后先訪問(wèn)登錄接口拿 token再拿 token 去調(diào)會(huì)員列表能返回?cái)?shù)據(jù)就說(shuō)明數(shù)據(jù)源、MyBatis 映射、鑒權(quán)攔截器三關(guān)都通了。這一步別急著看前端頁(yè)面接口通不通是根頁(yè)面白屏十有八九是跨域或者 token 沒(méi)帶。提示data.sql里一般會(huì)預(yù)置一個(gè)管理員賬號(hào)和幾條卡類(lèi)型字典。密碼如果存的是 MD5第一次登錄后記得在后臺(tái)改掉別直接拿去部署。3. 核心業(yè)務(wù)拆解從賣(mài)一張票到放一個(gè)人進(jìn)場(chǎng)3.1 會(huì)員卡與余額扣減先查后改為什么一定會(huì)出事余額扣減是這個(gè)項(xiàng)目里最容易寫(xiě)錯(cuò)的地方。新手版本的寫(xiě)法通常是先select出卡對(duì)象判斷balance amount然后setBalance(balance - amount)再u(mài)pdate。單機(jī)單線程跑起來(lái)毫無(wú)問(wèn)題一開(kāi)并發(fā)就翻車(chē)兩個(gè)請(qǐng)求同時(shí)讀到余額 100各自判斷通過(guò)各自寫(xiě)回 0 和 0實(shí)際扣了兩次但賬上只少了一次。正確的做法是把判斷和更新壓到一條 SQL 里由數(shù)據(jù)庫(kù)保證原子性影響行數(shù)就是唯一判據(jù)。Service RequiredArgsConstructor public class MemberCardService { private final MemberCardMapper cardMapper; private final CardFlowMapper flowMapper; /** * 扣減余額 * param cardId 會(huì)員卡主鍵 * param amount 扣減金額單位分 * param bizNo 業(yè)務(wù)單號(hào)用于流水冪等 */ Transactional(rollbackFor Exception.class) public void deductBalance(Long cardId, Long amount, String bizNo) { // 條件更新余額不足、卡凍結(jié)、卡過(guò)期三種情況都會(huì)讓 rows 為 0 int rows cardMapper.deductBalance(cardId, amount); if (rows 0) { throw new BizException(卡余額不足或卡狀態(tài)不可用); } // 流水落庫(kù)biz_no 上建唯一索引重復(fù)提交會(huì)直接拋 DuplicateKeyException CardFlow flow new CardFlow(); flow.setCardId(cardId); flow.setAmount(-amount); flow.setBizNo(bizNo); flow.setCreateTime(LocalDateTime.now()); flowMapper.insert(flow); } }對(duì)應(yīng)的 Mapper SQLupdate iddeductBalance UPDATE member_card SET balance balance - #{amount}, update_time NOW() WHERE id #{cardId} AND status 1 AND (expire_time IS NULL OR expire_time gt; NOW()) AND balance gt; #{amount} /update三個(gè)參數(shù)的作用分別是cardId定位到具體一行InnoDB 會(huì)在這行上加排他鎖amount是扣減額用減法而不是覆蓋賦值天然避免丟失更新bizNo不進(jìn)這條 SQL但它是流水表的唯一鍵同一個(gè)業(yè)務(wù)單號(hào)重復(fù)調(diào)用第二次會(huì)直接拋唯一鍵沖突相當(dāng)于給接口加了一層冪等。為什么不用select ... for update不是不能用而是它把鎖的持有時(shí)間拉長(zhǎng)了中間還要走一遍 Java 判斷代碼路徑變長(zhǎng)就多一個(gè)出錯(cuò)點(diǎn)。條件更新一條語(yǔ)句解決鎖的范圍和時(shí)長(zhǎng)都是最小的。金額單位統(tǒng)一用「分」存bigint這一點(diǎn)后面還會(huì)提到它是對(duì)賬能不能對(duì)上的分水嶺。3.2 場(chǎng)次容量一條帶 where 的 update 擋住超賣(mài)游泳館和普通票務(wù)不一樣它有時(shí)段概念。上午場(chǎng)限 200 人賣(mài)滿就不能再賣(mài)否則池子里站不下。這個(gè)「賣(mài)滿」的控制本質(zhì)和秒殺扣庫(kù)存是同一類(lèi)問(wèn)題。表里給swim_session放兩個(gè)字段capacity可售人次sold已售人次。下單時(shí)不是先查sold capacity再更新而是直接帶著條件去更新。Transactional(rollbackFor Exception.class) public Long buyTicket(Long sessionId, Long memberId, Long ticketTypeId) { // 第一步占坑。只有 sold capacity 時(shí)才會(huì) 1返回 0 說(shuō)明已滿 int rows sessionMapper.tryOccupy(sessionId); if (rows 0) { throw new BizException(該場(chǎng)次已滿請(qǐng)選擇其他場(chǎng)次); } // 第二步落訂單。訂單插入失敗會(huì)觸發(fā)整個(gè)事務(wù)回滾把剛占的坑位吐回去 TicketOrder order new TicketOrder(); order.setOrderNo(OrderNoUtil.next()); order.setMemberId(memberId); order.setSessionId(sessionId); order.setTicketTypeId(ticketTypeId); order.setStatus(1); // 1 待入場(chǎng) order.setCreateTime(LocalDateTime.now()); orderMapper.insert(order); return order.getId(); }update idtryOccupy UPDATE swim_session SET sold sold 1 WHERE id #{sessionId} AND status 1 AND sold lt; capacity /update這段的關(guān)鍵在于「相對(duì)更新」而不是「絕對(duì)值更新」。sold sold 1是在數(shù)據(jù)庫(kù)當(dāng)前值基礎(chǔ)上加多個(gè)事務(wù)并發(fā)進(jìn)來(lái)InnoDB 的行鎖會(huì)把它們排成隊(duì)每個(gè)事務(wù)看到的都是上一個(gè)事務(wù)提交后的值sold capacity這個(gè)條件在排隊(duì)過(guò)程中逐個(gè)判定第 201 個(gè)人拿到的rows必然是 0。status 1這個(gè)條件也別省。場(chǎng)次被后臺(tái)手動(dòng)關(guān)閉之后即使沒(méi)賣(mài)滿也不該繼續(xù)放票把它寫(xiě)進(jìn) where 里關(guān)閉動(dòng)作和售賣(mài)動(dòng)作天然互斥。注意這里整段必須在同一個(gè)事務(wù)里。如果占坑和落訂單分別提交訂單插入失敗時(shí)坑位不會(huì)回滾sold就會(huì)越漲越高最后場(chǎng)次明明沒(méi)人卻顯示已滿這種臟數(shù)據(jù)排查起來(lái)極其費(fèi)勁。3.3 入場(chǎng)核銷(xiāo)掃碼掃兩次賬不能記兩條前臺(tái)核銷(xiāo)是這個(gè)系統(tǒng)里調(diào)用頻率最高、也最容易出并發(fā)的接口?？腿四弥S碼在閘機(jī)前晃網(wǎng)絡(luò)抖一下前端重試一次或者工作人員手快點(diǎn)兩下就會(huì)出現(xiàn)同一個(gè)訂單進(jìn)兩次的情況。核銷(xiāo)接口必須做到冪等。設(shè)計(jì)上走狀態(tài)機(jī)訂單狀態(tài) 1 是待入場(chǎng)2 是已入場(chǎng)3 是已退票。核銷(xiāo)就是把 1 推到 2推不動(dòng)就說(shuō)明已經(jīng)處理過(guò)了。Transactional(rollbackFor Exception.class) public void checkIn(String orderNo, String gateNo) { TicketOrder order orderMapper.selectByOrderNo(orderNo); if (order null) { throw new BizException(訂單不存在); } // 帶原狀態(tài)的條件更新只有當(dāng)前還是 1 才能推到 2 int rows orderMapper.updateStatus(order.getId(), 1, 2); if (rows 0) { // 推不動(dòng)有兩種可能已核銷(xiāo)狀態(tài) 2或已退票狀態(tài) 3 // 已核銷(xiāo)直接靜默返回重復(fù)掃碼不彈紅已退票才需要報(bào)錯(cuò) TicketOrder latest orderMapper.selectById(order.getId()); if (latest.getStatus() 2) { return; } throw new BizException(該訂單狀態(tài)不可入場(chǎng)); } EntryRecord record new EntryRecord(); record.setOrderId(order.getId()); record.setMemberId(order.getMemberId()); record.setSessionId(order.getSessionId()); record.setGateNo(gateNo); record.setEntryTime(LocalDateTime.now()); entryRecordMapper.insert(record); }update idupdateStatus UPDATE ticket_order SET status #{toStatus}, update_time NOW() WHERE id #{id} AND status #{fromStatus} /updateupdateStatus的三個(gè)參數(shù)是訂單主鍵、期望的原狀態(tài)、目標(biāo)狀態(tài)本質(zhì)是一個(gè) CAS 操作。并發(fā)兩次請(qǐng)求只有一個(gè)能把status 1改成 2另一個(gè)影響行數(shù)為 0走靜默返回分支。數(shù)據(jù)庫(kù)層面再加一道保險(xiǎn)entry_record表上給order_id建唯一索引。就算哪天有人繞過(guò) Service 直接寫(xiě) Mapper或者事務(wù)傳播行為配錯(cuò)導(dǎo)致?tīng)顟B(tài)更新和記錄插入不在一個(gè)事務(wù)里唯一索引也會(huì)在第二次插入時(shí)拋異常把臟數(shù)據(jù)擋在門(mén)外。這種「代碼邏輯 數(shù)據(jù)庫(kù)約束」雙保險(xiǎn)的寫(xiě)法在涉及錢(qián)和進(jìn)出的業(yè)務(wù)里我基本都會(huì)加上。3.4 日結(jié)報(bào)表一條聚合 SQL 加一層 VO場(chǎng)館老板每天最關(guān)心的就三件事今天賣(mài)了多少?gòu)垺⑹樟硕嗌馘X(qián)、會(huì)員占多少。這個(gè)需求用一條 SQL 就夠了不需要在 Java 里循環(huán)累加。SELECT DATE(o.create_time) AS bizDate, COUNT(*) AS orderCnt, SUM(o.amount) AS totalAmount, SUM(CASE WHEN o.member_id IS NOT NULL THEN 1 ELSE 0 END) AS memberCnt, SUM(CASE WHEN o.source 2 THEN 1 ELSE 0 END) AS offlineCnt FROM ticket_order o WHERE o.status IN (1, 2) -- 排除已退票 AND o.create_time gt; #{startTime} AND o.create_time lt; #{endTime} -- 用小于而不是小于等于避開(kāi)邊界重復(fù) GROUP BY DATE(o.create_time) ORDER BY bizDate DESC幾個(gè)細(xì)節(jié)值得說(shuō)。SUM(o.amount)依賴amount是整數(shù)分如果是decimal或者double累加幾十萬(wàn)條之后尾差會(huì)顯現(xiàn)出來(lái)對(duì)賬時(shí)差一分錢(qián)能讓人查一下午。create_time start AND create_time end這種左閉右開(kāi)的寫(xiě)法是為了避免BETWEEN在跨天統(tǒng)計(jì)時(shí)把 23:59:59 之后的數(shù)據(jù)漏掉或者重復(fù)算。返回的 VO 里totalAmount在序列化前除以 100 轉(zhuǎn)成元用BigDecimal做除法并指定保留兩位別直接用double除浮點(diǎn)誤差在小數(shù)位上會(huì)現(xiàn)形。public class DailyReportVO { private String bizDate; private Integer orderCnt; private BigDecimal totalAmount; // 出參已轉(zhuǎn)成元保留兩位 private Integer memberCnt; private Integer offlineCnt; }報(bào)表接口一般還要支持按場(chǎng)次維度再切一刀那就把GROUP BY DATE(o.create_time)換成GROUP BY o.session_id其余聚合邏輯不變。同一個(gè) Mapper 里放兩個(gè)selectService 層根據(jù)前端傳的dimension參數(shù)分發(fā)比寫(xiě)兩套 Controller 干凈。4. 數(shù)據(jù)表與 SQL十幾張表?yè)纹鹨粋€(gè)場(chǎng)館4.1 核心表清單與字段取舍整個(gè)系統(tǒng)的表不算多十四五張能覆蓋主要業(yè)務(wù)。按模塊歸一下表名作用關(guān)鍵字段備注member會(huì)員檔案name、phone、status手機(jī)號(hào)建唯一索引card_type卡類(lèi)型字典type、price、times、valid_daystype1 儲(chǔ)值 2 次卡 3 期限卡member_card會(huì)員持卡card_no、balance、remain_times、expire_time金額單位分swim_session場(chǎng)次start_time、capacity、sold、status售賣(mài)核心表ticket_order票訂單order_no、session_id、amount、status狀態(tài)機(jī) 1/2/3entry_record入場(chǎng)記錄order_id、gate_no、entry_timeorder_id唯一card_flow卡流水card_id、amount、biz_nobiz_no唯一冪等用coach教練name、level、phone排課關(guān)聯(lián)course_schedule課程排期coach_id、start_time、capacity二次開(kāi)發(fā)高頻改動(dòng)點(diǎn)locker儲(chǔ)物柜no、status、member_id可選模塊water_quality水質(zhì)記錄ph、chlorine、check_time應(yīng)付檢查用sys_user/sys_role/sys_menu權(quán)限三件套—配關(guān)聯(lián)表字段取舍上有個(gè)原則凡是涉及錢(qián)和次數(shù)的一律用整數(shù)存最小單位。balance存分、remain_times存整數(shù)次數(shù)不用decimal也不用double?？粗粌?yōu)雅但省掉了所有浮點(diǎn)比較的麻煩balance amount直接比大小不用考慮0.1 0.2 ! 0.3這種玄學(xué)問(wèn)題。時(shí)間字段統(tǒng)一用datetime而不是timestamp。timestamp有 2038 年上限而且會(huì)隨時(shí)區(qū)轉(zhuǎn)換導(dǎo)出報(bào)表給別人時(shí)容易對(duì)不上。datetime存的是字面值存什么讀什么配合LocalDateTime用起來(lái)最省心。4.2 三張關(guān)鍵表的建表腳本swim_session是全場(chǎng)最熱的一張表讀寫(xiě)都集中在這。索引除了主鍵只留一個(gè)時(shí)間范圍查詢用的聯(lián)合索引。CREATE TABLE swim_session ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主鍵, name varchar(64) NOT NULL COMMENT 場(chǎng)次名如上午場(chǎng), start_time datetime NOT NULL COMMENT 開(kāi)場(chǎng)時(shí)間, end_time datetime NOT NULL COMMENT 散場(chǎng)時(shí)間, capacity int NOT NULL DEFAULT 0 COMMENT 可售人次, sold int NOT NULL DEFAULT 0 COMMENT 已售人次, status tinyint NOT NULL DEFAULT 1 COMMENT 1開(kāi)放 0關(guān)閉, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_time (start_time, end_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT場(chǎng)次表;entry_record的重點(diǎn)在唯一索引它是核銷(xiāo)冪等的最后一道防線。CREATE TABLE entry_record ( id bigint NOT NULL AUTO_INCREMENT, order_id bigint NOT NULL COMMENT 票訂單主鍵, member_id bigint DEFAULT NULL, session_id bigint NOT NULL, gate_no varchar(32) DEFAULT NULL COMMENT 閘機(jī)編號(hào), entry_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_order (order_id), -- 一個(gè)訂單只能進(jìn)一次 KEY idx_session_time (session_id, entry_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT入場(chǎng)記錄;member_card的card_no唯一索引用來(lái)防止重復(fù)發(fā)卡member_id上的普通索引用來(lái)做「查這個(gè)人的所有卡」這個(gè)高頻查詢。CREATE TABLE member_card ( id bigint NOT NULL AUTO_INCREMENT, member_id bigint NOT NULL, card_no varchar(32) NOT NULL COMMENT 卡號(hào)可掃碼, card_type_id bigint NOT NULL, balance bigint NOT NULL DEFAULT 0 COMMENT 余額單位分, remain_times int NOT NULL DEFAULT 0 COMMENT 次卡剩余次數(shù), expire_time datetime DEFAULT NULL, status tinyint NOT NULL DEFAULT 1 COMMENT 1正常 0凍結(jié) 2作廢, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_card_no (card_no), KEY idx_member (member_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT會(huì)員卡;ON UPDATE CURRENT_TIMESTAMP這個(gè)細(xì)節(jié)省事任何一次 update 都自動(dòng)刷新update_time不用在每條 SQL 里手寫(xiě)。但要注意如果哪天做數(shù)據(jù)同步需要保留原始時(shí)間得顯式在 update 語(yǔ)句里給update_time賦值否則會(huì)被自動(dòng)覆蓋。4.3 慢查詢一般出在哪這個(gè)體量的系統(tǒng)數(shù)據(jù)量不上百萬(wàn)基本不會(huì)慢。真正出問(wèn)題的地方集中在兩類(lèi)查詢上。第一類(lèi)是報(bào)表的日期范圍掃描。ticket_order表只建了主鍵索引WHERE create_time BETWEEN ...會(huì)走全表掃。解決辦法是給create_time單獨(dú)建索引或者建(status, create_time)的聯(lián)合索引把狀態(tài)過(guò)濾也帶上。聯(lián)合索引的字段順序按「等值在前、范圍在后」排status IN (1,2)是等值create_time是范圍順序不能反。第二類(lèi)是后臺(tái)列表的模糊搜索。會(huì)員列表按姓名或手機(jī)號(hào)搜LIKE %張%前置通配符會(huì)讓索引失效。這個(gè)場(chǎng)景數(shù)據(jù)量一般不大實(shí)在要優(yōu)化就上全文索引或者把手機(jī)號(hào)改成前綴匹配LIKE 138%。別為了這個(gè)去引 ES運(yùn)維成本遠(yuǎn)超收益。還有一種隱蔽的慢來(lái)自 N1 查詢。訂單列表里每條記錄都要顯示會(huì)員姓名和場(chǎng)次名稱如果循環(huán)里逐條查一頁(yè) 20 條就是 40 次查詢。改成 MyBatis 的collection嵌套查詢或者直接在 SQL 里L(fēng)EFT JOIN一次搞定。XML 里寫(xiě) join 比在 Java 里拼裝可讀性高得多。4.4 初始化數(shù)據(jù)與字典data.sql里必須預(yù)置的東西有四類(lèi)管理員賬號(hào)、卡類(lèi)型字典、場(chǎng)次模板、菜單權(quán)限。-- 管理員密碼是 BCrypt 加密后的 123456首次登錄必須改 INSERT INTO sys_user (id, username, password, real_name, status) VALUES (1, admin, $2a$10$N.zmdr9k7uOCQb376NoUnuTJ8iAt6Z5EHsM8lE9lBOsl7iKTVKIUi, 管理員, 1); -- 卡類(lèi)型儲(chǔ)值卡、次卡、月卡 INSERT INTO card_type (id, name, type, price, times, valid_days) VALUES (1, 儲(chǔ)值卡, 1, 0, 0, NULL), (2, 十次卡, 2, 300, 10, 180), (3, 月卡, 3, 500, 0, 30); -- 場(chǎng)次模板日期部分按實(shí)際排期改 INSERT INTO swim_session (name, start_time, end_time, capacity, sold, status) VALUES (上午場(chǎng), 2024-07-01 08:00:00, 2024-07-01 12:00:00, 200, 0, 1), (下午場(chǎng), 2024-07-01 13:00:00, 2024-07-01 17:00:00, 200, 0, 1), (夜場(chǎng), 2024-07-01 18:00:00, 2024-07-01 22:00:00, 150, 0, 1);密碼用 BCrypt 而不是 MD5是因?yàn)?MD5 撞庫(kù)太容易而且同一個(gè)密碼每次加密結(jié)果一樣拖庫(kù)之后一眼就能看出哪些用戶密碼相同。BCrypt 自帶鹽值每次加密結(jié)果不同校驗(yàn)時(shí)用matches比對(duì)。菜單數(shù)據(jù)插入后登錄接口返回的菜單樹(shù)才有內(nèi)容前端側(cè)邊欄不會(huì)空著。這塊數(shù)據(jù)建議直接從 SQL 腳本導(dǎo)入別在代碼里硬編碼改權(quán)限的時(shí)候只改數(shù)據(jù)不改代碼。5. 避坑與排查五個(gè)坑每一個(gè)都能卡住半天5.1 環(huán)境和啟動(dòng)階段的三個(gè)坑現(xiàn)象啟動(dòng)報(bào)Communications link failure日志里連不上數(shù)據(jù)庫(kù)。原因通常是三種MySQL 服務(wù)沒(méi)起、端口不是 3306、或者 8.0 版本必須帶allowPublicKeyRetrievaltrue而配置里漏了。 解決順序是先telnet 127.0.0.1 3306確認(rèn)端口通再檢查 URL 參數(shù)。如果是 Docker 起的 MySQL注意容器內(nèi)外的端口映射本地連127.0.0.1沒(méi)問(wèn)題但配置里寫(xiě)成容器名就需要在同一網(wǎng)絡(luò)里。現(xiàn)象頁(yè)面上的時(shí)間和數(shù)據(jù)庫(kù)里存的差 8 小時(shí)。原因是時(shí)區(qū)在三處各管一段JDBC 連接的serverTimezone、Jackson 序列化的time-zone、MySQL 服務(wù)端的time_zone。哪一處沒(méi)對(duì)齊都會(huì)偏。 解決是把三處統(tǒng)一成Asia/Shanghai并且在實(shí)體類(lèi)上不要再用java.util.Date統(tǒng)一換成LocalDateTime。Date會(huì)受 JVM 默認(rèn)時(shí)區(qū)影響LocalDateTime是明確的本地時(shí)間語(yǔ)義少一層解釋就少一個(gè)坑?，F(xiàn)象前端拿到的id末尾幾位變成 0或者詳情頁(yè)查不到數(shù)據(jù)。原因是雪花算法生成的長(zhǎng)整型超過(guò)了 JavaScript 的Number.MAX_SAFE_INTEGERJSON 反序列化時(shí)精度丟失。 解決有兩種后端全局配置 Jackson 把Long序列化成字符串或者給主鍵字段加JsonSerialize(using ToStringSerializer.class)。我一般選全局配置一次性解決所有實(shí)體省得漏加。Configuration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer longToString() { return builder - builder .serializerByType(Long.class, ToStringSerializer.instance) .serializerByType(Long.TYPE, ToStringSerializer.instance); } }這個(gè)配置加上之后前端所有id都是字符串路由傳參和比較時(shí)要注意別用直接比數(shù)字血淚經(jīng)驗(yàn)。5.2 業(yè)務(wù)和數(shù)據(jù)層面的兩個(gè)坑現(xiàn)象對(duì)賬時(shí)總額差幾分錢(qián)逐條核對(duì)又看不出問(wèn)題。原因八成是金額字段用了double或者float累加過(guò)程中產(chǎn)生了浮點(diǎn)誤差。0.1 0.2 0.30000000000000004這種事在單條記錄上看不出來(lái)聚合之后就顯形了。 解決是把金額全部改成bigint存分Java 側(cè)用Long只在展示層除以 100 轉(zhuǎn)BigDecimal。改的時(shí)候要全表掃一遍凡是decimal(10,2)的金額字段都換成bigintSQL 里的SUM結(jié)果再除。這個(gè)改造越早做越省事等數(shù)據(jù)攢了幾十萬(wàn)條再改遷移腳本能寫(xiě)到你懷疑人生?，F(xiàn)象Service 方法上明明加了Transactional拋異常后數(shù)據(jù)還是寫(xiě)進(jìn)去了。原因有四種常見(jiàn)情況同類(lèi)內(nèi)部方法自調(diào)用代理不生效異常被try-catch吞掉沒(méi)有重新拋出方法不是public異常類(lèi)型是受檢異常而注解沒(méi)配rollbackFor。 排查方法是先看調(diào)用是不是從外部進(jìn)來(lái)的再看 catch 塊里有沒(méi)有throw最后確認(rèn)注解寫(xiě)了rollbackFor Exception.class。Spring 默認(rèn)只對(duì)RuntimeException回滾業(yè)務(wù)里拋的自定義異常如果繼承的是Exception不加這個(gè)參數(shù)就不會(huì)回滾這個(gè)坑我見(jiàn)過(guò)不止一次。// 錯(cuò)誤示范內(nèi)部自調(diào)用事務(wù)注解形同虛設(shè) public void outer() { this.inner(); // 走的是 this不是代理對(duì)象 } Transactional(rollbackFor Exception.class) public void inner() { /* ... */ }正確做法是把inner挪到另一個(gè) Bean 里或者注入自身代理Lazy MemberCardService self再調(diào)self.inner()。后者寫(xiě)法簡(jiǎn)單但有點(diǎn)繞前者結(jié)構(gòu)更清晰我一般選前者?，F(xiàn)象核銷(xiāo)接口偶發(fā)Duplicate entry異常日志里一片紅。原因不是 bug恰恰是唯一索引在起作用——同一個(gè)訂單被并發(fā)核銷(xiāo)了兩次第二次插入被擋下來(lái)了。但這個(gè)異常如果直接拋到前端工作人員會(huì)以為系統(tǒng)壞了。 解決是在 Service 層捕獲DuplicateKeyException當(dāng)成「已核銷(xiāo)」處理返回成功即可。同時(shí)把狀態(tài)更新的 CAS 邏輯補(bǔ)上讓絕大多數(shù)重復(fù)請(qǐng)求在第一步就被攔住唯一索引只做兜底。6. 二次開(kāi)發(fā)加一個(gè)培訓(xùn)課程報(bào)名模塊要?jiǎng)幽膸讓訄?chǎng)館跑順之后老板十有八九會(huì)提一句「順便把游泳培訓(xùn)班的報(bào)名也管起來(lái)」。這個(gè)需求看著是新增實(shí)際是復(fù)用改動(dòng)清單可以列得很清楚。層次改動(dòng)內(nèi)容復(fù)用點(diǎn)表新增course、course_schedule、course_booking容量字段和swim_session同構(gòu)實(shí)體/Mapper三張表各生成一套MyBatis-Plus 代碼生成器直接跑ServiceCourseBookingService.book()直接套 3.2 的tryOccupy模式Controller報(bào)名、取消、我的課程三個(gè)接口鑒權(quán)和統(tǒng)一返回體沿用菜單sys_menu插三條記錄綁定角色后臺(tái)刷新即可見(jiàn)核心的報(bào)名扣名額邏輯和票務(wù)售賣(mài)是同一個(gè)套路把表名換掉就行Transactional(rollbackFor Exception.class) public Long book(Long scheduleId, Long memberId) { // 和場(chǎng)次占坑完全一致的 CAS 寫(xiě)法只是換了張表 int rows scheduleMapper.tryBook(scheduleId); if (rows 0) { throw new BizException(該課程已報(bào)滿); } // 報(bào)名記錄上給 (schedule_id, member_id) 建唯一索引防止同一個(gè)人重復(fù)報(bào) CourseBooking booking new CourseBooking(); booking.setScheduleId(scheduleId); booking.setMemberId(memberId); booking.setStatus(1); bookingMapper.insert(booking); return booking.getId(); }驗(yàn)證的時(shí)候別只點(diǎn)頁(yè)面。用ab或者 JMeter 對(duì)報(bào)名接口打 200 并發(fā)搶 50 個(gè)名額跑完查SELECT COUNT(*) FROM course_booking WHERE schedule_id ?是不是正好 50再看sold字段和實(shí)際記錄數(shù)對(duì)不對(duì)得上。這個(gè)驗(yàn)證方法比點(diǎn)一百次頁(yè)面都管用而且能順帶壓出連接池配置的問(wèn)題。還有一個(gè)容易忽略的點(diǎn)新模塊上線前把course_booking的唯一索引和course_schedule的sold capacity條件一起寫(xiě)進(jìn)回歸清單。后來(lái)加功能的人如果只改了 Service 沒(méi)動(dòng) SQL接口層面測(cè)不出問(wèn)題只有并發(fā)場(chǎng)景才會(huì)暴露。從那以后我每次給這類(lèi)系統(tǒng)加新模塊都強(qiáng)制先跑一遍并發(fā)腳本再提測(cè)寧可多花二十分鐘也不想半夜被電話叫起來(lái)查「為什么多賣(mài)了八張票」。希望這些拆解能幫你少走點(diǎn)彎路。本文還有配套的精品資源點(diǎn)擊獲取