企业官网建设流程全解析

我做了一个nginx集群聊天室的项目，前面几篇都在折腾nginx反向代理、负载均衡策略和WebSocket会话保持，流量分发到几个Tomcat节点之后，功能层面的问题就全压到了数据层。聊天室要真正能跑起来，用户要注册登录、好友要有增删关系、群聊要有成员关系、消息要落地，这些功能背后全是一张张MySQL表。如果不提前把表结构设计清楚，后面开发时就会陷入“改一张表要连带改五张表”的泥潭。这篇就是整个系列的第四篇，专门记录这套聊天室的MySQL数据库表设置和配套代码，从建表SQL、MyBatis调用到集群环境下的连接池配置都会提到。如果你正在做类似的聊天室项目，或者被社交关系表和逻辑删除反复折磨，这篇里应该能找到想要的答案。

1. 数据库表整体设计思路

1.1 聊天室项目到底需要哪些表

我在设计之前先把业务实体捋了一遍。聊天室的核心场景无非是：用户注册登录、添加好友、创建群聊、群成员管理、单聊消息、群聊消息。这六个场景指向的实体都能收敛到几张基础表上：用户表user要承担认证和用户画像；好友关系表user_friend用来存双向好友关系；群组表chat_group存群的基本信息；群成员表group_member解决一个人加入多个群、一个群有多个人的多对多关系；聊天消息表chat_message存所有消息内容。如果还要做会话列表、已读未读、未读消息数这些功能，就得再加入会话表和会话成员表。我这一版把会话也单独拆出来了，因为后面做消息列表、已读回执会轻松很多。

这组表的关系很明确，user_id是贯穿所有表的线索，好友表里两个user_id对映一段关系，群组表和群成员表通过group_id关联，消息表通过session_id归属到某个会话。表与表之间我刻意没有加任何物理外键，原因后面会详细说。从实际经验看，这个表结构已经能覆盖一个中小型聊天室的所有功能，而且比较容易扩展。

1.2 字段设计、索引取舍和“为什么不用外键”

表结构设计的时候我给自己定了几条铁律。

第一，主键统一用BIGINT AUTO_INCREMENT。聊天室不是高并发金融系统，用自增主键不会遇到什么瓶颈，而且InnoDB聚簇索引对自增主键非常友好，插入顺序和物理存储顺序一致，可以减少页分裂。如果以后要迁移到分布式ID方案，BIGINT也留足了空间。

第二，每张表都保留create_time、update_time两个时间字段，用DATETIME类型，默认值设为CURRENT_TIMESTAMP，更新时自动刷新。这样做的好处是后端代码里完全不用手动维护时间，排查线上数据问题时也能一眼看出记录是何时写入的。

第三，每张表都加一个is_deleted逻辑删除标记。聊天室这类C端产品，用户可能注销、退群、删好友，但业务上往往想保留历史关联数据用于审计或者悔撤销恢复。直接用DELETE物理删数据太不优雅，我统一用TINYINT的删除标记，查询时强制带is_deleted = 0条件。

第四，索引设计一定要围绕“怎么查”来设计。比如好友表要按“我的好友列表”查，就要在user_id上建索引；消息表要按会话查最近消息，就建(session_id, send_time)复合索引；群成员表要按群查成员，就在group_id上建索引。不要听网上的人说“索引越多越好”，聊天室每个写操作都涉及多条表，索引过多会让插入性能明显下降，我最终的策略是在每个表只建少数几个高频查询的索引。

第五，坚决不用物理外键。很多教程让建表时用FOREIGN KEY约束，我在真实项目里吃过亏：物理外键会让每次insert/update都去检查关联表，集群环境下MySQL压力本来就大，这种额外的约束检查会放大延迟；而且一旦要分库分表，物理外键会成为最大的迁移障碍。我的做法是只保留逻辑外键，也就是通过SQL的JOIN或者应用层代码去维护关系，MySQL只管存数据，不要干审查关系的活。

还有一个很多人容易忽略的点：字符集必须用utf8mb4。做聊天室消息里难免有emoji，老版本的utf8只能存三个字节，表情一发就报错乱码。排序规则我用utf8mb4_unicode_ci，虽然比general_ci略慢一点点，但对中文和特殊符号的排序更准确，聊天室里这个损耗可以忽略。

2. 建表SQL与表结构详解

2.1 用户表和好友关系表

用户表是整个系统的基础，我建表SQL是这样写的：

CREATE TABLE `user` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` VARCHAR(50) NOT NULL COMMENT '登录名', `password` VARCHAR(100) NOT NULL COMMENT '登录密码，存BCrypt哈希', `nickname` VARCHAR(50) NOT NULL COMMENT '用户昵称', `avatar` VARCHAR(255) DEFAULT NULL COMMENT '头像URL', `signature` VARCHAR(255) DEFAULT NULL COMMENT '个性签名', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '状态：1在线，2离线，3隐身', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', `is_deleted` TINYINT NOT NULL DEFAULT 0 COMMENT '逻辑删除：0正常，1已删', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='用户表';

用户名做了真正的唯一索引，因为登录名不允许重复，注销用户如果要保留历史数据，我宁愿用改名或换注销方案，也不会牺牲这种强约束。密码字段长度给到100，因为BCrypt每次生成的哈希长度是60个字符左右，历史兼容项目还可能有其他算法，留足余量。头像和签名这类信息都允许为空，减少不必要的存储。

好友关系表我用了两个用户ID表达关系，同时存了备注和分组名称：

CREATE TABLE `user_friend` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `user_id` BIGINT NOT NULL COMMENT '用户ID', `friend_user_id` BIGINT NOT NULL COMMENT '好友用户ID', `remark` VARCHAR(50) DEFAULT NULL COMMENT '好友备注', `group_name` VARCHAR(50) DEFAULT NULL COMMENT '好友分组名称', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `is_deleted` TINYINT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_friend` (`user_id`, `friend_user_id`, `is_deleted`), KEY `idx_friend_user_id` (`friend_user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='好友关系表';

注意这个表的唯一键我最初直接建了(user_id, friend_user_id, is_deleted)。它的想法是：A加B一次，正常记录是user_id=A，friend_user_id=B，is_deleted=0；如果解除好友就把is_deleted置为1，以后再添加B还能有一条is_deleted=0的新记录。实际用下来发现一个大坑：如果用户反复删除再添加，第二次删除后新记录也被置为1，此时会和第一次删除的旧记录在(user_id, friend_user_id, is_deleted)上撞车，直接报唯一键冲突。这个问题的解决办法我留到第4章专门讲，因为踩的人实在太多了。

2.2 群组表和群成员表

群组的建表SQL很直接：

CREATE TABLE `chat_group` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `group_name` VARCHAR(50) NOT NULL COMMENT '群名称', `owner_user_id` BIGINT NOT NULL COMMENT '群主用户ID', `notice` VARCHAR(500) DEFAULT NULL COMMENT '群公告', `max_members` INT NOT NULL DEFAULT 500 COMMENT '最大人数', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `is_deleted` TINYINT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), KEY `idx_owner_user_id` (`owner_user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='群组表';

群主信息我放在chat_group里冗余了一份，但群主同时也是群成员，所以group_member里也要有一条role=1的记录。这样查询群列表或者做权限校验很方便，不需要每次拿owner_user_id再去关联查询群成员表。

群成员表是典型的多对多关系表：

CREATE TABLE `group_member` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `group_id` BIGINT NOT NULL COMMENT '群ID', `user_id` BIGINT NOT NULL COMMENT '用户ID', `role` TINYINT NOT NULL DEFAULT 0 COMMENT '角色：0普通成员，1群主，2管理员', `muted_until` DATETIME DEFAULT NULL COMMENT '禁言截止时间', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `is_deleted` TINYINT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), UNIQUE KEY `uk_group_member` (`group_id`, `user_id`, `is_deleted`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='群成员表';

查询“某人加入了哪些群”就靠group_member表上的idx_user_id索引。查询“群里有哪些成员”就靠uk_group_member的前缀(group_id)索引。这里和好友表一样，(group_id, user_id, is_deleted)的唯一键也会遇到“退群后重复退群”的冲突问题。后面会一起解释。

2.3 会话表、会话成员表和聊天消息表

我把单聊和群聊收敛成了统一会话模型。每个双人聊天会创建一条chat_session记录，然后往chat_session_member里塞两条成员关系；每个群聊在创建群的同时也会生成一条session_type=1的会话记录。消息表里不直接存对方的user_id，而是存session_id，这是为了简化查询逻辑。

CREATE TABLE `chat_session` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `session_type` TINYINT NOT NULL COMMENT '会话类型：0单聊，1群聊', `name` VARCHAR(100) DEFAULT NULL COMMENT '会话名称，群聊时冗余群名', `avatar` VARCHAR(255) DEFAULT NULL COMMENT '会话头像，群聊时冗余群头像', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `is_deleted` TINYINT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), KEY `idx_session_type` (`session_type`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会话表';

CREATE TABLE `chat_session_member` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `session_id` BIGINT NOT NULL COMMENT '会话ID', `user_id` BIGINT NOT NULL COMMENT '用户ID', `last_read_msg_id` BIGINT NOT NULL DEFAULT 0 COMMENT '该用户在此会话中最后已读的消息ID', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `is_deleted` TINYINT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), UNIQUE KEY `uk_session_member` (`session_id`, `user_id`, `is_deleted`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会话成员表';

消息表是聊天室数据量最大的表，我这样建：

CREATE TABLE `chat_message` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `session_id` BIGINT NOT NULL COMMENT '会话ID', `sender_id` BIGINT NOT NULL COMMENT '发送者用户ID', `content` TEXT NOT NULL COMMENT '消息内容', `msg_type` TINYINT NOT NULL DEFAULT 0 COMMENT '消息类型：0文本，1图片，2文件，3语音', `reply_to_msg_id` BIGINT DEFAULT NULL COMMENT '回复的消息ID', `client_msg_id` VARCHAR(64) DEFAULT NULL COMMENT '客户端去重ID', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0未读，1已读，2撤回', `send_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '发送时间', `is_deleted` TINYINT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), KEY `idx_session_send` (`session_id`, `send_time`, `id`), KEY `idx_sender_id` (`sender_id`), UNIQUE KEY `uk_client_msg_id` (`client_msg_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='聊天消息表';

这里有几个细节要解释。idx_session_send是核心索引，查询一个会话的历史消息时，SQL会走WHERE session_id = ? ORDER BY send_time DESC, id DESC，这个复合索引让MySQL只需要查找该session的索引段，然后按顺序回表拿数据。client_msg_id是客户端生成的一个UUID，用来做消息幂等，防止客户端网络重试导致一条消息被插入两次；MySQL唯一索引天然保证client_msg_id不能重复，而且多个NULL值在MySQL的UNIQUE索引中是允许的，所以客户端没传时留NULL不会有冲突。send_time在查询时会参与排序，所以必须跟session_id建联合索引，如果只建session_id索引，排序就要走内存filesort，数据量大时非常慢。

会话成员表里的last_read_msg_id是已读列表方案的一个关键字段。用户打开某个会话时，把他在这个会话里的last_read_msg_id更新到当前最大的消息ID，计算未读数就是COUNT(*) WHERE session_id=? AND id>last_read_msg_id。这个方案比在消息表里逐条维护已读状态要省很多空间。

3. 数据库连接与访问代码实现

3.1 nginx集群下的数据库连接池配置

表建好了，代码要能连上库。这个项目用Spring Boot，数据库连接池用的是HikariCP。在nginx集群场景下，每个Web节点都是独立进程，每个进程都有自己的连接池。我一开始没仔细算，直接把每个节点连接池最大值设成了50，四个节点就是200个连接，结果MySQL默认的max_connections只有151，应用启动后还没跑业务数据库就报警告了。

配置如下，这是按每个节点20个最大连接来的：

spring.datasource.url=jdbc:mysql://192.168.10.20:3306/chatroom?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&rewriteBatchedStatements=true spring.datasource.username=chatroom spring.datasource.password=你的密码 spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.hikari.minimum-idle=5 spring.datasource.hikari.maximum-pool-size=20 spring.datasource.hikari.connection-timeout=30000 spring.datasource.hikari.idle-timeout=600000 spring.datasource.hikari.max-lifetime=1800000

rewriteBatchedStatements=true特别重要，MySQL驱动在批量插入时会自己把多条insert重写为一条多值insert，性能提升非常明显，做群发消息或者初始化群成员时能快一个数量级。多节点并发时，连接池大小不能拍脑袋。我后来按“单节点并发数/（单查询耗时毫秒/1000）”粗算，简单说就是：一个连接在同一时刻只能服务一个SQL，你希望一个节点同时能处理40个请求，单个请求平均查3次库，每次5毫秒，那连接池20就够。给每个节点设20，4个节点80个连接，MySQL这边还有系统连接和其他开销，余量还算健康。如果节点数量扩展到10个以上，建议要么减小每个节点的pool大小，要么直接升配MySQL并修改max_connections。

另外，nginx集群里的业务都是通过nginx反向代理进来的，数据库连接池的异常处理必须考虑“节点重启”。我在实际部署时发现，某台节点被杀掉重启后，老连接还在MySQL端没有释放，新节点又建新连接，很容易把连接数顶满。所以Hikari的max-lifetime我刻意设成30分钟，比MySQL的wait_timeout默认8小时短很多，让连接池主动老化旧连接，避免用到一个被服务端掐断的“僵尸连接”。

3.2 基于MyBatis的Mapper代码示例

项目用的是MyBatis。用户注册和登录是最基础的两个接口。用户注册的Mapper接口写法如下：

@Mapper public interface UserMapper { int insertUser(User user); User selectByUsername(String username); }

对应的XML：

<insert id="insertUser" useGeneratedKeys="true" keyProperty="id"> INSERT INTO `user` (username, password, nickname, avatar, signature, status) VALUES (#{username}, #{password}, #{nickname}, #{avatar}, #{signature}, #{status}) </insert> <select id="selectByUsername" resultType="User"> SELECT id, username, nickname, avatar, signature, status FROM `user` WHERE username = #{username} AND is_deleted = 0 </select>

登录密码别用明文存，建议用BCrypt加密，BCryptPasswordEncoder可以直接塞进Spring容器里。查询时把password排除掉，避免密码哈希传到前端。逻辑删除条件一定要写在XML里，而且不要用SELECT *，只select自己需要的列，既省带宽也方便后续维护字段。

好友添加涉及关系写入，我直接在Service层加事务：

@Transactional(rollbackFor = Exception.class) public void addFriend(long userId, long friendUserId) { UserFriend relation = new UserFriend(); relation.setUserId(userId); relation.setFriendUserId(friendUserId); friendMapper.insert(relation); UserFriend reverseRelation = new UserFriend(); reverseRelation.setUserId(friendUserId); reverseRelation.setFriendUserId(userId); friendMapper.insert(reverseRelation); }

这个事务很必要，A添加B成功但B添加A失败，会出现单向好友的脏数据，聊天室的好友列表就乱了。事务保证两条记录同时成功或同时失败。

创建群组也同理：插入群表、插入群主作为成员的记录、插入会话表和会话成员记录，这四步必须在同一个事务里执行。

3.3 消息发送与历史消息查询的实现细节

发送消息的Mapper插入写法我用自增主键，需要把插入后的消息ID返回：

<insert id="insertMessage" useGeneratedKeys="true" keyProperty="id"> INSERT INTO chat_message (session_id, sender_id, content, msg_type, reply_to_msg_id, client_msg_id, status) VALUES (#{sessionId}, #{senderId}, #{content}, #{msgType}, #{replyToMsgId}, #{clientMsgId}, 0) </insert>

这里有一个实际项目里很关键的幂等处理：客户端发送消息时会先本地生成一个client_msg_id，如果客户端因为网络超时重发了同一个请求，后端通过唯一索引uk_client_msg_id捕获到冲突，直接忽略重复插入。代码里要处理这个异常，不能让它直接抛给用户。我一般用try-catch捕获DuplicateKeyException，然后查询出原消息返回给客户端，而不是报错。

拉取历史消息用游标分页，避免深分页那种OFFSET越来越慢的问题：

SELECT id, session_id, sender_id, content, msg_type, send_time FROM chat_message WHERE session_id = #{sessionId} AND id > #{lastMsgId} AND is_deleted = 0 ORDER BY id ASC LIMIT 100

这种方式是增量拉取，配合idx_session_send索引，即使消息表有几百万行，也只扫描该session对应的那一段索引，查询毫秒级返回。如果直接用LIMIT 100000, 100这种深分页，MySQL要扫10万行后再丢前99900行，性能很灾难。

4. 常见问题与排查技巧实录

4.1 软删除和唯一键冲突，为什么软删除之后无法新建了

这个坑我前面反复提到。很多人在唯一键里直接拼上is_deleted字段，比如：

UNIQUE KEY `uk_user_friend` (`user_id`, `friend_user_id`, `is_deleted`)

假设A添加了B，然后解除好友。第一次解除时把这条记录is_deleted置为1。之后A又想加B，插入新记录(user_id=A, friend_user_id=B, is_deleted=0)，此时不冲突，因为(…,0)和(…,1)不一样。问题出在第二次解除：A把这条新记录再次置为1，数据库里就有两条(A,B,1)，唯一键直接爆炸。群成员退群再重进再退群是同一个道理。

这个场景我试过几种方案，分享我最终的解法。最推荐的是增加一个delete_token列，唯一键不再用is_deleted，而是用业务唯一字段加上delete_token：

ALTER TABLE `user_friend` ADD COLUMN `delete_token` VARCHAR(36) DEFAULT NULL COMMENT '逻辑删除标记，删除时填入UUID', DROP INDEX `uk_user_friend`, ADD UNIQUE KEY `uk_user_friend_del` (`user_id`, `friend_user_id`, `delete_token`);

未删除的数据delete_token为NULL，MySQL的UNIQUE索引允许多个NULL值存在，所以同一对好友只允许存在一条delete_token为空的数据。删除好友时，把delete_token更新成一个随机UUID，这样多次删除都会生成不同的UUID，永远不会冲突；同时is_deleted字段还能用于查询过滤。这个方案同样用在群成员表、会话成员表上，适用面很广。如果你的业务允许物理删除，也可以干脆不保留历史，直接DELETE掉旧记录，然后重建新记录，但既然用逻辑删除，还是用delete_token最省心。

4.2 nginx集群下连接池、主从延迟和事务的真实问题

多节点部署时数据库一旦扛不住，不会是MySQL自己挂掉，而是连接被占满导致所有接口都变慢。我的排查流程是这样：先看SHOW PROCESSLIST里有没有大量Sleep连接，再看应用的连接池是不是不够用，最后查是不是有慢SQL长时间占用连接。之前我遇到过一条查询消息列表的SQL因为WHERE字段类型不匹配，导致索引失效全表扫描，单条查询跑了3秒，把连接池里的连接全部拖住，其他请求都在排队等连接，整个聊天室看起来就是卡死状态。用EXPLAIN看到type=ALL之后就立刻去改了索引。

主从读写分离在集群聊天室里是必然的，但会引入一个很微妙的延迟问题：用户刚注册完马上跳转登录，如果登录查询走的是从库，而主从同步还没完成，就会报“用户不存在”。我的处理是在读写分离框架里配置“读操作强制走主库”的规则，比如用户完成注册后30秒内的请求走主库，或者对特定Mapper方法标记强制主库。网上有人分享说“写完立即读用缓存”，那也可以，但我更喜欢直接让关键读走主库，逻辑简单，不容易出现缓存不一致。

事务方面也有一个我在集群下踩过的坑：不要在一个事务里做远程调用。比如点了“创建群聊”，你在这个事务里往chat_group插入群，然后又调用文件服务上传群头像并等待返回，这时候事务一直开着，数据库连接被占用，如果文件服务慢，连接池就被拖死。正确做法是先上传文件拿到结果，再开启数据库事务，业务事务越小越好。

4.3 消息表数据量膨胀和索引失效怎么办

聊天室最怕的就是消息表无限膨胀。单表几千万行之后，即使有索引也会因为B+树层级变深和回表代价升高而变慢。我在设计时就想过这个事，常用的处理方案有三种：按月分区、按会话哈希分表、冷热数据归档。

按月分区最简单，适合消息量增长平稳、需要按时间查历史消息的场景。建表可以这样：

ALTER TABLE chat_message PARTITION BY RANGE (TO_DAYS(send_time)) ( PARTITION p202501 VALUES LESS THAN (TO_DAYS('2025-02-01')), PARTITION p202502 VALUES LESS THAN (TO_DAYS('2025-03-01')), PARTITION p202503 VALUES LESS THAN (TO_DAYS('2025-04-01')) );

分区不是让你每个分区都有一张表，它底层还是一张表，但MySQL查询时可以根据send_time条件只扫描匹配分区，历史消息的清理也变成DROP PARTITION，瞬间完成，不会产生大事务。如果消息量大到单实例MySQL已经扛不住，那时候才考虑按session_id哈希分库分表，不过那是另一个大工程了。

索引失效这个问题，我在这个项目中实际遇到过两个经典场景。第一个是对索引字段用函数，比如WHERE DATE_FORMAT(send_time, '%Y-%m-%d') = '2025-01-01'，这样索引直接失效，因为MySQL要每条记录先算函数结果。正确写法是WHERE send_time >= '2025-01-01' AND send_time < '2025-01-02'，利用范围查询才能走索引。第二个是隐式类型转换，比如session_id是BIGINT，但代码里传了一个字符串数字给Mapper，MySQL内部类型转换后可能会让索引失效。我后来把Mapper参数类型钉死，所有ID都用Long，再没犯过这个错。

最后说一个我自己的习惯：这套表上线后，我又花了半小时把所有SELECT语句都检查了一遍，确保没有SELECT *，没有多余的显示事务嵌套，没有在WHERE后面对索引字段做任何运算。聊天室项目功能看着简单，其实数据层最考验细节。如果你现在也正在做类似的聊天室，建议先花半天把表结构和唯一索引想清楚，特别是逻辑删除和唯一键的兼容方案，想清楚再动手写代码，后面能省掉好几个通宵。