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

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

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

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

步骤一：

百讲知识点索引

简介

• B站已更新截止到2023.12.31之前的所有百讲课程，总计261讲。
• 什么是百讲？百讲是一个主要介绍IRIS、Cache编程知识的免费课程。
• 课程的特点是，将每一个知识点，都会用示例演示出来、了解原理，而不是仅仅告诉有这个功能。
• 每周一期，每期会请到有多年开发经验的老师来给大家讲解课程。
• 百讲观看地址：https://www.bilibili.com/video/BV1cw41147xr/

在此文章中将分享，当使用InterSystems IRIS 做后端时如何接收并保存通过POST方式发送过来的 Base64文件。

前后端之间传输文件，我认为较简单的方式是：前端将文件转为Base64格式，调用POST方法并将Base64内容附加在JSON消息中的一个参数中，在JSON消息中的另一个参数可以是文件名，比如消息定义如下：

数据收集

这篇分步说明指南将讲解如何创建任务来收集 InterSystems 数据库及其全局变量的相关数据（如关联的 Open Exchange App 所示，其中包含所有相关代码）

免责声明：此软件仅用于测试/演示目的。 InterSystems 不支持将此代码作为任何发布产品的一部分。 它由 InterSystems 提供，作为特定产品和版本的演示/测试工具。 用户或客户全权负责此软件交付后的维护和测试，InterSystems 对此代码的错误或误用不承担任何责任。

1) 首先，通过管理门户导入文件“DataCollection.xml”，并确保没有错误。 如果存在错误，则可能是版本问题，请发送电子邮件至 ari.glikman@intersystems.com 联系 Ari Glikman 获取适合你的版本的支持。 另外，确保将数据导入到你想要收集其内部数据以供后续检查的命名空间中。

各位社区成员，大家好，

利用面向您的组织中的各个角色提供的全套 InterSystems 学习资源（在线或面授形式），您可以全面挖掘 InterSystems IRIS 的潜力，并帮助您的团队完成入门流程。 开发者、系统管理员、数据分析师和集成商可以快速上手。

学习服务提供的资源

在深入学习角色特定的资源之前，我们先来总体了解一下现有的学习资源：

FHIR是标准，是规范，使用FHIR使大家可以使用同一种语言、语义进行交流，名称、API都是统一的，只要符合FHIR标准，任何系统都可交互。对业务开发者来说，大部分接口交互的定义交给FHIR来处理，效率大大提高。

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

TuneTable是否要人工执行

一定要。

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

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

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

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

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

表的统计项

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

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

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

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

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

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

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

通过 REST API 将前端 React 应用程序与 IRIS 数据库等后端服务集成，是构建健壮网络应用程序的强大方法。但是，开发人员经常遇到的一个障碍是跨源资源共享（CORS）问题，由于网络浏览器强制执行的安全限制，该问题可能会阻止前端访问后端的资源。在本文中，我们将探讨在将 React Web 应用程序与 IRIS 后端服务集成时如何解决 CORS 问题。

创建Schema

我们首先定义一个名为 Patients 的简单Schema：

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

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

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

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

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

列式存储是 InterSystems IRIS 提供的一项较新的技术。与传统的基于行的存储不同，它通过将数据存储在列而不是行中来优化查询处理，从而实现更快的访问和检索相关信息。

下面是使用SQL创建此类表的例子

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

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