これは InterSystems FAQ サイトの記事です

揮発性テーブル（多数のINSERT、DELETEが行われるテーブル）では、ビットマップ・インデックス用ストレージは徐々に効率が低下する可能性があります。

例えば、以下の定義からなるデータが数千件あり、一定期間保持した後 TRUNCATE TABLE で一括削除を行うオペレーションが繰り返し行われているとします。

Class MyWork.MonthData Extends (%Persistent, %Populate)
{
/// 満足度
Property Satisfaction As %String(VALUELIST = ",満足,やや満足,やや不満,不満,");
/// 年齢
Property Age As %Integer(MAXVAL = 70, MINVAL = 20);
Index AgeIdx On Age [ Type = bitmap ];
}

これはInterSystems FAQ サイトの記事です。

SQLインジェクションに関しては、様々なWebサイトで対策等が公開されていますが、InterSystems SQLを使ったアプリケーションでも、他のRDBMSと同様にそれらの対策を適切に実施することで、SQLインジェクションは防げると考えられます。

さらに、InterSystems Data Platform(以下IRIS)の場合、一般的なRDBMSに比較して、SQLインジェクションを実行しづらい、幾つかの施策が組み込まれています。

優れた執筆者は、題名で読者を引き込み、答えを記事のどこかに隠すべきだと考えられています。 だとすると、私は出来の悪い執筆者ということになってしまいます。私の自尊心は見知らぬインターネットユーザーの皆さんのご意見にかかっていますので、お手柔らかにお願いします。

これは、InterSystems FAQサイトの記事です。

SELECT ... FOR UPDATE は明示的な行ロック取得の方法として多くの RDBMS で実装されているため、この機能を使われているケースも多いと思います。

このシンタックスは InterSystems 製品ではエラーにはなりませんが、期待されるような行ロックの取得は行われません。

この記事では同等の機能を実現する方法をご紹介します。

DECLARE CURSOR C1 IS
SELECT Name FROM Person WHERE Name LIKE 'A%' FOR UPDATE
OPEN C1
LOOP FETCH C1 INTO name　
... name を表示
... 終了ならLOOPをEXIT
END LOOP
CLOSE C1

上記のようなSQL文は、下記のSQL文で代替可能です。

※下記2行目のUPDATE文の実行により対象行に対して排他ロックがかかるため、他DBの動作と異なる点ご注意ください。

これはInterSystems FAQ サイトの記事です。

インデックスが複数定義されているクラス／テーブルへ csv 形式等のシーケンシャルファイルから大量データをデータベースに登録する際、推奨される登録方法として、データ登録時インデックスを生成させず、登録完了後に一括でインデックスを生成する 方法があります。

この方法は、新規に大量のレコードを一括登録する際に最も有効な手段となります。

＜メモ＞
大量のデータを追加登録する際には、既存のデータ量と新規データ量のバランスにより、この手法が有効でないケースもあります。その場合は、インデックスの再構築を範囲指定で行うこともできます。

説明に使用するクラス定義例は以下の通りです。

これはInterSystems FAQ サイトの記事です。

テーブルチューニングを行った際に、フィールドに値がほとんど登録されていない（Null）場合や、特定の値がほとんどを占める場合、その値を [外れ値] として除外して選択性計算を行います。 また、外れ値が全レコードの何 % を占めているかの値は [外れ値の選択性] として記録されます。

InterSystems 製品のクエリオプティマイザは、選択性数値とエクステントサイズを使用してクエリの経路を決定しますが、クラスクエリ、埋め込み SQL に使用しているクエリに外れ値が含まれる場合は、外れ値の選択性が自動的に考慮され、インデックスの使用有無を決定しています。

SQL パフォーマンスリソース

SQL のパフォーマンスについて語るとき、最も重要なトピックとして取り上げられるのが「Indices」、「TuneTable」、「Show Plan」の 3 つです。 添付の PDF にはこれらのトピックに関する過去のプレゼン資料が含まれていますので、それぞれの基礎を一度に確認していただけます。 当社のドキュメンテーションでは、これらのトピックの詳細に加え、SQL パフォーマンスの他のトピックについてもカバーしておりますので、下のリンクからお読みください。 eラーニングをご利用いただくと、これらのトピックをもっと深く理解していただけます。 また、開発者コミュニティによる記事の中にも SQL パフォーマンスについて書かれたものが複数ありますので、関連するリンクを下に記載しております。

下に記載する情報には同じ内容が多く含まれています。 SQL パフォーマンスにおける最も重要な要素を以下に紹介します。

InterSystems IRIS のクラスクエリ

InterSystems IRIS（および Cache、Ensemble、HealthShare）のクラスクエリは、SQL クエリを Object Script のコードから分離する便利なツールです。 このクエリの基本的な機能は、同じ SQL クエリを複数の場所で異なる引数で使用する場合にクエリの本文をクラスクエリとして宣言し、このクエリを名前で呼び出すことでコードの重複を回避できるというものです。 このアプローチは、次のレコードを取得するタスクを開発者が定義するカスタムクエリにも便利です。 興味が湧きましたか？ それではこのまま読み進めてください！

Caché 2017以降のSQLエンジンには新しい統計一式が含まれています。 これらの統計は、クエリの実行回数とその実行所要時間を記録します。

これは、多くのSQLステートメントを含むアプリケーションのパフォーマンスを監視する人や最適化を試みる人にとっては宝物のような機能ですが、一部の人々が望むほどデータにアクセスするのは簡単ではありません。

日付範囲クエリが極端に遅くなっていませんか？ SQLのパフォーマンスが低下していませんか？

日付範囲のサブクエリをまだご覧になっていない場合は、前回の投稿をご確認ください。
https://jp.community.intersystems.com/post/日付範囲クエリのsqlパフォーマンスを改善する

なぜ、こうも日付クエリに注目しているのでしょうか？ それは、日付クエリが重要だからです。 それは報告であり、統計であり、自分の素晴らしい仕事を上司に証明するための数字です（もちろん、あなたが実際にそうしていればの話ですが )。では、前回と同じようなテーブルを見てみましょう。ただし、実際には MAXLEN と MINLEN を次のように適切に定義します。

本稿について

本稿では、InterSystems IRISを使用してSQLベースのベンチマークを行う際に、実施していただきたい項目をご紹介します。
Linuxを念頭においていますが、Windowsでも考慮すべき点は同じです。

メモリ自動設定をやめる

パフォーマンスに直結する、データベースバッファサイズの自動設定はデフォルトで有効になっています。自動設定は、実メモリの搭載量にかかわらず、データベースバッファを最大で1GBしか確保しません。

更新: 2020年11月20日 バージョン2020.3から、確保を試みるデータベースバッファが実メモリの25%に変更されました。

搭載実メモリ64GB未満の場合は実メモリの50%程度、搭載実メモリ64GB以上の場合は実メモリの70%を目途に、明示的に設定を行ってください。