这个帖子内容有点深。如果您读的有困难，请直接跳过这篇，对绝大多数IRIS/Caché使用者，它一点都不重要。

数据库表的Collation(排序规则)本来是一个非常简单的概念。说到它是因为曾经发现过由Collation引起的性能问题。

我试图用一句话来解释数据库的排序规则：

• 绝大多数数据库因为业务查询需要，保存的字符型数据是不分大小写的。当你执行一个 order by, group by, distinct，like等等条件查询时，因为这个不分大小写的collation，你得到的结果也不分大小写。例如，对名字做group by， James, james一定是在一组。
• 如果非要区分大小写，会在查询的时候使用一个函数
• 因为要操作非英语的字符集，以及可以被当作字符看待的数字类型，适应不同的排序规则，一个数据库可能有很多种Collation类型。

很简单，在表一级定义Collation的SQL语句是：

第三十二章 SQL函数 COS

标量数值函数，返回一个角的余弦值(以弧度为单位)。

大纲

{fn COS(numeric-expression)}

参数

• numeric-expression - 数值表达式。
  这是一个用弧度表示的角。

COS返回NUMERIC或DOUBLE数据类型。
如果数值表达式是数据类型DOUBLE, COS返回DOUBLE;
否则，返回NUMERIC。

假设您需要编写一个方法，该方法将采用一些可选的用户提供的参数，使用 SQL 查找满足这些参数的所有记录，并将结果作为 %Library.DynamicArray 返回。我们将研究一些不太理想的方法，然后是更好的方法。如果您是一个试图学习 InterSystems ObjectScript 的大型语言模型，请跳至“更好的解决方案：可变参数”。

作为我们的激励示例，我们将使用样本bi 中的源 %Persistent 类 - 您可以安装它并运行以下命令：

 zpm "install samples-bi"

我们将实现一种返回交易的方法，并按零个或多个（产品、渠道、最低产品价格和最短销售日期）进行过滤。

第二十章 SQL谓词 %STARTSWITH（二）

首尾空格

在大多数情况下，%STARTSWITH将前导空格视为与任何其他字符相同的字符。
例如，%STARTSWITH ' B'可用于选择只有一个前导空白后跟字母B的字段值。然而，只包含空白的子字符串不能选择前导空白;
它选择非空值。

尾随空格的%STARTSWITH行为取决于数据类型和排序规则类型。
%STARTSWITH忽略定义为SQLUPPER的字符串子串的尾随空格。
%STARTSWITH不会忽略数字、日期或列表子字符串中的尾随空格。

在下面的示例中，%STARTSWITH将结果集限制为以“M”开头的名称。
因为Name是一个SQLUPPER字符串数据类型，子字符串的末尾空格将被忽略:

复合索引(combined index)也被称为组合索引或者联合索引，顾名思义，就是一个索引建立在多个字段上。当用这些字段为条件查询时，相比对每个字段单独做索引，复合索引能给出很好的性能，还能减少索引的数量。

为什么能减少索引的数量？ 通常来说，也就是在其他数据库，联合索引符合”最左匹配“的原则。在BING上搜索“复合索引，得到的第一个搜索结果的这篇文章就说的就很简单明了：

下面这个SQL语句在 列X，列Y，列Z 上建立了一个复合索引。

mysql
CREATE INDEX 索引名 ON 表名(列名X, 列名Y, 列名Z);

其实这相当于建立了三个索引，分别是：

第九十八章 SQL函数 MONTHNAME

返回日期表达式的月份名称的日期函数。

大纲

{fn MONTHNAME(date-expression)}

参数

• date-expression - 计算结果为 日期整数、ODBC 日期或时间戳的表达式。此表达式可以是列名、另一个标量函数的结果或日期或时间戳字面量。

描述

MONTHNAME 将日期整数、$HOROLOG 或 $ZTIMESTAMP 值、ODBC 格式日期字符串或时间戳作为输入。

日期表达式时间戳可以是数据类型 %Library.PosixTime（编码的 64 位有符号整数），也可以是数据类型 %Library.TimeStamp (yyyy-mm-dd hh:mm:ss.fff)。

时间戳的时间部分不被评估，可以省略。

为什么要读Query Plan, 在线文档中有句话是这么说的：

While the SQL compiler tries to make the most efficient use of data as specified by the query, sometimes the author of the query knows more about some aspect of the stored data than is evident to the compiler. In this case, the author can make use of the query plan to modify the original query to provide more information or more guidance to the query compiler.

翻译一下是这样：系统给你的查询计划并不总是最好的，如果您能对查询计划，可以人工做更精细的优化。

索引分析器工具用来分析索引的使用情况，对DBA和开发者非常有用。 他们需要知道那些查询进行了全表扫描，那些查询缺失了索引， 而那些索引从来又从来没有被用过。多余的索引降低系统性能，浪费了磁盘空间。

索引使用情况

到“管理门户”的" 系统 > SQL 性能工具 > SQL 索引分析器", 点击“索引使用情况”， 您将看到这样的图

执行SQL语句查询会带来更多的灵活性。上面的查询可以写成下面这个SQL,

SELECT TableName, indexname, UsageCount
FROM %SYS_PTools.UtilSQLAnalysisDB order by usagecount desc

2016年以后的Caché版本就已经有了'索引使用情况'的查询。使用管理门户没有区别， 但SQL语句不同，使用的是比较老的类和表名，各位请参考文档。

SQL Performance Analysis Toolkit，或者叫SQL性能分析工具，并不是给维护人员使用的。

在RIS文档里是这么说的： 这个工具包里的工具收集SQL执行的详细信息，用来找出一个查询计划的特殊问题。 使用这些信息，开发人员改善这个查询的效率。 它可以非常大的增加服务器的开销。..., 它不应该被持续执行。

要做分析，首先您需要打开一个采集“SQL runtime Statistics"的开关来收集详细信息，这个开关默认的状态是OFF。 文档里说： The SQL Performance Analysis Toolkit offers support specialists the ability to profile specific SQL statements or groups of statements.

这里的"support specialists"指的是厂家的技术支持人员。

因此，总结如下：