keycloak~大数据量时坑出现~索引的坑

最新推荐文章于 2023-01-16 22:53:09 发布

Gerald Newton

最新推荐文章于 2023-01-16 22:53:09 发布

阅读量534

点赞数

文章标签： java spring 程序人生学习 struts

本文链接：https://blog.csdn.net/m0_68064743/article/details/124445621

版权

本文讲述了在使用Keycloak时遇到的性能问题，由于未对查询字段加索引，当用户表数据量达到几十万，导致所有增删改接口响应缓慢。作者分享了自己在大数据量场景下寻找问题根源的过程，并提出关注索引优化对于提升系统性能的重要性。

摘要由CSDN通过智能技术生成

我不知道为什么kc没有为对应的查询字段加索引，导致我们在使用kc时，当用户表数据量达到几十万时，出现所有增删改接口缓慢的问题，这个问题的原因，我找了好长时间，我在大数据量时找这个缓慢原因过程

查看mysql的并发数的限制
查看top产生的cpu,内在的使用情况
查看客户端到kc端，kc端到数据库的网络传输限制
为k8s的资源进行调整，添加内存额度
为username字段添加索引
打开mysql日志功能，观察慢接口的日志
找到慢的语句
select userentity0_.ID as ID1_75_, userentity0_.CREATED_TIMESTAMP as CREATED_2_75_, userentity0_.EMAIL as EMAIL3_75_, userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_75_, userentity0_.EMAIL_VERIFIED as EMAIL_VE5_75_, userentity0_.ENABLED as ENABLED6_75_, userentity0_.FEDERATION_LINK as FEDERATI7_75_, userentity0_.FIRST_NAME as FIRST_NA8_75_, userentity0_.LAST_NAME as LAST_NAM9_75_, userentity0_.NOT_BEFORE as NOT_BEF10_75_,  userentity0_.REALM_ID as REALM_I11_75_, userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE12_75_, userentity0_.USERNAME as USERNAM13_75_ from USER_ENTITY userentity0_ where userentity0_.SERVICE_ACCOUNT_CLIENT_LINK='25e52f60-5991-43dd-9108-873f60af385d' and useren