大并发下 结构梳理 你的数据库表或许成为性能隐患

用户中心是典型的读多写少系统，咱们的许多系统也属于这种类型。这类系统经过引入缓存技术可以清楚优化性能。在流量增大时，用户中心通常成为系统优化的首要模块，由于它通常与多个系统有高度耦合。因此，梳理和优化该模块关于整个系统的高并发变革至关关键。

咱们将专一于优化读多写少的用户中心数据整顿，使其更容易启动缓存。数据梳理是一项关键技艺，关于任何须要高并发变革的老系统，倡导先对数据库表启动梳理。老系统在经常使用数据库时，通常存在诸多疑问，例照实体表字段过多、表查问维度和用途多样、表相关凌乱，甚至存在m:n相关。这些疑问都会参与缓存变革的难度，严重影响变革进展。

经过从数据结构入手，先在特定场景下启动优化，再实施缓存技术，将会极大简化后续的高并发变革。因此，梳理数据库结构是启动系统高并发变革的关键一步。

精简数据会有更好的性能

用户中心的关键配置是保养用户信息、用户权限和登录形态，它保管的数据大局部都属于读多写少的数据。用户中心经常出现的优化模式关键是将用户中心和业务彻底拆开，不再与业务耦合，并适当参与缓存来提高系统性能。

我举一个繁难的例子：过后整表内有凑近 2000 万的账号信息，我对表的配置和字段启动了业务解耦和精简，让用户中心的账户表里只会保管用户登陆所需的账号、明码：

          utf8mb4_unicode_ci     utf8mb4_unicode_ci     utf8mb4_unicode_ci                     utf8mb4 utf8mb4_unicode_ci

数据库是系统的外围，假设它体现缓慢，一切业务都会遭到影响，整个服务的性能很难超越外围数据库的下限。精简账号表字段的外围在于：更短的数据长度在吞吐、查问、传输上更快，治理缓和存也更繁难。精简后的表字段更少，业务用途繁多，通常只用于检测用户登录账号明码能否正确，而不触及其余访问或范围查问。这种精简的表在性能上体现出色，即使存储了两千万个账号，全体体现依然优秀。

不过，须要留意的是，只管精简数据可以提高照应速度，但适度精简并无法取。假设表字段不足适当的冗余，会造成业务虚现复杂化。例如，假设账户表精简掉用户昵称和头像字段，那么每次登录都须要额外读取一次性数据库，并一直关注缓存同步降级；同样，假设保管这些字段，登录验证后就可以间接启动其余业务操作，无需再次查问数据库。由此可见，精简几个字段往往会造成额外的数据库查问，同时参与缓存同步累赘，得失相当。因此，咱们须要在“更多字段”和“更少职能”之间找到正当的平衡点。

数据的归类及深化整顿

除了经过精简表的职能来提高表的性能和保养性外，咱们还可以针对不同类型的表做不同方向的缓存优化，如下图用户中心表例子：

数据关键分为四种类型：实体对象主表、辅佐查问表、实体相关和历史数据。不同类型的数据须要驳回不同的缓存战略。假设将一些职能不明晰的数据强行放入缓存，经常使用时或许会遇到许多复杂疑问。

我曾遇到一个典型的失误做法：将用户来访记载这种继续增长的操作历史放入缓存。这个记载的关键用途是统计好友和生疏人来访的数量，但它同时保管了用户的好友相关标记。这象征着，一旦用户相关出现变动，这些历史数据就须要同步降级，否则好友相关将变得“过期”。

将历史记载和须要实时降级的好友形态混在一同，显然不正当。假设咱们做归类梳理的话，应该拆分红三个职能表，区分启动治理：历史记载表，不做缓存，仅展现最近几条，极其状况暂时缓存；好友相关（缓存相关，用于统计有几个好友）；来访统计数字（暂时缓存）。

数据实体表

首先来看用户账号表，这是一个实体表，通常作为主表，每行数据代表一个独立的实体，并且每个实体都有一个独立且惟一的 ID 作为标识。在这里，“实体”指的是一个形象事物，而详细字段示意该实体的实时形态属性。这个 ID 在高并发环境下的缓存中至关关键，用户登录后可以经过自己的账户 ID 极速查找对应的订单、昵称、头像和好友列表信息。假设业务关键经过这种模式查找，性能会十分好，且十分适宜常年缓存。

但是，除了按 ID 查找外，还有一些业务须要经过组合条件启动查问，比如：7 月 4 日购置耳机的订单有哪些？在天津的新注册用户有多少？老用户的数量又是多少？昨天能否有用户名以 rick 扫尾的账户注册？这类基于条件的查问和统计数据并不适宜做缓存，由于高并发服务中的缓存数据通常是能经过 Hash 极速婚配的，而带条件查问的统计数据容易出现不分歧性和数据量不确定性，造成性能不稳固。此外，假设相关数据出现变动，咱们也很难确定应该同步降级哪些缓存。

因此，这类数据更适宜寄存在相关数据库中，或许提早计算结果并放入缓存中启动经常使用，并活期降级。

除了组合条件查问难以缓存外，像 count()、sum() 这类须要实时计算的操作也存在降级不迭时的疑问，只能活期缓存汇总结果，防止频繁查问。因此，在后续开发中，咱们应尽量防止经常使用数据库来启动实时计算。

回到实体表的设计，这类表通常针对业务的关键查问需求而设计。假设咱们偏离这个设计用途来查问表，性能往往会大打折扣。比如，用于账户登录的表，当咱们用它来查问昵称中能否蕴含“极客”时，须要额外参与对“用户昵称”字段的索引。这类 LIKE 查问会扫描全表数据启动计算，并且若查问频率较高，或许会严重影响其余用户的登录体验。同时，参与的昵称索引会降落该表拔出数据的性能，这也是为何在后盾系统中，通常会独自分出一个从库，做不凡的索引查问。

在高并发场景中，为了优化读取性能，缓存通罕用于保管实体数据。经常出现的方法是经过“key 前缀 + 实体 ID”失掉数据（例如 user_info_9527），而后应用缓存中的关联相关进一步失掉指定数据。例如，经过 ID 间接失掉用户好友相关的 key，从而失掉用户好友 ID 列表。经过这种模式，咱们可以在 Redis 中成功用户的罕用关联查问操作。

总体来说，实体数据是咱们业务的关键承载体，当咱们找到实体主体的时刻，就可以依据这个主体在缓存中查到一切和它无关联的数据，来服务用户。如今咱们来稍微总结一下，咱们整顿实体表的外围理路关键有以下几点：精简数据总长度；增加表承当的业务职能；增加统计计算查问；实体数据更适宜放在缓存当中；尽量让实体能够经过 ID 或相关模式查找；增加实时条件挑选模式的对外服务。

实体辅佐表

为了精简数据并便于治理，咱们经常依据不同用途对主表启动拆分，经常出现的模式是纵向表拆分。纵向表拆分的关键目的有两个：一是将经常使用频率较低的数据摘进去，以精简主表的职能；二是辅佐表的主键通常与主表分歧或经过记载 ID 关联，它们之间的相关多为 1:1。辅佐表中保管的数据普通在关键业务查问中不经常使用，仅在特定场景下取用，比如用户账号表用于用户登录，而辅佐信息表保管家庭住址、省份、微信和邮编等不常展现的信息。

辅佐表的另一个作用是辅佐查问。当原有业务数据结构无法满足其余维度的实体查问时，可以经过辅佐表成功。例如，一个以“老师”为主体的表，通常依据“老师 ID + 条件”查问在校生和班级数据。但当系统从在校生的角度登程时，须要频繁以“在校生和班级”为基础查问老师数据，这时就需先查出“在校生 ID”或“班级 ID”，再查找老师 ID，既不繁难又低效。因此，可以将在校生和班级数据拆分到一个辅佐表中，繁难这些查问。

值得提示的是，辅佐表和主体表之间或许存在 1或 m的相关，因此咱们须要活期整顿和核查数据，以确保冗余数据的同步和完整。但是，保养非 1:1 数据相关的辅佐表并不容易，容易造成数据不分歧或提早，有时还需刷新一切相关相关的缓存，既耗时又费劲。经过脚本活期口头数据核查，找出差异会愈加繁难。此外，为提高查问效率，咱们经常在多个表中冗余同一数据，数据降级时需同步降级冗余表缓和存。

行业内也罕用一些开源搜查引擎辅佐启动相似的相关业务查问，例如经常使用 ElasticSearch 启动商品检索，经常使用 OpenSearch 启动文章检索等。这些可横向扩容的服务能够清楚减轻数据库查问压力，但其惟一缺陷是很难成功数据的强分歧性，因此须要人工检测和核查两个系统的数据。

实体相关表

接上去咱们再谈谈实体之间的相关。

关于相关型数据，我剧烈倡导经常使用一个额外的相关表来记载实体间的 m

关联相关，这样两个实体无需相互依赖，更容易保养。关于 1:n或 m:n相关的数据缓存，倡导提早评价或许触及的数据量，防止缓存数据量过大影响性能。普通状况下，咱们会用主体的 ID 作为缓存 key，value 中保管多个关联 ID 以记载数据间的相关。关于访问频率特意高的业务缓存，可以将数据按相关提早组织好，全体缓存，以便极速查问和经常使用。

须要留意的是，这种关联数据往往会发生多级依赖，使得数据整顿十分复杂。当相关表或查问条件降级时，咱们必定及时同步缓存中的数据。因此，多级依赖在高并发系统中很难保养，通常会降落分歧性要求以满足高并发需求。

总结一下，哪些数据适宜做缓存？通常来说，能够经过 ID 准确婚配的数据实体十分适宜缓存；经过 String、List 或 Set 指令构成的多条 value 数据结构适宜用于（1:1、1:n、m:n）辅佐或相关查问。另外，只管 Hash 结构适宜用于实体表的属性和形态存储，但 Hgetall 指令性能较差，容易造成缓存卡顿，不倡导经常使用。

举措历史表

普通来说，举措历史数据表用于记载数据实体的举措或形态变动环节，比如用户登录日志、积分生产或失掉记载等。这类数据随着期间不时增长，关键用于记载和展现近期的信息，不倡导将其用于业务的实时统计计算。

你或许对这个倡导有不懂，那我举个例子来说明：假定咱们有一个积分支付记载表，蕴含 2000 万条记载，如今须要统计某个用户支付 ID 为 15 的商品的数量。这种状况下，假设间接对这张表启动实时统计计算，不只效率低，还会参与数据库的累赘。因此，不倡导将这类历史数据用于高频的实时统计。

                                          uid   utf8mb4utf8mb4_unicode_ci uid   action_count product_id user_score_history uid       action_id        uidaction_id

可以看出，这类表的数据量十分大，记载了少量的实体操作历史，并且字段和索引并不适宜启动这种查问。当咱们计算某个用户支付 ID 为 15 的商品数量时，只能先经过 UID 索引过滤数据以增加范围。但是，即使这样挑选，数据量依然宏大。随着期间的推移，这张表的数据会不时增长，查问效率也会逐渐降落。

因此，关于这种须要依赖少量数据统计得出的论断数据，不倡导对外提供实时统计计算服务，由于这种查问会严重拖慢数据库，影响系统的稳固性。即使经常使用缓存来暂时保管统计结果，这也只是权宜之计。更好的打算是借助其余表来成功这类需求，比如设置一个实时查问支付记载表，以取得更高的查问效率。

默认总结：

1. 数据梳理是关键技巧，对表启动梳理可处置老系统在高并发变革中的疑问。

2. 平衡“更多字段”和“更少职能”可提高性能，防止适度设计。

3. 对不同类型数据启动归类处置，拆分红不同表治理，可提高系统性能和保养性。

4. 实体数据适宜放在缓存中，经过ID或相关模式查找，增加实时条件挑选对外服务。

5. 辅佐表数据不适宜放在缓存中，保营养歧性较为费事，须要活期核查和同步降级。

6. 实体相关表的缓存治理复杂，需降落分歧性要求以满足高并发状况。

7. 依据ID能够精准婚配的数据实体适宜做缓存，而经过String、List或Set指令构成的有多条value的结构适宜做辅佐或相关查问。

8. Hash结构适宜做实体表的属性和形态，但Hgetall指令性能并不好，不倡导经常使用。