YashanDB在社交网络数据中的实战：建模、SQL与调优

做社交业务的数据开发这几年，我最大的感受是：关系数据、用户行为、内容流、话题传播，这些看似不同的场景，底层都是同一批数据在反复横跳。今天想聊的是YashanDB。它不是那种非要你重写全部业务的数据库，而是能直接跟现有社交场景贴合起来的国产数据库——支持Oracle兼容语法，带行列混合存储和HTAP能力，既能扛住用户关系、帖子发布这类高并发事务，又能直接跑画像分析、话题热度这类偏分析型的查询。这篇文章不是产品介绍，是我在实际项目里怎么用它把社交网络数据真正用起来的完整记录，包括表结构怎么设计、索引怎么搭、SQL怎么写才算合理、混合负载下怎么不互相拖累，以及我踩过的一些坑。适合正在做社交类应用、内容社区、或者想从传统数据库迁到YashanDB的同学参考。

1. 社交网络数据与YashanDB的契合点分析

1.1 社交网络数据的典型结构与规模特征

社交网络数据表面看是“用户+内容+关系”三个词，落地到数据库里就很具体了。用户表、关注关系表、帖子表、评论表、点赞表、私信表、标签表，再加上用户行为日志，这几张表撑起了绝大多数社交产品的核心逻辑。

数据结构上有个典型特征：实体简单，关系复杂。用户表本身字段不多，几十个到上百个列而已，但关注关系、互动关系是海量的、多对多的。比如一个千万级DAU的社区，用户可能只有几百万，但关注关系表动辄就是几亿行，动态流表、互动事件表增长更快。这跟传统ERP那种单一表单数据模型完全不同，后者表之间关系固定、查询模式相对稳定，而社交数据的访问模式极度分散——首页Feeds、个人主页、关系链查询、内容检索、热门榜单，每个查询走不同的路径。

规模特征上，社交数据是典型的“写多读多、热点集中、冷热分明”。写路径上，发帖、点赞、关注、评论都是高频小事务，几毫秒内必须完成，数据库首先要扛住大量并发短事务。读路径上，同一个用户反复访问自己的Feeds和热门内容，数据热度高度集中，头部内容贡献了大部分查询量，长尾内容几乎无人问津。这意味着数据库不仅要处理高并发，还要能识别热点数据，用合理的缓存和索引策略去扛住读压力。

存储上还要面对一个现实：社交内容无外乎结构化字段和文本/半结构化字段并存。帖子表除了用户ID、时间、状态这些固定列，往往还有标签数组、扩展属性、甚至正文摘要。直接用纯关系模型做，表会变得又宽又怪；用纯文档模型做，关联查询又很痛苦。YashanDB的多模存储能力在这里就比较合适——关系表负责核心事务，JSON字段承载扩展属性，倒排索引处理内容检索，一套体系内解决，不用像以前那样把数据拆到好几个存储里再自己做同步。

1.2 YashanDB核心能力与社交场景的匹配逻辑

YashanDB能跟社交场景走到一起，不是偶然。它最核心的几个能力，我按实际使用价值排序：

第一，兼容Oracle语法。这一点在社交业务里的价值比想象中大。很多中大型社交产品的核心链路是从Oracle/MySQL迁过来的，几百条历史SQL、存储过程、触发器的移植成本往往比想象中还高。YashanDB兼容Oracle的PL/SQL、常用函数、层次查询等语法，项目组不用为“换数据库”重写所有数据访问层。我们迁过一套老用户体系，最复杂的几个存储过程几乎只是改了包名就跑了。

第二，行列混合存储。社交数据的行式存储适合点查和事务更新，列式存储适合聚合分析。YashanDB一张表里可以同时维护两种存储形态，事务走行存，分析走列存，这个能力对社交场景太关键了。因为社交业务天然就是“既要频繁写，又要频繁统计”——热度榜、用户标签透视、关系链分析、人群分群，全是重SQL聚合，如果只靠行存扛，查询性能会很差；如果完全列式，单条更新又很重。混合存储让我不用费劲去搭一条T+1的离线分析链路，很多统计直接在线跑了。

第三，HTAP能力。社交场景最典型的痛点就是“白天线上高并发，晚上批量跑报表”。传统做法是业务库和分析库分离，中间靠ETL同步，延迟几十分钟到几小时，而且同步链路还得专门运维。YashanDB的HTAP思路是在同一个引擎内同时处理事务和分析负载，事务型查询和分析型查询走同一份数据。并不是说它能完全取代OLAP数仓——复杂到十几张表join、扫几十亿行的重型分析还是建议留给专门的数仓——但日常的运营看板、实时榜单、用户分层计算，直接在当前库上跑就够了，数据准时性也更好。

第四，分布式的弹性。社交业务的特点是爆发式增长和大促脉冲。新功能上线、节日活动、热点事件，往往几天内流量翻几倍。YashanDB支持shared-nothing的分布式部署，数据按分布键分散到多个节点，每个节点只处理自己的那部分数据，横向加机器就能扩展读和写能力。我们把它用在关注关系表和互动流水表上，按用户ID哈希分片，热点用户的读写被分散到多个节点，单点压力明显下降。

还有一个容易被忽略却很重要的点：高可用和容灾能力。社交产品最怕出故障，任何一个核心链路的数据库抖动，直接体现在用户流失上。YashanDB提供多副本同步、自动故障切换等能力，生产上把数据副本分布在不同的物理节点甚至不同机房，遇到单机宕机，切换过程对上层业务几乎无感。这套机制跟我以前用开源数据库自己搭主从、做切换脚本的日子比起来，省心太多了。

2. 核心链路：从建表建模到数据高效接入

2.1 按数据冷热与访问模式设计存储模型

我把社交场景的表按访问模式分为三类，分别用不同的方式去设计。

第一类是核心事务表，典型如用户表、帖子表。这类表的特点是点查和短事务极多：登录要查用户、发帖要插帖子、打开帖子详情要做一次主键查询。设计上必须走行存，主键尽量简洁，索引要精准覆盖高频查询。我一般把用户表设计成紧凑型，字段能用整型绝不用字符串，比如性别、状态、用户类型都用整数编码。帖子表的主键通常是帖子ID，但社交场景里“按作者拉列表”“按时间拉流”才是真实高频查询，所以光有主键不够，还得在作者ID和时间上建组合索引。

第二类是关系与事件流水表，典型如关注表、点赞表、评论表、浏览记录。这类表天生是分布式高并发写入的，单表规模上亿很正常。设计上我会用分布式表，以用户ID作为分布键，让同一个用户的所有关系数据落在同一节点，这样不仅写入分散，查询用户维度数据时也能做到本地计算，避免跨节点广播。

第三类是分析标签类数据，典型如用户标签、内容标签、话题聚合信息。这类数据事务性不强，但经常要按标签做群体统计，比如“找出关注了某话题同时活跃度高的用户”。对这种数据我倾向在建表时设置列存，平时更新少、读取重，列存能把聚合查询的速度提升一个量级。如果一张表既要有事务能力又要有分析能力，就用YashanDB的行列混合存储，行存用于单点更新，列存用于分析，数据保持一致，不需要你维护双份。

设计存储模型时最需要克制的是“不要用一张宽表装所有东西”。我刚带项目时吃过这个亏，把用户基础信息、扩展资料、画像标签全揉进一张表，结果表宽了几十个列，走行存浪费存储，走列存更新又别扭。后来拆成用户基础表和用户标签表，基础表保持轻量，标签表使用KV结构用JSON存储，问题立刻缓解。社交数据的核心就是实体和关系，拆开反而更贴合访问模式。

2.2 批量导入与实时写入的工程配置建议

社交数据接入是两条路径并行：存量数据的批量导入和增量数据的实时接入。我在YashanDB上的实践是分开处理。

存量数据批量导入，最忌讳的是用逐条INSERT。几千万条用户关系数据，如果一条条插，光网络往返就能耗掉几小时。正确的做法是用批量导入工具或INSERT加批量参数。YashanDB的批量提交模式下，可以一条语句携带大量记录，减少事务提交次数和网络开销。实际导入时还有个细节：先建好索引再导数据，还是先导数据再建索引？我的建议是大批量导入前先干掉冗余索引，只留主键，数据导入完成后再统一建索引。因为每插入一行都要同步维护索引，索引越多写入越慢，导完之后再建索引反而总时间更短。

增量实时接入，核心是控制事务粒度。发帖、点赞、关注是高频小事务，每个事务只写几行，这是社交场景的标准姿势。但业务方经常会提出一些“顺手”需求，比如发帖的同时更新作者的发帖数、帖子数缓存，如果把这些写进同一个事务，事务时间变长，锁竞争加剧，并发能力就下来了。我的处理方式是把强一致的核心写操作放进事务，把可延迟的统计更新改成异步或最终一致，比如先写帖子主记录，再异步扣减统计。代价是统计偶尔有滞后，但换来了整个链路的稳定性。

写入时的分布键选择也很关键。社交场景里，关注关系表、互动流水表这类表我按用户ID哈希分布；帖子表我按作者ID哈希分布。这样设计的好处是，应用层查询“用户A关注了谁”“用户A的帖子有哪些”时，数据全在同一个节点内，查询效率和写入吞吐都更好。如果分布键选错，比如帖子表按帖子ID哈希，那么按作者拉列表的操作就要跨节点聚合，性能直线下降。

还有个容易被忽视的问题是连接池参数。YashanDB的并发连接数、每连接的并发请求数、网络超时时间这些参数，直接决定社交场景的极限吞吐。我最开始用默认参数跑压力测试，连接池一打满，事务排队严重，应用层P99延迟飙升。后来把最大连接数调大，并限制单连接的并发请求数，同时设置合理的网络重试机制，让超时请求快速失败而不是无限阻塞，链路就稳多了。压测一定要在真实数据量上做，不然后果就是上线后被真实流量教做人。

3. 高价值SQL玩法：跑通典型社交数据场景

3.1 用户画像与多维筛选的实现

社交产品运营最喜欢问一个问题：帮我筛出“最近7天活跃、关注了科技话题、女性、24-30岁、在一线城市”的用户。这个需求拆开看，是用户基础属性、行为标签、关注话题三个维度的交叉，跨了多张表。

我的做法是把画像标签做成扁平化的标签表，每个用户一行，标签用JSON对象存储，各标签值建好索引。筛选的时候SQL可以这样写：

SELECT u.user_id, u.nick_name, u.age, u.city FROM users u JOIN user_tags t ON u.user_id = t.user_id WHERE t.tags @> '{"gender":"female","city_level":1}'::jsonb AND u.age BETWEEN 24 AND 30 AND EXISTS ( SELECT 1 FROM user_follows f JOIN topics tp ON f.topic_id = tp.topic_id WHERE f.user_id = u.user_id AND tp.topic_name = '科技' ) AND (u.last_active_at >= CURRENT_DATE - INTERVAL '7 days') LIMIT 1000;

这段SQL里最核心的是JSON字段上的包含查询。如果标签字段设计成独立关联表、每个标签一行，那筛选三个标签至少三路JOIN，性能很难接受；用JSON后置索引，一个条件就过滤掉大部分无关用户，效果立竿见影。注意LIKE模糊匹配在社交场景要少用，尤其是前模糊和后模糊，能走倒排索引就尽量走。

用户画像查询还有个经验：宁可在标签表上多放几个冗余字段，也别让业务SQL频繁地做多表JOIN。比如“城市等级”这个字段，既出现在用户基础表也复制到标签表，一眼看去违反三范式，但在社交这种读多写少的画像场景里，冗余带来的查询性能收益远大于存储成本。代价只是更新用户城市等级时多更新一个副本，事务里改一行和改两行差别不大。

3.2 关系链扩散与话题传播计算

社交关系分析里最典型的计算是“二度人脉”“关注链传播”“话题扩散路径”。用传统SQL的自连接实现层级很深时特别痛苦，比如查“用户A通过两层关注能触达哪些用户”，自连接两层已经是SQL地狱，再往上就基本没法维护了。

YashanDB兼容Oracle的层次查询语法，这让我处理关系链扩散时舒服很多。比如查用户A三层以内的关注扩散：

SELECT DISTINCT u.user_id, u.nick_name FROM ( SELECT CONNECT_BY_ROOT follower_id AS root_id, followee_id FROM user_follows START WITH follower_id = :userId CONNECT BY NOCYCLE PRIOR followee_id = follower_id ) f JOIN users u ON u.user_id = f.followee_id WHERE f.root_id = :userId AND LEVEL <= 3;

NOCYCLE是关键，社交关系里存在互关和成环的情况，不用NOCYCLE会死循环。我第一次跑这个查询时没加，SQL直接跑挂，后来才知道这种递归查询必须显式处理环。另外递归深度也要控制，社交关系链的幂律特征很明显，到两三层数量级就很大了，再往下跑既慢也没业务意义，通常限制在三到四层。

话题传播计算也是类似思路。平台上一个热点话题，想知道它是怎么从大V扩散开的，本质是在转发关系上做路径追踪。我把转发关系存成一张表，每条记录包含原帖ID、转发者ID和转发时间，转发时把路径字段附加在上面，比如/uid1/uid2/uid3这种字符串。查询某个话题的传播路径时，用LIKE匹配路径前缀，配合倒排索引，一次查询就能拿到整条传播链。路径字段的维护成本极低，但带来的查询便利性是几何级别的。这就是典型的“用空间换时间”。

3.3 内容推荐与相似度计算的SQL写法

社交内容推荐，如果不想一开始就上复杂的推荐系统，可以用SQL做基础版本的协同过滤和内容相似度计算，效果在冷启动阶段足够用了。

基于用户行为的内容相似度，核心是看两个内容被同一批用户消费的重合度。SQL思路很直接：先找出对某内容有过正向行为的用户集合，再统计这些用户还消费过哪些其他内容，按重合度排序。比如求与帖子A最相似的内容：

SELECT interact_content_id AS similar_id, COUNT(DISTINCT user_id) AS common_users, COUNT(*) * 1.0 / ( SELECT COUNT(DISTINCT user_id) FROM content_interactions WHERE content_id = :targetId AND action_type IN ('like','share') ) AS similarity FROM content_interactions WHERE user_id IN ( SELECT user_id FROM content_interactions WHERE content_id = :targetId AND action_type IN ('like','share') ) AND interact_content_id != :targetId GROUP BY interact_content_id ORDER BY common_users DESC, similarity DESC LIMIT 20;

这条SQL我先说结论：数据量小的时候随便跑，数据量大了就要小心。content_interactions 表如果上千万行，IN子查询会非常重，一遍遍扫描。我的做法是限制用户集合规模，只取最近30天有正向行为的用户，再对这些用户的行为记录做聚合，这样数据量缩小到几百万行内，列存加持下，单次计算能在一两秒内完成。对实时性要求不高的内容相似度计算，完全可以夜间批量算完结果表，白天只做查表。

文本内容相似度这块，社交平台常做“相似话题推荐”，本质是话题关键词的集合重合度。我把话题关键词洗好存在JSON数组里，用数组重叠判断来算Jaccard相似度。YashanDB对数组类型的支持配合GIN索引，查询时能直接命中倒排，比拆表关联快得多。相关SQL大致长这样：

SELECT topic_id, topic_name, 1.0 * CARDINALITY(topic_keywords & :targetKeywords) / CARDINALITY(topic_keywords | :targetKeywords) AS jaccard_sim FROM topics WHERE topic_keywords && :targetKeywords ORDER BY jaccard_sim DESC LIMIT 10;

这个方案的优点是直接、可解释、不用引入外部向量数据库；缺点是只能做关键词级别相似度，语义上的相似它判断不了。如果想做语义相似，基本得走向量化路线，可以先用外部工具生成向量，再把向量存到YashanDB里做近邻查询。社交场景的推荐不追求一步到位，先从可用的关键词方案开始，后续再逐步迭代到向量方案，是比较务实的路线。

4. 让查询快起来的索引与调优实录

4.1 索引选型：B+树、哈希、倒排的组合套路

社交场景没有一种索引能包打天下，我的经验是组合使用。

用户表和帖子表的主键查询、唯一查询，用B+树索引就对了。B+树支持范围查询和排序，非常适合“按时间倒序拉帖子”“按分数拉榜单”这类需求。哈希索引适合等值查询，比如按token查用户、按手机号查绑定关系这种场景，哈希索引的查找复杂度是常数级别，比B+树的树高更稳定。但注意哈希索引不支持范围查询，别在排序和时间范围上用它。

倒排索引是社交场景的隐形主角。内容搜索、标签查询、话题过滤、JSON字段匹配，全靠它。我在标签表、话题表的JSON字段上建了倒排索引后，之前几个秒级甚至超时的筛选查询直接降到百毫秒级。尤其JSON字段的包含查询，没有倒排索引基本就是全表扫描的运气成分，有了倒排索引就和搜索引擎查关键词一样高效。

实际建索引要克制，不要为每个字段都建索引。索引不是越多越好，每个索引都会拖慢写入速度、占用存储空间。我在社交项目里总结出一个原则：先统计真实查询模式和频率，只给高频查询条件建索引，低频查询宁可用全表扫描或离线计算。

4.2 执行计划解读与慢SQL排查

YashanDB支持查看执行计划，这是我排查慢SQL的第一工具。拿到一条慢SQL，我习惯先看执行计划里几个关键信号。

第一个信号是驱动表。SQL里第一张被访问的表往往决定了查询的起点，如果驱动表是应该被过滤到很小结果集的大表，说明优化器选择有问题，通常需要检查统计信息是否过期，或者手动提示调整驱动顺序。

第二个信号是JOIN方式。社交场景大量JOIN走哈希连接，尤其是大数据量等值连接，哈希连接是合理的。但如果看到嵌套循环连接且内层表没有索引，每次外层行都要全表扫一遍内层，那就很危险。解决方法是给内层表的连接键建索引，或者改成哈希连接。

第三个信号是排序和分组。社交场景的SQL里ORDER BY和GROUP BY特别多，如果执行计划出现明显的排序操作，且排序量很大，通常会导致临时文件落盘。解决思路是让索引顺序匹配排序顺序，或者把排序字段加到索引里，让优化器直接走索引顺序避免额外排序。

我遇到过一个典型慢SQL：查“过去7天活跃用户中按城市分组计数”。表有5000万行，开发写的SQL是直接对行为表做GROUP BY。执行计划显示全表扫描加哈希分组，跑了18秒。后来改成先过滤出活跃用户ID集合，再JOIN用户表分批取城市字段聚合，同一个结果跑进了400毫秒。这个案例说明，社交场景里“先缩小范围再聚合”远比“全量聚合再过滤”高效。

统计信息更新这件事容易被忽略。YashanDB的优化器依赖统计信息来做成本估算，如果表数据量因为活动等原因暴涨，统计信息还是旧的，优化器就会给出离谱的执行计划。我在社交项目里养成了习惯，每次大促活动前后都会手动刷新关键表的统计信息，平时晚上跑一次自动更新。别等慢SQL出现了才想起来。

4.3 分区与分布策略实战

社交数据量大之后，单表不加分区或分布策略，迟早出问题。我的做法是按时间分区加按用户分布式设计双管齐下。

互动流水表、行为日志表这些时间特征明显的表，按时间做范围分区是最自然的思路。按月分区，查询时带上时间范围，优化器能自动裁剪到只扫少量分区。比如查某用户最近7天的互动记录，如果表是按月分区的，那么最多跨两个分区；如果表没有分区，要从几亿行里扫，代价完全不同。时间分区还有一个附带好处：删除过期数据可以直接DROP分区，比逐条DELETE快了不止一个数量级，这对社交业务定期淘汰旧日志非常重要。

用户维度的大表，比如关注关系表，需要按分布键切分到分布式节点。分布键选用户ID后，同一个用户的所有关注记录都落在一个节点上，查询单用户的关注列表、被关注列表都是本地操作，天然避免跨节点网络开销。但需要注意，按分布键设计时，业务查询必须带上分布键条件才能获益。如果查询条件只有帖子ID而没有用户ID，那么数据会被广播到所有节点执行，性能反而更差。这要求我把分布键和业务查询模式一起设计，先梳理核心查询的过滤字段，再决定分布键。

分区和分布不是互斥的，可以叠加使用。比如互动流水表既按月分区，又按用户ID分布，数据层先按用户分散到节点，每个节点内部再按时间分区。这样既获得了分布式扩展，又保留了分区裁剪能力。设计时复杂度会高一些，但换来的是长期稳定性，值得花这个精力。

5. 从OLTP到OLAP：混合负载下的稳定性保障

5.1 事务与分析查询的资源隔离

YashanDB的HTAP能力让社交场景可以在一套系统里同时跑事务和分析，但这不代表你可以什么都不管。混合负载最怕的是分析大查询把CPU和IO吃满，导致线上核心链路的写事务延迟飙升。

我管理生产环境时的做法是分层控制。首先是SQL层面限流，对跑分析类查询的应用账号做资源限制，限制单查询的扫描行数、内存使用量、执行时间。大查询一旦超出阈值自动报错，不会拖垮整个集群。其次是时间窗口错峰，虽然HTAP能在线跑分析，但能错开的尽量错开。运营报表、画像批量计算这类任务，放到凌晨低峰期执行；白天只保留必要的实时看板统计，且单次查询严格带上时间范围过滤，控制在数百万行以内。

更细一层的经验是让分析查询尽量利用列存。YashanDB里同一张表的列存部分是专门为分析场景优化的，OLAP型查询在列存上执行比行存快很多。我建表时就把预计有大量聚合查询的表设置为行列混合存储，写事务更新行存，分析SQL自动走列存，数据实时一致，对业务完全透明。这个能力是HTAP体验的关键，不然分析查询和事务查询共享行存，再怎么做限流也只是延缓问题。

我强烈建议生产环境把核心事务应用和数据分析应用用不同的账号接入，并为分析账号设置单独的资源配置。这样即使某个分析查询失控，也只影响它所在的资源组，不会拖累线上核心链路。这个经验不是YashanDB独有的，但混合负载场景下尤其重要。

资源隔离后还要盯监控。我接入YashanDB后的第一件事就是搭建关键指标的监控看板：CPU利用率、内存使用、磁盘IO、活跃会话数、慢SQL数量、事务延迟分布。告警规则要设置在实际出问题之前，比如事务P99延迟超过基线2倍就告警，慢SQL数量在一小时内连续猛增就告警。只有监控到位了，才能放心让HTAP跑起来，不然就像闭眼开车一样心里没底。

5.2 好友圈时间线常用更新策略与数据归档

社交产品的热门查询是“拉取用户时间线”，也就是用户关注的所有人的帖子按时间倒序排列。这种feeds流查询不能靠实时JOIN关注表和帖子表来做，数据量大后必然超时。我的方案是把时间线聚合结果物化为一张缓存表，用户发生关注动作或好友发布帖子时，增量更新这张缓存表——好友发帖时，把他的帖子ID推送到所有粉丝的缓存列表里；用户新增关注时，把他已发布的帖子批量拉入缓存列表。

这种物化表在YashanDB里跑得很顺，因为它是典型的高频点更新加范围读取，行存和索引正好覆盖。维护物化表的任务是异步的，用队列消费，不阻塞主事务。这样设计后，用户拉取时间线的SQL变成对缓存表的单表范围查询，加上LIMIT分页，毫秒级返回，效果非常明显。比一次性实时JOIN的SQL快了几十个数量级（前提是物化表不失控）。

数据归档这块，社交场景必须养成好习惯。互动流水表几亿行，真正能被近期业务用到的可能只有最近3个月。我的策略是把在线表按时间生命周期管理，超过3个月的数据定期迁移到离线归档区，在线表只保留热数据。归档前先确认归档数据被哪些查询使用，如果还有月度报表依赖，就先把对应的聚合结果算好存到统计表，再归档原始明细。归档操作建议用批量任务在低峰期跑，每次处理一个分区，避免长时间大事务锁表、拖垮线上。

归档后要注意表膨胀问题。频繁更新和删除在数据库里会产生大量旧版本数据，如果长时间不整理，查询性能会逐步恶化，存储空间也白白浪费。我习惯每月对核心大表做一次存储整理，把数据重整一遍，回收无用空间。这个操作要放在业务低峰期执行，并评估对线上会话的影响。

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

6.1 社交查询场景问题速查表

我整理了一张排查速查表，遇到问题先对照定位，能省不少时间：

这张表里最常触发的一个问题还是统计信息过期。社交业务的活动性质和热点事件让表数据量经常突增突降，优化器基于旧统计做决策，很容易选错执行计划。我建议核心表都纳入统计信息自动更新任务，大促前后各手动更新一次。

6.2 写入放大与锁等待的避坑经验

社交场景并发高，写入放大和锁等待是绕不开的两个对手。写入放大最典型的例子是索引数量失控。一张帖子表如果要支撑按作者查、按时间查、按标签查、按状态查，四个维度各建一套索引，那么每插一条帖子，就要同步维护四个索引，写入量瞬间放大四倍。我的建议是控制在三个以内的核心索引，够用的索引才是好索引。

锁等待这块最常见的是“同一热点用户被疯狂读写”。大V发布帖子后，成千上万的粉丝同时请求刷他的主页，如果数据都落在同一个节点甚至同一行上，行锁竞争会很严重。缓解思路有几种：第一，热点用户的数据做读写分离，读走只读副本，写保持主本；第二，把同一个人频繁更新和读取的字段拆到不同表，比如帖子正文走内容表，点赞和评论统计走聚合表，减少同一行的锁冲突；第三，对统计类的更新不用实时强一致，用异步队列批量合并更新，把一小时内的点击和点赞合并成一百次写，而不是一百万次写。

还有一个小坑是应用层的批处理SQL没有分批，一次性更新几十万行数据，造成长时间持锁。我的经验是批量更新一定分批执行，每批控制在几千行内，批次之间留出间隔，让其他事务有机会执行。看起来麻烦，但能避免把核心业务的写路径堵死。这条经验没什么技术含量，但真实救过我很多次。

6.3 开发习惯与长期运维建议

社交业务迭代快，数据库层经常被遗忘。我见过太多项目在开发阶段顺风顺水，上线三个月后性能雪崩，复盘时发现都是开发早期埋下的雷。

我坚持三个习惯。第一，SQL评审。项目里所有核心SQL上线前必须过一道执行计划，确认它能走合理的索引、不出现明显全表扫描、JOIN顺序正常。这一步能挡住百分之八十的初期性能隐患。第二，定期做容量评估。社交数据量增长不是线性的，一个爆款内容就能让某张表的写入翻倍。月度评估一次数据量、存储占用、CPU和IO趋势，提前发现扩容需求，远比线上告警后再救火从容。第三，做好核心表血缘和数据字典维护。社交业务人员流动大，几年后没人知道某些表是谁建的、字段含义是什么、哪些表还在生产环境被使用。数据字典是长期维护的基石，没它后面做架构演进会极其痛苦。

异步化是社交场景的生存法则。能异步的尽量异步，比如计数、榜单、画像更新、消息推送这些逻辑，一律丢进队列异步执行。数据库只承载核心强一致写和读，其余全部在应用层削峰填谷。YashanDB本身扛并发很稳，但再稳定的数据库也经不住什么都往里塞。

关于YashanDB在社交网络数据中的使用，我整体的体会是：选对存储模型、控制事务粒度、把索引设计纳入开发流程，比单纯指望某个数据库魔法功能更重要。YashanDB的HTAP和兼容Oracle特性确实省了很多事，但社交业务永远是流量突发、模型复杂的场景，底层的表结构和SQL设计才是决定成败的地方。如果你正在做类似项目，建议先小规模验证几个核心场景——用户画像筛选、关系链查询、时间线拉取、内容相似度计算——跑通了再逐步扩展。这几个场景能跑稳，社交数据的大半价值就都发挥出来了。

最后再分享一个小技巧：社交数据的很多性能问题，其实可以从查询语义上换个思路绕开，不一定非要堆机器。比如“全站热门内容”这种查询，天生就是重聚合，非要实时算就会很痛苦。把它拆成“最近5分钟的热门”和“24小时的历史热门缓存”，前者小范围实时计算，后者预计算结果表，体验几乎一样，成本和性能却天差地别。做社交数据开发，技术功底只是基础，能不能站在业务视角重新定义查询和存储需求，才是拉开差距的关键。