2
keycloak~大数据量时坑出现~索引的坑
source link: https://www.cnblogs.com/lori/p/15250202.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
keycloak~大数据量时坑出现~索引的坑
我不知道为什么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 userentity0_.REALM_ID='xxx' - 为两个查询字段添加索引
SERVICE_ACCOUNT_CLIENT_LINK和SERVICE_ACCOUNT_CLIENT_LINK - 问题解决！
最后，把这个问题产生的过程，和解决方法抛出来，并且我会在github上为redhat提出这个bug。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK