小编Dan*_*SQL的帖子

在SQL中，据我所知，逻辑查询处理顺序，也就是概念解释顺序，以FROM开头的方式如下：

1. 从
2. 在哪里
3. 通过...分组
4. 有
5. 选择
6. 订购者

按照这个列表很容易看出为什么 WHERE 子句中不能有 SELECT 别名，因为别名还没有被创建。T-SQL (SQL Server) 严格遵循这一点，在通过 SELECT 之前不能使用 SELECT 别名。

但是在 MySQL 中，可以在 HAVING 子句中使用 SELECT 别名，即使它应该（逻辑上）在 SELECT 子句之前处理。这怎么可能？

举个例子：

SELECT YEAR(orderdate), COUNT(*) as Amount
FROM Sales.Orders
GROUP BY YEAR(orderdate) 
HAVING Amount>1;

该语句在 T-SQL 中无效（因为 HAVING 指的是 SELECT 别名Amount）...

Msg 207, Level 16, State 1, Line 5
Invalid column name 'Amount'.

...但在 MySQL 中工作得很好。

基于此，我想知道：

• MySQL 是否在 SQL 规则中走捷径来帮助用户？也许使用某种预分析？
• 还是 MySQL 使用的概念解释顺序与我虽然所有 RDBMS 都遵循的顺序不同？

我有一个 SQL Server 2012 (SP1) #cu5 (X64) 实例用作 SharePoint 2010 后端，大多数情况下仅使用 10 - 30% 的 CPU，但在运行 FAST 搜索爬网（增量和完整）时 CPU 使用率很高）。

按照 Microsoft 对 SharePoint SQL 实例的建议，自动创建和自动更新统计已关闭，SharePoint 应该使用健康分析器规则和计时器作业来处理统计和索引维护。在大多数情况下，它做得不错，但在调查创建高 CPU 使用率的查询时，我发现缺少统计信息，但我无法创建它们，因为修改 SharePoint 数据库会使它们不受支持。

如果您遇到过类似的情况，请告诉我，任何有用的建议都会被采纳。如果您认为https://sharepoint.stackexchange.com/是发布此内容而不是 DBA SE 的最佳位置，也请告诉我。

SQL Server 环境： HP ProLiant DL385p Gen8、Microsoft Windows Server 2008 R2 Enterprise SP1、AMD Opteron(tm) 处理器 6204（单插槽、2 核、支持 HT）Microsoft SQL Server 2012 (SP1) #cu5 (X64)

SharePoint 环境（我现在没有太多详细信息）：SP 2010 SP2（2 个应用服务器、2 个 Web 服务器、1 个 FAST 搜索服务器）