我们的应用中大约有100万用户。我们使用具有标准配置的Keycloak实例（https://hub.docker.com/r/jboss/keycloak/）。 此外，我们使用离线令牌，该问题以某种方式连接到了
offline_user_session 表中的记录越多，启动密钥库实例的时间就越多。
如果记录数为0，则开始大约需要30秒。
有80万个会话时，需要8分钟才能开始
大约有100万次会话时，它可以启动30分钟或更长时间
我试图在互联网上找到任何东西，并在官方文档中进行了查询，但仍然没有结果。
答案 0 :(得分：2)
在分析 user_session 离线表时，存在与定义此表的良好做法相关的问题。
| 字段 | 类型 | 空 | 键 | 默认 | 额外 |
|---|---|---|---|---|---|
| USER_SESSION_ID | varchar(36) | 没有 | PRI | NULL | |
| USER_ID | varchar(255) | 是 | |||
| REALM_ID | varchar(36) | 没有 | |||
| CREATED_ON | int(11) | 没有 | 多 | ||
| OFFLINE_FLAG | varchar(4) | 没有 | PRI | ||
| 数据 | 长文本 | 是 | |||
| LAST_SESSION_REFRESH | int(11) | 没有 | 0 |
在数据库层，我们有一个构造问题，当使用具有“varchar”类型的两列组成主键时。这种情况是出现问题的唯一原因，只有在有很多记录的情况下才会明显。
这个问题的解决方案是将主键交换为大整数数据类型，并将其保留为列（USER_SESSION_ID、OFFLINE_FLAG）作为唯一索引。但是，这涉及到应用层的配置调整，这应该与解决方案提供商一起看到。
| 字段 | 类型 | 空 | 键 | 默认 | 额外 |
|---|---|---|---|---|---|
| 身份证 | BIGINT | 没有 | PRIL | ||
| USER_SESSION_ID | varchar(36) | 没有 | UNI | NULL | |
| USER_ID | varchar(255) | 是 | |||
| REALM_ID | varchar(36) | 没有 | |||
| CREATED_ON | int(11) | 没有 | 多 | ||
| OFFLINE_FLAG | varchar(4) | 没有 | UNI | ||
| 数据 | 长文本 | 是 | |||
| LAST_SESSION_REFRESH | int(11) | 没有 | 0 |