这个问题现在有了一些新的发现。
首先，我找到了重现客户那里出现的那个复杂SQL语句的方法。这个现象其实是这样的：
- 当WebApplication的“List View Threshold” 数量大于 文档库中文件个数的时候，如果是非管理员的用户打开文档库，就会出现那样的SQL语句。
- 当“List View Threshold”数量小于文档库中文件个数的时候，如果是非管理员的用户打开文档库，会得到一个警告说文档库无法打开。而如果是管理员，就可以打开，而且SharePoint会使用另一个比较适合大数量的SQL语句(但是在数据量小的时候反而不如原来那个语句)来查询。
所以客户那里出现那个SQL 语句的原因是 “List View Threshold“调整得太大。而”List View Threshold”调大的原因，是为了让普通用户能够打开文档库。
但是其实我们有更好的办法可以在不调大“List View Threshold“(也就避免了SharePoint使用适合小数据量大SQL语句操作大数据量的文档库，从而造成性能问题)的前提下，让普通用户也打开文档。
方法是执行下面的PowerShell 脚本。
$app=Get-SPWebApplication “http://<site url>”
$app.UnthrottledPrivilegedOperationWindowEnabled=$true
$app.DailyUnthrottledPrivilegedOperationsDuration=24
$app.Update()
这个脚本的目的是修改SharePoint对于大List/Library(也就是list item数量操作 List View Threshold的list )操作的一个开关。SharePoint 2013可以规定一天中某些时段允许普通用户打开大List。默认是不允许的，目的是为了整个系统的Scalability。但是在客户的这个环境中，访问这些大文档库是必须的，所以我们可以修改为一天中24个小时都能够让普通用户访问大list。
这样List View Threshold不再是限制用户访问的一个阈值，而是SQL语句优化的一个阈值。通常List View Threshold 设置5,000是比较合适的。客户那里有约30,000个文档，所以肯定会使用优化的语句。
下面的PowerShell脚本可以比较方便地修改这个值。
$app=Get-SPWebApplication “http://<site url>”
$app.MaxItemsPerThrottledOperation=5000
$app.Update()
遗憾的是SharePoint这些比较高级的调优功能(应该说是设计很巧妙的)，缺乏文档说明。所以很少有人知道。MSDN有关于这两些设置的字面解释，但是没有给出生动的范例来说明其用途。我们只能够通过程序的调试，从源代码中看出这些设置的实际用途。