我们使用的是不受支持的JIRA版本，即使我们拥有支持许可证，Atlassian也不会就此主题向我们提供支持。
上周我们的数据库上有一个补丁，我们看到系统上的查询数量从每天80万跳到超过3600万。 JIRA系统正在尝试从组中删除用户。以下是我们的EnterpriseDB日志
捕获的内容 "execute <unnamed>: DELETE FROM public.membershipbase WHERE USER_NAME=$1 AND GROUP_NAME=$2"
我们不明白为什么它会尝试这样做，并且非常感谢帮助找出原因。我已经检查了我们拥有的所有代码，我已经检查了DB中的所有函数，我已经查找了存储过程，甚至查看了所有视图。我没有看到任何可以进行上述调用的内容。如果您对此版本的JIRA有任何经验，请提供您的任何建议。根据我的阅读，从5.0版开始删除了USERBASE和MEMBERSHIPBASE表，这就是为什么我要求那些具有4.1.2知识的人。
答案 0 :(得分：1)
在此项目中实现了名为opensymphony的库包，用于创建查询。
为什么不让人们学习编写自己的SQL。它更清洁，更容易IMO。
答案 1 :(得分：0)
正如您所指出的，membershipbase表包含属于JIRA内部组的用户。我最好的猜测是你可能有JIRA设置使用LDAP / AD进行身份验证（使用Crowd？），并且它正在尝试将组成员身份的更改同步到JIRA。
例如，如果JIRA在一家大公司中为包含邮件列表等的组配置了过宽的LDAP过滤器，而另一家公司管理员要在LDAP中删除和/或移动一堆条目在过滤器之外的树，我可以看到这导致在JIRA中发生大量删除。
一个有用的命令就是这个（根据你的上述评论，我猜你需要从你的dBAs请求）：
SELECT GROUP_NAME, count(1) FROM public.membershipbase GROUP BY GROUP_NAME ORDER BY 1 DESC
报告每组中的用户数。然后在一分钟后再次运行相同的命令，并对输出进行差异。这应该可以让您了解哪些组正在被修改，而无需安装SQL监视工具。 （您可能还想查看JIRA中总共有多少组，并验证它看起来是合理的数字。）
无论哪种方式，您都可以深入了解正在更新/删除的实际用户，并开始询问其他系统管理员。
您也可以尝试重新启动JIRA以查看更新是否消失。如果它是合法/预期的LDAP同步操作，我想DELETEs会再次开始备份。
编辑添加：
Group Browser in the admin UI代替SQL查询，也会显示一些相同的信息，但不是特别适合于差异。
答案 2 :(得分：0)
修复方法是将1000个条目的限制更改为编码为100,000的用户的缓存。
我说这是一个黑客修复因为我们不理解编码的意图。代码中没有注释，也没有任何文档背后为什么它被设置为如此低的数字。
更新时间：2015年9月17日与Jira 6.x的培训师交谈之后 说这个问题不是基于Jira的。有人修改了 源代码。 Jira 4.x没有1000的限制器 缓存。