第二十八章 T 开头的术语

以 T 开头的术语

表 (table)

InterSystems SQL

表是一种由表示特定实体的行和表示每个实体特定数据点的列组成的数据结构。

目标角色 (target role)

系统

在受保护的 IRIS 应用中，由应用程序授予给已经是其他角色（称为匹配角色）成员的用户的角色。如果用户拥有匹配角色，则在使用应用程序时，用户还可以被授予一个或多个额外的目标角色。

目标用户 (target user)

系统

试图认证到 LDAP 服务器的用户。IRIS 通过在特定 LDAP 配置的“编辑 配置”页面上的 唯一搜索属性字段中使用提供的值，尝试在 数据库中查找该用户。可以从 配置页面（系统管理 > 安全 > 系统安全 > 配置）访问“编辑 配置”页面。（请注意，如果启用了 ，页面名称和菜单选项中会包含 。）

TCP/IP

通用

传输控制协议/互联网协议（），是可以管理关系客户端和关系服务器之间连接的通信协议之一。也称为 TCP。

临时全局 (temporary global)

系统

存储在临时数据库 中的全局。请参见临时全局和 数据库。

终端 (Terminal)

系统

正式而言，该术语指的是 终端应用程序。非正式而言，该术语也可以指 ObjectScript shell，即 的交互式命令行接口。终端应用程序包括 ，但也提供菜单和其他选项。

第二十七章 S 开头的术语

存储接口 (storage interface)

对象（Objects）

使用自定义存储或编写自己的存储类时必须实现的一组方法。

存储策略 (storage strategy)

对象（Objects）

类使用的存储策略在编译时评估为存储定义，决定数据的存储方式。

存储过程 (stored procedure)

SQL

存储过程允许你从 ODBC 或 JDBC 执行查询或类方法。

流接口 (stream interface)

对象（Objects）

流接口用于在 ObjectScript、SQL 和 中操作流。

流 (stream)

对象（Objects）

流提供了一个接口，用于操作和存储大量数据。 流接口可在 ObjectScript、SQL 和 中用于操作流。

超级服务器 (superserver)

系统

监听指定端口的服务器，用于接收对 的传入连接并将其分发到适当的子系统。默认的超级服务器端口是 ；如果 1972 不可用，超级服务器将从 开始监听下一个可用端口。要设置超级服务器端口号，请使用管理门户（系统管理 > 配置 > 系统配置 > 内存和启动）中的内存和启动页面的超级服务器端口号字段。

滑动 (swizzling)

对象（Objects）

当嵌入和持久对象被引用时，自动将其拉入内存的过程。也称为懒加载。

系统类 (system class)

对象（Objects）

第十六章 L - M 开头的术语

锁表 (lock table)

系统

IRIS 内部的表，存储所有由进程发出的 LOCK 命令。你可以使用系统查看器查看此表。

日志文件 (log files)

系统

系统管理员目录中的文件，包含关于系统操作、错误和指标的消息。这些包括消息日志（）、系统监视器日志（SystemMonitor.log）、警报日志（alerts.log）、初始化日志（）和日志历史记录日志（）。有关这些日志文件的信息，请参见“监控日志文件”。

逻辑格式 ()

对象（Objects）

对象属性的逻辑格式是在内存中使用的格式。所有的比较和计算都是基于这种格式进行的。

登录角色 (login role)

系统

通过认证到IRIS 时与用户关联的任何角色（而不是之后关联的角色）。

以 M 开头的术语

宏预处理器 (macro preprocessor)

ObjectScript

ObjectScript 编译器的一部分，将宏代码转换为可用的 代码。

宏源代码 (macro source code)

ObjectScript

编写例程和方法的最高、最灵活和最宽松的代码级别。宏源代码允许使用 语法、特殊宏预处理器命令和 标准 的组合来定义宏和嵌入式 语句。

映射 (map)

系统

在

第十三章 I 开头的术语

安装目录 (install-dir)

系统

在通用引用 IRIS 安装目录时，文档使用术语 install-dir。在示例中，文档使用 C:\MyIRIS\。章节“默认安装目录”描述了 在所有受支持操作系统上的安装位置。

实例 (instance)

对象（Objects）

表示特定实体的类的实现。术语“实例”和“对象”可以互换使用。

实例认证 (Instance Authentication)

系统

本地认证系统：用户会被提示输入密码，输入的密码的哈希值会传递到 IRIS 服务器，并与服务器中存储的现有密码的哈希值进行比较。如果两个值相同， 将授予用户对其有权限的资源的访问权限。

此机制在管理门户中列为“密码认证”。

实例方法 (instance method)

对象（Objects）

从类的特定实例调用的方法，并执行与该实例相关的某些操作。

实例化 (instantiate)

对象（Objects）

将对象实例放入内存中，以便程序可以对其进行操作。

中间源代码 (intermediate source code)

ObjectScript

IRIS 中可用的标准三代语言（） 源代码。中间代码由 编译器从宏源生成。在这个阶段，所有预处理器语法（包括嵌入式 ）都已解析，例程仅包含纯源代码。可以在这个级别编写 例程，但无法使用嵌入式

第十一章 F - H 开头的术语

文件流 (file stream)

对象（Objects）

文件流提供了一个接口，用于在外部文件中操作和存储大量基于文本或二进制的数据。IRIS 的流接口可以在 ObjectScript、SQL 和 中用于操作文件流。

最终类 (final class)

对象（Objects）

不能被扩展或子类化的类。

最终方法 (final method)

对象（Objects）

不能被重写的方法。

最终属性 (final property)

对象（Objects）

不能被重写的属性。

外键 (foreign key)

InterSystems SQL

外键约束表中的一列指向另一表中的另一列。为第一列提供的值必须存在于第二列中。

基础 (foundation)

医疗保健（Health care）

在 InterSystems IRIS for Health™ 和 中，启用了医疗保健互操作性的命名空间。

以 G 开头的术语

全局 (global)

系统

多维存储结构。全局在 数据库中使用平衡树技术实现。

全局数据库 (globals database)

系统

的基础逻辑和物理数据存储结构，其中所有数据都存储在称为“全局”的多重下标数组系统中。

全局目录 (global directory)

系统

包含全局数据库的目录。

1.Caché数据库有没有办法配置然后用sql读取数据库实时变化的数据，类似于mssql那样？我看了可以写类去读取global获取journal的值，但是怎么用sql读呢？

2.不行的话，那用什么方式可以读取到journal日志文件，并输出日志文件的内容？

先谢谢大家了！！！

InterSystems 常见问题系列FAQ

如果要让超时功能失效, 在DSN设置查询超时为disabled:

Windows Control Panel > Administrative Tools > Data Sources (ODBC) > System DSN configuration

如果勾选了Disable query timeout , 超时就会失效.

如果想在应用侧修改，你可以在ODBC API 层设置：在连接数据源之前，调用ODBC SQLSetStmtAttr功能设置SQL_ATTR_QUERY_TIMEOUT 属性 

迄今为止，我看到的大多数使用向量vector的示例，将它只作为 SQL 中的一种功能，尤其是围绕 VECTOR_Search 的 3 个函数。
* TO_VECTOR()
* vector_dot_product ()
* vector_cosine ()

在 iris-vector-search 演示包中隐藏着一个非常有用的摘要。
从那里，你可以通过多个链接找到所需的一切。

我还缺少更多的 VECTOR 方法，于是在 Idea Portal 上提出了相关请求。

接着，我想起每个 SQL 方法或存储过程都有一堆 ObjectScript 代码。
于是我开始搜索，下面就是我的研究的一些总结：

%Library.Vector 是对新数据类型的核心描述
      这是一种复杂的结构，就像对象或 %DynamicObjects 或 $Bit Expressions 一样，需要特定的方式去访问。
我们还可以看到 2 个必备参数： 
      * DATATTYPE - 一旦设置就不能更改。 可接受的类型：  "整数integer"（或 "int"）、"双精度浮点double"、"十进制decimal"、"字符串 "和 "时间戳"。
      * LEN >0 时，可以增长，但绝对不能缩小

$vector() / $ve() 是矢量访问的基本方法
      * 设置矢量数据 >>> SET $VE(. . .

低代码挑战

想象一下那个场景。您正在 Widgets Direct 愉快地工作，这是互联网上首屈一指的小部件和小部件配件零售商。您的老板有一些毁灭性的消息，一些客户可能对他们的小部件不太满意，我们需要一个帮助台应用程序来跟踪这些投诉。为了让事情变得有趣，他希望代码占用非常小，并挑战您使用 InterSystems IRIS 以少于 150 行代码交付应用程序。这可能吗？

免责声明：本文记录了一个非常基本的应用程序的构建，为了简洁起见，省略了安全性和错误处理等细节。该应用程序仅供参考，不得用于任何生产应用。本文使用IRIS 2023.1作为数据平台，并非所描述的所有功能在早期版本中都可用

第 1 步 - 定义数据模型

我们首先定义一个新的干净的命名空间 - 带有代码和数据数据库。虽然所有内容都可以位于 1 个数据库中，但将它们拆分以便于数据刷新。

我们的帮助台系统需要 3 个基本类：一个 Ticket 对象，它可以包含用于记录员工顾问 UserAccount 和客户联系人 UserAccount 之间交互的操作。让我们用一些基本属性来定义它们：

19 行代码，我们就有了完整的数据模型！我们将 2 个类设置为 Persistent，以便将它们保存到数据库中，并且还继承自 %JSON.Adapter，这使我们能够非常轻松地以 JSON 格式导入和导出对象。

最近有某国内三甲医院为满足评级和飞行检查要求，希望提升HIS和IRIS的SQL查询效率，客户和实施工程师整理了一个慢查询的SQL列表， 有一些查询比较慢， 查询时间在甚至大于60分钟。

在我们和厂商共同努力下，对整个库的SQL查询做了优化。 下表是记录了我们在进行了大部分优化工作后的结果，您可以看到大多查询从几十分钟减少到了几十秒甚至1秒以内。其中有几个慢到几分钟的查询，最后经过细调， 也把查询耗时减少到了一分钟以内。 优化的效果还是很明显的。

这里我分享一下操作的要点，以便给其他有同样问题的客户一个思路。

其实如果您看过我前面的帖子，应该已经有了基本的概念。我就把工作流程总结一下，其实就这么几个步骤：

步骤一：

检查硬件配置。 配置中和SQL性能相关的有这么几个： 1. 数据缓存大小，应该至少为物理内存的一半以上。 2. BBSIZE, 也就是单个进程最大的内存占用，对应不同的Caché/IRIS版本和不同的应用，这个配置有区别，但当然是越大越好，询问您的实施工程师配置是否正确。 3. 是否使用了大页内存，这个能从messages.log里看到。

步骤二

执行Tunetable。 在上面说的这个客户的系统上从来没人执行过Tunetable, 因此SQL引擎其实是没法正确工作的。执行后基本可以解决80%的慢SQL问题。时间短风险小见效快， 找个半夜业务小的时候直接在生产环境执行。

SQL查询优化器一般情况下能给出最好的查询计划，但不是所有情况都这样，所以InterSystems SQL还提供了一个方式， 也就是在查询语句里加入optimize-option keyword（优化关键字）, 用来人工的修改查询计划。

比如下面的查询：

SELECT AVG(SaleAmt) FROM %PARALLEL User.AllSales GROUP BY Region

其中的%PARALLEL, 就是最常用的优化关键字， 它强制SQL优化器使用多进程并行处理这个SQL。

您可以这样理解： 如果查询优化器足够聪明，那么绝大多数情况下，根本就不需要优化关键字来人工干预。因此，您也一定不奇怪在不同的IRIS/Caché版本中， 关键字的表现可能不一样。越新的版本，应该是越少用到。比如上面的%PARALLEL， 在Caché的大多数版本中， 在查询中加上它一般都能提高查询速度，而在IRIS中，尤其是2023版本以后， 同样的SQL查询语句，很大的可能查询优化器已经自动使用多进程并行查询了，不再需要用户人工干预了。

因此，先总结有关优化关键字的要点：

1. 优化关键字主要是FROM语句中使用。 UPDATE, INSERT语句也有可以使用的关键字，比如%NOJOURAL等等， 这里我不介绍了，请各位自己查询文档。

我在使用PHP 链接 Cache时  超长字段有一半乱码，其他字段正常，这是为什么

我使用Call 来访问的视图   unixODBC 链接  windows ODBC链接  均出现乱码 请求帮助

SQL性能监控是DBA最重要的日常工作。经常被问起："Caché/IRIS怎么发现慢SQL"? 答案很简单： 到管理门户的SQL页面，点开如下的“SQL语句“子页， 您能看到这个命名空间的所有执行过的SQL语句，知道每个SQL语句执行了多少次，平均执行时间是多少， 被那个客户端编译的，第一次执行是那一天等等。

请看下面的截图

图中的各个栏目基本都不需要解释，有个别的内容在这里总结一些：

• 表/视图/存储过程名称：列出这个查询使用的所有的表/视图/存储过程的名字。如果你想看某个表有关的查询，可以使用上面的过滤器。

• 位置(Location) : 对于动态查询， 列出所使用的缓存的查询的类名，对于嵌入SQL(Embedded SQL)查询，列出使用的routine名字。

• 每个字段的标题栏可以用于排序，比如上图是按执行次数倒序显示的，所以前几位都是执行了很多的INSERT。 如果是日常维护查找慢SQL, 您可以按平均时间倒序显示。

• 计划状态： 通常是"Unfrozn"或者“Unfrozen/Parallel"。除非您需要升级或者有“Frozen Qeury Plan“的需要，您可以不关心这个栏目。

• 用鼠标单击上图的最左列或者最右列“SQL声明文本”， 会显示这个SQL语句的详细执行数据。 注意这个页面上的两个按钮： “导出” 和**”查询测试“**， 您可以试试它们。

索引分析器工具用来分析索引的使用情况，对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"指的是厂家的技术支持人员。

因此，总结如下：

• **如果您是个生产环境的维护人员，除非有厂商的支持要求您执行，否则最好不要在生产系统使用这个工具。除非您有兴趣，想知道这个Toolkit是干什么的, 以便在有厂商人员需要您使用这个工具采集数据的时候，知道工作的大概, 否则不用往下看了。 **

为什么要读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.

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

我们先看看读Query Plan的几个基本知识：

MAP

An SQL table is stored as a set of maps. 您有看到3种map: Master map, index map, bitmap.

# 回表读主数据，
- Read master map DWBC.CT_Dept.IDKEY, using the given idkey value.

# 读普通索引
Read index map DWBC.CT_MDRDictionary(T1).UniCodeIdx, using the given %SQLUPPER(UniCode), and getting T1.ID.

# 读bitmap索引
Read bitmap index My.ppl1.idxWLRecDep, looping on %SQLUPPER(WLRecDep) (with a given set of values) and bitmap chunks.

2024年3月26日，InterSystems数据平台全球主管Scott Gnau发文，宣布InterSystems IRIS数据平台新增了向量搜索（vector search）功能。

本文作者为Scott Gnau，InterSystems数据平台全球主管。

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

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

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

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

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

CREATE TABLE Sample.MyNames (
    LastName CHAR(30),
    FirstName CHAR(30) COLLATE SQLstring)

IRIS/Caché的Collation

事情在IRIS/Caché里变的有点复杂。

1. 对于一个字段，可以分别在字段上和索引上定义Collation。

Bitmap索引是指对某个，或者某几个字段建立的bit map(位图映射)。如果是对整个表的记录，也就是表的%ID做位图映射，得到的特殊的bitmap索引在IRIS/Caché里被称为Bitmap Extent。

建立Bitmap Extent索引的目的就是加快COUNT(*)的执行。提高了多少呢？ 下面两个显示的是最简单的全表查询花费的时间：

• 不使用Bitmap Extent : 1.3810s
• 使用Bitmap Extent： 0.0038

相差有几百倍。

有关Bitmap Extent你需要了解：

• IRIS中不需要人工创建。当在表中创建了任何一个Bitmap索引， 系统会为这个表自动添加一个Bitmap Extent, 名字是“$类名”， 比如上图中的$ppl1。
• Caché中需要你自己手工添加bitmap Extent， 可以使用SQL或者在类里定义
  • 在类里定义：

Index DDLBEIndex [ Extent, SqlName = "%%DDLBEIndex", Type = bitmap ];

• SQL定义

CREATE BITMAPEXTENT INDEX Patient ON TABLE Sample.Patient

• 做为Bitmap的一个特例， 它也有下列限制
  • 需要IDKEY为正整数
  • 大量的数据删除插入需要定期维护

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

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

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

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

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

1. 单列索引（列X）
2. 复合索引（列X, 列Y）
3. 复合索引（列X，列Y，列Z）

而Caché/IRIS是不承认最左匹配原则的，Caché/IRIS的原则非常简单粗暴: 既然定义了索引在这些字段上，查询中必须同时有所有这些字段。 也就是说，这个复合索引

单按列名X，或者“列名X and 列名Y”做SQL查询都用不到这个索引。

正确的使用Bitmap Index (位图索引)来代替普通索引，可以成百上千倍的提高SQL查询性能。

先来看看Bitmap索引和普通索引的区别。我来在Patient表的Sex字段上创建两个索引

• idxSex: 普通索引
• bidxSex: bitmap索引

然后创建10个病人数据，查看索引的内容：

# 普通索引
^User.PatientI("idxSex"," F",1)	=	""
^User.PatientI("idxSex"," F",6)	=	""
^User.PatientI("idxSex"," F",8)	=	""
^User.PatientI("idxSex"," M",2)	=	""
^User.PatientI("idxSex"," M",3)	=	""
^User.PatientI("idxSex"," M",4)	=	""
^User.PatientI("idxSex"," M",5)	=	""
^User.PatientI("idxSex"," M",7)	=	""
^User.PatientI("idxSex"," M",9)	=	""
^User.PatientI("idxSex"," M",10)	=	""

# bitmap索引
^User.PatientI("bidxSex"," F",1)	=	$zwc(407,2,1,6,8)/*$bit(2,7,9)*/
^User.PatientI("bidxSex"," M",1)	=	$zwc(413,2,0,1,6,8)/*$bit(3..6,8,10,11)*/

Caché/IRIS的特点是运行Global的修改，而这个修改和SQL是无关的，因此非常容易出现数据库表数据完整性的问题，也就是表中的数据是不是符合定义的表约束。 

这样的情况非常常见。有些是人为的对Global的错误修改， 有些是应用系统的事务性管理写的不对，造成事务回滚的时候破坏了索引的完整性。无论什么原因，只要使用Global操作，破坏SQL的完整性非常难以避免。结果就是SQL查询给出错误结果。

最简单的解决方法就是执行“索引检查(Validate Indices)"

我们来做个实验

- 先修改一个global： 如下图， 将Patient表的一个记录的SEX字段，从'M'改到‘F'. 

运行索引检查, 结果会提示您问题在什么地方。 

SAMPLES>do ##class(Patient).%ValidateIndices()
​
​
Checking index integrity for class 'User.Patient'
Begin time:  03/19/2024 15:25:43
​
Verifying data from data map 'IDKEY' is indexed correctly...
Bitmap index 'bidxSex', entry $bit(^User.PatientI("bidxSex"," F",1),4)=0, row is missing from index, it should be 1.
Index 'idxSex', entry ^User.PatientI("idxSex"," F",3) missing.
Data Map evaluation complete, 1000000 rows checked, 2 errors found, elapsed time: 27.344792 seconds
​
Verifying data from index map "$Patient" is correct...
Index map "$Patient" evaluation complete, 0 errors, elapsed time: 12.026982 seconds
​
Verifying data from index map idxSex is correct...
Index 'idxSex', entry ^User.PatientI("idxSex"," M",3), data differs for field 'Sex' between data and index map.
Index map idxSex evaluation complete, 1 errors, elapsed time: 12.285592 seconds
​
Verifying data from index map bidxSex is correct...
Bitmap index 'bidxSex', entry  $bit(^User.PatientI("bidxSex"," M",1),4), for row with ID '3', bit is ON, but indexed field value(s) differ from data map value(s).
Index map bidxSex evaluation complete, 1 errors, elapsed time: 13.591468 seconds
​
Verifying data from index map idxPatientNumber is correct...
Index map idxPatientNumber evaluation complete, 0 errors, elapsed time: 13.646994 seconds
​
%ValidateIndices is complete, total elapsed time: 41.048687 seconds
​
SAMPLES>
​

上个帖子写了TuneTable的执行, 提到了SQL优化器使用的那些统计数据， 这里逐一的介绍一下这些统计项。了解它们看懂和分析SQL执行计划的基础。 如果您不需要做单个查询的优化工作，可以调过这部分内容。 

表的统计项

• Extent Size: 表的大小，也就是记录数。在执行多表关联(JOIN)的查询时，SQL优化器会根据Extent Size值，从数据量最小的表来开始执行查询。

您还需要了解：表创建的时候Extent Size会获得一个初始值，而之后的插入修改数据并不自动修改这个值。而只有执行TuneTable才会修改这个。 这也就是为什么没有执行过TuneTable的数据库SQL性能好不了的原因。下图中的Patient表，可以看出有1,000,000记录

字段的统计项

请看下面的图

• 选择性(Selectivity)

选择性取值可以是1或者一个百分数。取值为1说明这是个unique的字段，比如上图的ID, PatientNumber。 %表示的值，取值越高说明唯一性越低。比如上图中的Name的选择性是1.2987%，说明不是唯一值，有重复的姓名，但比例不高。 相反，Sex的选择性是50%, 说明只有两个取值。 

• 离散值选择性Outlier Selectivity),

始用于Caché2014.

IRIS/Caché查询慢，主要原因有以下几个：

• 应用是一个事务型的数据库， 数据模型的设计不适合某些复杂的分析查询

        这是慢的原因，不是慢的离谱的原因。数据模型是产品设计的范畴， 这里不讨论， 本文只讨论优化。

• 历史原因，有些表的索引不够优化

        虽然还是设计问题，但可以在实施中或者维护中给出优化方案。

• 产品运行中的问题造成的查询效率下降

IRIS/Caché数据平台的一个特点是允许跳过SQL约束，对底层数据的直接修改。坏的代码或者应用可能破坏表数据和表索引的约束，造成SQL性能的下降。维护人员应该知道怎么避免，和处理这样的问题。 

• 维护工作缺乏造成

 比如Tune Table(调整表), 这是必须做的工作，但可惜很有些项目没有执行过。

还有些其他暂时没想到的原因。我会在以下链接的帖子里和各位分享我的参与的一些知识和经验。这些经验是从一些SQL优化的工作中学到的，包括Caché 2010, 2016, IRIS, HealthConnect/Ensemble的项目。比如在最近的一个IRIS项目中， 我和另一个合作伙伴的工程师将IRIS 2021上的HIS数据库的100个SQL查询的平均查询时间从几十秒降低到几秒， 最慢的查询从50分钟降低到10几秒钟。

TuneTable(调整表)收集数据库中表的统计信息，用来为SQL引擎制定最优的执行计划。在其他数据库产品里，这个动作被称为“gather stats job"或者类似的名字，相比较TuneTable不是那么直白，但作用是一样的。
 

TuneTable是否要人工执行

一定要。

在IRIS 2023版本， 第一次加入了TuneTable的自动执行功能，在此之前的所有IRIS/Caché版本， 如果没有人工执行TuneTable, SQL引擎无法保证给出最好的查询计划。 即使是IRIS2023有了自动执行功能，也还需要人工执行TuneTable的操作，后面解释。

怎么知道有没有执行过TuneTable 

到“管理门户>SQL"页面， 打开一个表， 看“目录详情”，如下图， 如果其中的“选择性”，"离群值选择性“， ”离群值“，“平均字段大小”这些字段有数据， 说明这个表至少做过了一次TuneTable. 

除了“字段”按钮页，在“表信息”还有统计项 “ExtentSize"， “索引”页，包含每个索引的统计信息项。

关于这些统计项的想象解释， 我会在下个帖子里介绍。 

什么时候执行TuneTable

简单的说：对于查询所用的表，SQL引擎要有以上有统计信息，而且足够准确。

解释以下“足够准确”。

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

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

 zpm "install samples-bi"

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

 ClassMethodTODO:

糟糕的解决方案#1：SQL 注入

最自然的糟糕方法是将用户输入直接连接到查询文本中。这可能会导致SQL 注入漏洞。 SQL 注入的经典示例实际上在动态 SQL 设置中不起作用，因为 %SQL.Statement 不接受多个分号分隔的语句。但即使在 SELECT 语句的上下文中，仍然存在 SQL 注入漏洞带来的安全风险。 UNION ALL 可用于公开完全不相关的数据，并且存储过程可能能够修改数据或影响系统可用性。

这是一个糟糕的解决方案，它容易受到 SQL 注入的攻击（并且还会出现其他一些错误，我们将在稍后讨论）：

 %Integer

这里有什么问题？

什么是非结构化数据？
非结构化数据是指缺乏预定义数据模型或组织的信息。与数据库中具有清晰结构（例如表和字段）的结构化数据相比，非结构化数据缺乏固定的模式。此类数据包括文本、图像、视频、音频文件、社交媒体帖子、电子邮件等。

为什么来自非结构化数据的见解很重要？
根据 IDC（国际数据公司）的报告，预计到 2025 年，全球 80% 的数据将是非结构化的，这将成为 95% 企业的重大担忧。 福布斯文章

人工智能世界如何解决这个问题？
在人工智能领域，生成式人工智能在为非结构化数据提供解决方案方面发挥着至关重要的作用。它擅长从文本/图像/视频中提取有价值的信息、文本摘要和处理文档等任务。

Intersystems 非结构化数据解决方案
Intersystems IRIS 提供了一种称为“SQL 文本搜索”的特殊解决方案，用于搜索非结构化数据。此功能有助于对多种语言的非结构化文本数据进行语义上下文搜索。

使用 SQL 文本搜索有什么优点？

快速搜索： InterSystems IRIS SQL 搜索利用优化的索引生成快速导航大量数据，避免对数据本身进行顺序搜索。

单词感知搜索：与基本字符串搜索不同，SQL 搜索依赖于文本中的语义结构，以单词为基本单位。这种方法最大限度地减少了嵌入字符串或跨越两个单词的字符串引起的误报。

实体感知搜索： SQL 搜索考虑语义关系以将多个单词分组为实体。

本篇文章会介绍一个简单的示例：如何使用IRIS 2023版自带的EnsLib.SQL.Service.GenericService 和EnsLib.SQL.Operation.GenericOperation将MySQL的数据库读取出来并灌入Oracle数据库，本示例以Windows环境为例。

1. 创建SQL网关连接，连到MySQL

1.1 在windows中创建MySQL ODBC连接

1.2 在IRIS中创建ODBC SQL网关连接，连接到MySQL

系统管理 -> 配置 -> 连接 -> SQL网关连接，连接类型选择‘ODBC’，给一个连接名称，现有的DSN选择在1.1中所有建立的DSN名称，填写连接用户名和密码，然后点击下方‘连接测试’，如果出现‘连接成功’，说明此连接能够正常工作

2. 创建SQL网关连接，连到Oracle

2.1 在IRIS中创建JDBC网关连接，连接到Oracle

系统管理 -> 配置 -> 连接 -> SQL网关连接，连接类型选择‘JDBC’，给一个连接名称，填写连接用户名和密码，填写驱动器名称和要连接的Oracle数据库的URL和本地OJDBC.jar的java类路径，然后点击下方‘连接测试’，如果出现‘连接成功’，说明此连接能够正常工作

3. 创建Production组件

3.1 业务服务

添加EnsLib.SQL.Service.

近日，InterSystems宣布 InterSystems IRIS® Cloud SQL 和 InterSystems IRIS® Cloud IntegratedML® 服务全面上市。 这些全面托管的云原生智能数据服务使开发人员能够轻松地在SQL环境中构建云原生数据库和机器学习（ML）应用程序。

通过 Cloud SQL和 Cloud IntegratedML，开发人员可以访问下一代关系数据库即服务（DBaaS），DBaaS快速且易于配置和使用。 嵌入式AutoML功能支持开发人员在全面托管的、弹性的云原生环境中，仅仅通过几条类似SQL的命令即可轻松开发并执行机器学习模型。

SqlDbx是我们常用的数据库查询与操作工具，因其轻量且无须安装而无处不在，然而习惯了在Intersystems的CACHE和ENSEMBLE版本下使用SqlDbx在升级到IRIS版本后却无法使用了，为此进行了一系列尝试，并最终获得成功，形成本文攻略，分享给大家。

1、在SqlDbx的连接登录窗口，从DBMS Type中直接选择 “InterSystems CACHE”连接IRIS会报错，提示“通过IRISconnect失败”，说明“InterSystems CACHE”不再适用于IRIS。

2、考虑IRIS的ODBC支持，为此换一种思路，采用ODBC方式连接，此方式需要在ODBC中建立DSN。

3、从Intersystems官网https://intersystems-community.github.io/iris-driver-distribution/或github网站https://github.com/intersystems-community/iris-driver-distribution/tree/...下载InterSystems IRIS ODBC 32位驱动，注意一定要下载32位驱动（注：SqlDbx现只支持32位的ODBC）。