DBAハンドブック

数値型、文字列型、日付と時刻型、JSON型、空間型の範囲、バイト数、主な用途。MySQLとMariaDBの重要な違いも扱います。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+

データ型の選び方は、ディスク上のサイズ、インデックスの速さ、データの整合性を左右します。このガイドでは、MySQLとMariaDBでよく使われる型を、その範囲、バイト数、主な用途とともにまとめます。

整数型

- TINYINT：1バイト。符号付きの範囲は−128〜127（符号なしは0〜255）。真偽値のフラグや小さな状態に便利です。
- SMALLINT：2バイト。−32,768〜32,767。年齢や小さな数量に。
- MEDIUMINT：3バイト。−8,388,608〜8,388,607。MySQLとMariaDBに固有の型で、それ以外ではほとんど使われません。
- INT（INTEGER）：4バイト。±2.1·10⁹。中規模のテーブルの主キーに使う標準の型です。
- BIGINT：8バイト。±9.2·10¹⁸。大きなテーブルの主キーや分散環境の識別子に。

CREATE TABLE orders (
    id        BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    quantity  SMALLINT UNSIGNED NOT NULL,
    status    TINYINT UNSIGNED NOT NULL DEFAULT 0
);

小数と浮動小数点数

- DECIMAL(M, D)：正確な精度。全体でM桁、小数部がD桁。金額には必須です。
- FLOAT：4バイト。有効数字はおよそ7桁。近似値です。
- DOUBLE：8バイト。およそ15桁。近似値です。

CREATE TABLE prices (
    sku    VARCHAR(32) PRIMARY KEY,
    amount DECIMAL(12, 2) NOT NULL,
    tax    DECIMAL(4, 2)  NOT NULL DEFAULT 13.00
);

文字列

- CHAR(N)：N文字の固定長で、最大255。すべての行が同じ長さになる場合（国コード、ハッシュ値）に高速です。
- VARCHAR(N)：可変長で、1行あたり最大65,535バイト（ほかの列と共有）。長さを記録するために1〜2バイトを余分に使います。
- TEXT、MEDIUMTEXT、LONGTEXT：64 KiB、16 MiB、4 GiB。行の外に格納され、プレフィックスを付けなければキーとして使えません（KEY (col(255))）。
- BLOB、MEDIUMBLOB、LONGBLOB：それぞれのバイナリ版です。

日付と時刻

- DATE：3バイト。'1000-01-01'…'9999-12-31'。
- TIME：3バイト。'-838:59:59'…'838:59:59'。そう、24時間を超えられます（時刻ではなく時間の長さを表すため）。
- DATETIME：5バイトに、秒の小数部のために最大3バイトが加わります。タイムゾーンを持たず、保存や読み取りのときに変換もしません。保存した値がそのまま返ります。
- TIMESTAMP：4バイト。範囲は1970〜2038（MySQL。8.xを含む）または1970〜2106（MariaDB 11.5以降）。UTCで格納され、接続のtime_zoneに変換されます。
- YEAR：1バイト。1901〜2155。

CREATE TABLE events (
    id           BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    occurred_at  DATETIME(6) NOT NULL,
    created_at   TIMESTAMP   NOT NULL DEFAULT CURRENT_TIMESTAMP
);

JSON

MySQL 5.7以降とMariaDB 10.2以降のネイティブ型です。JSON_EXTRACTや->>で取り出したフィールドにインデックスを付けられ、MySQL 8.0以降はインデックス付きの生成列（配列に対するMULTI-VALUED INDEX）も使えます。

CREATE TABLE profiles (
    id          BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    attributes  JSON NOT NULL,
    email       VARCHAR(120) AS (JSON_UNQUOTE(JSON_EXTRACT(attributes, '$.email'))) STORED,
    INDEX idx_email (email)
);

空間型（GIS）

- POINT、LINESTRING、POLYGON、GEOMETRY、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、GEOMETRYCOLLECTION。
- 効率よく検索するにはSPATIALインデックスが必要です（MBRContains、ST_Distance、ST_Within）。
- MySQL 8.0では、空間インデックスを使うにはSRIDの指定が必須です。

CREATE TABLE locations (
    id    BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    name  VARCHAR(120),
    point POINT NOT NULL SRID 4326,
    SPATIAL INDEX (point)
) ENGINE = InnoDB;

ENUMとSET

- ENUM：あらかじめ決めたN個の値（最大65,535）のうち1つを格納します。コンパクト（1〜2バイト）ですが融通が利きません。一覧を変えるにはALTER TABLEが必要です。
- SET：最大64個の値の組み合わせをビットマップで格納します。固定の権限やラベルに便利です。

値の一覧が頻繁に変わるなら避けてください。参照用のテーブルと外部キーのほうが保守しやすくなります。

選び方

1. 想定する範囲を収められる最も小さい型を使います。INTで足りるところにBIGINTを使うと、インデックスの領域が4倍になります。
2. 負の値が要らない列にはUNSIGNEDを付けます。範囲が2倍になります。
3. できるだけNULLを避けます。NOT NULL DEFAULT …の列は、行ごと、インデックスごとに1ビットを節約できます。
4. 実際のデータが20文字に収まるなら、VARCHAR(255)はVARCHAR(20)より高くつきません。宣言した長さが効いてくるのはプレフィックスインデックスだけです。

キーワード： データ型、INT、BIGINT、VARCHAR、TEXT、JSON、DATETIME、TIMESTAMP、DECIMAL、ENUM、SET、POINT、SPATIAL、BLOB、範囲、バイト

インデックスの種類（Bツリー、HASH、FULLTEXT、空間インデックス）、単一列と複合インデックスの違い、書き込みを犠牲にせずに読み取りを速くする戦略。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+

インデックスは、ディスク容量と、INSERT/UPDATE/DELETEのたびにかかる負荷と引き換えに、検索を速くします。インデックス設計の良し悪しが、ミリ秒で終わるクエリーと1分かかるクエリーの差になります。

インデックスの種類

- Bツリー：InnoDBのデフォルト。等価検索、範囲（>、<、BETWEEN）、プレフィックス（LIKE 'abc%'）、並べ替え（ORDER BY）に使えます。
- ハッシュ：等価検索のみ。MEMORYエンジンで使えます。InnoDBは内部にアダプティブハッシュインデックスを持っていますが、直接は制御できません。
- FULLTEXT：自然言語検索とブール検索。InnoDBとMyISAMで使えます。長いTEXT列に便利です。
- SPATIAL：POINTやPOLYGONなどのためのRツリー。NOT NULLの列が必要です。
- マルチバリュー：JSON配列の要素にインデックスを付けます。MySQL 8.0.17以降のみ。

-- 複合Bツリーインデックス
CREATE INDEX idx_orders_customer_date
    ON orders (customer_id, order_date DESC);

-- 全文インデックス
ALTER TABLE articles
    ADD FULLTEXT INDEX ft_title_body (title, body);

-- 空間インデックス
ALTER TABLE locations
    ADD SPATIAL INDEX sp_point (point);

単一列と複合

(A, B, C)の複合インデックスは、先頭から使う検索をカバーします：WHERE A = ?、WHERE A = ? AND B = ?、WHERE A = ? AND B = ? AND C = ?。ただし、WHERE B = ?だけの検索には使えません。

目安として、複合インデックスの列は選択性（それぞれの列の一意な値の多さ）と、絞り込みに使われる頻度の順に並べます。

-- 良い例：最も選択性の高い列を先頭に
CREATE INDEX idx_invoices
    ON invoices (customer_id, status, date)
    -- customer_id（選択性が高い）→ status → date
;

-- アンチパターン：冗長なインデックス
-- (customer_id)は(customer_id, status, date)ですでにカバーされている
DROP INDEX idx_invoices_customer ON invoices;

カバリングインデックス

クエリーが読むすべての列を含むインデックスは、テーブルを読みに行かずに済みます。EXPLAINを実行し、Extra列にUsing indexがあるかを確認します。

-- クエリーが読むのはcustomer_idとtotalだけ → インデックスがカバーする
CREATE INDEX idx_orders_cover
    ON orders (customer_id, total);

SELECT customer_id, SUM(total)
FROM orders
WHERE customer_id IN (1, 2, 3)
GROUP BY customer_id;

プレフィックスインデックス

長いTEXT列やVARCHAR列では、先頭のN文字だけにインデックスを付けます。妥当な選択性を保ちながら、インデックスのサイズを小さくできます。

CREATE INDEX idx_url
    ON pages (url(64));   -- 先頭の64文字

不可視インデックス

ALTER TABLE orders ALTER INDEX idx_legacy INVISIBLE;
-- 数時間パフォーマンスを監視する
ALTER TABLE orders ALTER INDEX idx_legacy VISIBLE; -- 元に戻す
-- または
DROP INDEX idx_legacy ON orders; -- 削除を確定する

ALTER TABLE orders ALTER INDEX idx_legacy IGNORED;
ALTER TABLE orders ALTER INDEX idx_legacy NOT IGNORED; -- 元に戻す

読み取りと書き込みへの影響

インデックスを1つ増やすたびに：
- それを使うクエリーは速くなります。
- インデックス付きの列に触れるすべてのINSERTとUPDATE、そしてすべてのDELETEが遅くなります。
- 追加の容量を使います（多くの場合、テーブルのサイズの10〜40%）。

書き込みの多いテーブル（ログ、メトリクス）では、欠かせないインデックスだけを最小限に保ちます。

最適化の戦略

1. まずEXPLAIN：type: ALL（フルスキャン）とkey: NULL（インデックスを使っていない）を探します。
2. 最適化の前に測定する：スロークエリーログで、最もコストの高いクエリーを見つけます。
3. 選択性と順序を組み合わせる：複合インデックスは、WHERE句とORDER BY句の順序に合わせます。
4. 冗長なインデックスを避ける：(A)、(A, B)、(A, B, C)は冗長です。(A, B, C)だけで足ります。
5. カーディナリティの低い列にインデックスを付けない：genderやactive（一意な値が1つか2つ）のインデックスはほとんど役に立ちません。

-- 診断
EXPLAIN SELECT * FROM orders
WHERE customer_id = 42 AND date >= '2024-01-01';

-- インデックスの使用統計
SELECT object_schema, object_name, index_name, count_star
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE object_schema = DATABASE()
ORDER BY count_star DESC;

キーワード： インデックス、INDEX、Bツリー、BTREE、HASH、FULLTEXT、空間インデックス、カバリングインデックス、複合インデックス、選択性、EXPLAIN、プレフィックス、不可視インデックス、カーディナリティ

第1正規形、第2正規形、第3正規形、非正規化すべき場面、データの整合性とパフォーマンスの釣り合いの取り方。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+ PostgreSQL 13+ SQLite 3.35+ SQL Server 2022+

正規化とは、冗長性を減らし、挿入・更新・削除の異常を防ぐようにスキーマを整理することです。正規形は積み重ねで、第3正規形（3NF）のテーブルは2NFと1NFも満たします。

第1正規形（1NF）

- 各列は、分割できない値を1つだけ持ちます（複数のエンティティを表すリストや入れ子のJSONは不可）。
- 各行は主キーで識別できます。
- 列に繰り返しのグループがありません（phone1、phone2、phone3）。

-- 悪い例：同じ「エンティティ」を繰り返す3つの列
CREATE TABLE customers_v1 (
    id      BIGINT PRIMARY KEY,
    name    VARCHAR(120),
    phone1  VARCHAR(20),
    phone2  VARCHAR(20),
    phone3  VARCHAR(20)
);

-- 良い例：関連テーブル
CREATE TABLE customers (
    id BIGINT PRIMARY KEY,
    name VARCHAR(120)
);
CREATE TABLE customer_phones (
    customer_id  BIGINT NOT NULL,
    phone    VARCHAR(20) NOT NULL,
    kind        VARCHAR(10) NOT NULL,
    PRIMARY KEY (customer_id, phone),
    FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE CASCADE
);

-- SQLite：接続ごとに、最初のトランザクションの前にオンにする
PRAGMA foreign_keys = ON;

CREATE TABLE customer_phones (
    customer_id  INTEGER NOT NULL,
    phone    TEXT NOT NULL,
    kind        TEXT NOT NULL CHECK (kind IN ('mobile', 'home', 'office')),
    PRIMARY KEY (customer_id, phone),
    FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE CASCADE
);

-- SQL Server：代理キーと、名前付きの決まった値の集合
CREATE TABLE customer_phones (
    id          BIGINT IDENTITY(1, 1) PRIMARY KEY,
    customer_id  BIGINT NOT NULL,
    phone    VARCHAR(20) NOT NULL,
    kind        VARCHAR(10) NOT NULL
        CONSTRAINT ck_phone_kind CHECK (kind IN ('mobile', 'home', 'office')),
    UNIQUE (customer_id, phone),
    FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE CASCADE
);

-- あとから一覧を変更する
ALTER TABLE customer_phones DROP CONSTRAINT ck_phone_kind;
ALTER TABLE customer_phones ADD CONSTRAINT ck_phone_kind
    CHECK (kind IN ('mobile', 'home', 'office', 'fax'));

第2正規形（2NF）

- 1NFを満たします。
- キー以外のすべての列が、主キーの一部ではなく主キー全体に従属します。複合キーに当てはまる規則です。

例：order_line (order_id, product_id, quantity, product_name)というテーブルは2NFに違反しています。product_nameは2つ組全体ではなく、product_idだけに従属するからです。

-- 悪い例：同じ製品の行ごとにproduct_nameが繰り返される
CREATE TABLE order_line_v1 (
    order_id      BIGINT,
    product_id    BIGINT,
    quantity      INT,
    product_name  VARCHAR(120),
    PRIMARY KEY (order_id, product_id)
);

-- 良い例：product_nameはproductsテーブルに置く
CREATE TABLE order_line (
    order_id    BIGINT,
    product_id  BIGINT,
    quantity    INT NOT NULL,
    PRIMARY KEY (order_id, product_id),
    FOREIGN KEY (product_id) REFERENCES products(id)
);

第3正規形（3NF）

- 2NFを満たします。
- キー以外の列が、キー以外のほかの列に従属しません（推移的従属がない）。

定番の例：employees (id, name, department_id, department_name)。部署名は従業員のキーに直接ではなく、department_idに従属します。

-- 悪い例：推移的従属
CREATE TABLE employees_v1 (
    id                BIGINT PRIMARY KEY,
    name              VARCHAR(120),
    department_id     BIGINT,
    department_name   VARCHAR(80)
);

-- 良い例
CREATE TABLE departments (
    id     BIGINT PRIMARY KEY,
    name   VARCHAR(80)  NOT NULL
);
CREATE TABLE employees (
    id             BIGINT PRIMARY KEY,
    name           VARCHAR(120),
    department_id  BIGINT NOT NULL,
    FOREIGN KEY (department_id) REFERENCES departments(id)
);

BCNFとそれより高い正規形

ボイス・コッド正規形（BCNF）は3NFをさらに厳しくしたもので、4NFと5NFは多値従属と結合従属を扱います。たいていのトランザクション系のスキーマでは、きれいに3NFまで到達すれば十分です。

非正規化すべき場面

意図的な非正規化は、パフォーマンスのために規則を破ることです。次の場合には妥当です：

1. 読み取りが多く、書き込みが少ない：テーブルにキャッシュしたフィールド（orders.total_paid）があれば、繰り返しのSUM(...)を避けられます。
2. レポートや分析：スタースキーマやスノーフレークスキーマは、わざと非正規化します。
3. 事前に計算した結果：マテリアライズドビューや集計テーブル。

受け入れることになる代償：

- 更新の異常：非正規化したデータが変わったら、N行を更新しなければなりません。
- 一時的な不整合：更新が途中で失敗すると、キャッシュしたフィールドがずれることがあります。
- トリガーやアプリケーションのロジック：データを同期させておく仕組みが必要です。

-- 例：読み取りのたびのSUMを避けるため、注文の合計をキャッシュする
ALTER TABLE orders
    ADD COLUMN total DECIMAL(12, 2) NOT NULL DEFAULT 0;

-- トリガーで保守する
DELIMITER //
CREATE TRIGGER order_line_after_insert
AFTER INSERT ON order_line
FOR EACH ROW
BEGIN
    UPDATE orders
       SET total = (SELECT COALESCE(SUM(quantity * unit_price), 0)
                    FROM order_line
                    WHERE order_id = NEW.order_id)
     WHERE id = NEW.order_id;
END//
DELIMITER ;

CREATE FUNCTION recalculate_total() RETURNS trigger
LANGUAGE plpgsql AS $$
BEGIN
    UPDATE orders
       SET total = (SELECT COALESCE(SUM(quantity * unit_price), 0)
                    FROM order_line
                    WHERE order_id = NEW.order_id)
     WHERE id = NEW.order_id;
    RETURN NULL;
END;
$$;

CREATE TRIGGER order_line_after_insert
AFTER INSERT ON order_line
FOR EACH ROW EXECUTE FUNCTION recalculate_total();

CREATE TRIGGER order_line_after_insert
AFTER INSERT ON order_line
FOR EACH ROW
BEGIN
    UPDATE orders
       SET total = (SELECT COALESCE(SUM(quantity * unit_price), 0)
                    FROM order_line
                    WHERE order_id = NEW.order_id)
     WHERE id = NEW.order_id;
END;

ALTER TABLE orders
    ADD total DECIMAL(12, 2) NOT NULL DEFAULT 0;

CREATE TRIGGER order_line_after_insert
ON order_line
AFTER INSERT
AS
BEGIN
    SET NOCOUNT ON;
    UPDATE p
       SET total = (SELECT COALESCE(SUM(d.quantity * d.unit_price), 0)
                    FROM order_line d
                    WHERE d.order_id = p.id)
      FROM orders p
     WHERE p.id IN (SELECT order_id FROM inserted);
END;

CREATE VIEW dbo.orders_total WITH SCHEMABINDING AS
SELECT order_id, SUM(quantity * unit_price) AS total, COUNT_BIG(*) AS lines
FROM dbo.order_line
GROUP BY order_id;

CREATE UNIQUE CLUSTERED INDEX ux_orders_total ON dbo.orders_total (order_id);

推奨事項

1. デフォルトでは3NFで設計する。整合性が守られます。
2. 非正規化はデータに基づいてだけ行う：遅いクエリーを測定し、キャッシュを試し、比較します。
3. 非正規化したことを文書にする。DDLにコメントがないと、次のDBAが間違いだと思って「正規化」し直してしまいます。

キーワード： 正規化、1NF、2NF、3NF、BCNF、非正規化、冗長性、関数従属性、キー、整合性、トリガー

INNER、LEFT、RIGHT、CROSS、SELF、FULL OUTER JOIN：それぞれをいつ使うかを、典型的な注文スキーマの例で説明します。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+ PostgreSQL 13+ SQLite 3.35+ SQL Server 2022+

JOINは、条件に基づいて2つ以上のテーブルの行を組み合わせます。一致する相手が見つからない行をどう扱うかは、結合の種類で決まります。

例では次のテーブルを使います：

CREATE TABLE customers (
    id      BIGINT PRIMARY KEY,
    name    VARCHAR(120) NOT NULL
);
CREATE TABLE orders (
    id          BIGINT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    total       DECIMAL(12, 2) NOT NULL,
    FOREIGN KEY (customer_id) REFERENCES customers(id)
);

INNER JOIN

両方のテーブルで一致する行だけを返します。デフォルトで、最もよく使われる結合です。

SELECT c.name, o.total
FROM customers c
INNER JOIN orders o ON o.customer_id = c.id;

LEFT JOIN（LEFT OUTER JOIN）

左のテーブルのすべての行と、右のテーブルで一致する行。右側に一致がないフィールドはNULLになります。「すべてのX、Yがあればそれも」という場合に便利です。

-- 注文があってもなくても、すべての顧客
SELECT c.name, COUNT(o.id) AS orders
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.id, c.name;

注文のない顧客：WHERE … IS NULLを使う定番のパターンです：

SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

RIGHT JOIN

LEFTの逆です。ほとんどの場合、テーブルの順序を入れ替えたLEFT JOINとして書きます。そのほうが読みやすくなります。

-- 順序を入れ替えたLEFT JOINと同じ
SELECT c.name, o.id
FROM orders o
RIGHT JOIN customers c ON o.customer_id = c.id;

CROSS JOIN

直積です。Aのすべての行とBのすべての行を組み合わせます。ON句はありません。すべての組み合わせを作るのに便利です（レポート用のカレンダー×製品など）。

-- レポート用に（顧客, 月）のすべての組み合わせを生成
SELECT c.id, m.month
FROM customers c
CROSS JOIN (
    SELECT 1 AS month UNION ALL SELECT 2 UNION ALL SELECT 3
    -- ...12まで
) m;

SELF JOIN

同じテーブルが、別のエイリアスで2回現れます。階層や、同じテーブルの行どうしの比較に便利です。

CREATE TABLE employees (
    id         BIGINT PRIMARY KEY,
    name       VARCHAR(120),
    manager_id BIGINT NULL,
    FOREIGN KEY (manager_id) REFERENCES employees(id)
);

-- 各従業員と、その上司の名前
SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m ON m.id = e.manager_id;

FULL OUTER JOIN

両方のテーブルのすべての行。一致しない行は、相手のない側がNULLになります。

-- MySQLでの代用
SELECT c.name, o.id
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id

UNION

SELECT c.name, o.id
FROM customers c
RIGHT JOIN orders o ON o.customer_id = c.id
WHERE c.id IS NULL;

-- PostgreSQLのネイティブな書き方
SELECT c.name, o.id
FROM customers c
FULL OUTER JOIN orders o ON o.customer_id = c.id;

-- SQLite 3.39+
SELECT c.name, o.id
FROM customers c
FULL OUTER JOIN orders o ON o.customer_id = c.id;

-- SQL Serverのネイティブな書き方
SELECT c.name, o.id
FROM customers c
FULL OUTER JOIN orders o ON o.customer_id = c.id;

STRAIGHT_JOIN

SELECT STRAIGHT_JOIN c.name, o.id
FROM customers c, orders o
WHERE o.customer_id = c.id;

-- SQLite：書いた順序が優先される
SELECT c.name, o.id
FROM orders o
CROSS JOIN customers c ON o.customer_id = c.id;

-- SQL Server：書いた順序が優先される
SELECT c.name, o.id
FROM orders o
JOIN customers c ON o.customer_id = c.id
OPTION (FORCE ORDER);

-- 各顧客の最も高額な注文
SELECT c.name, x.total
FROM customers c
CROSS APPLY (
    SELECT TOP (1) o.total
    FROM orders o
    WHERE o.customer_id = c.id
    ORDER BY o.total DESC
) x;

アンチジョインとセミジョイン

SQLのキーワードではなく、論理的なパターンです：

- セミジョイン（一致が少なくとも1つある）→ EXISTSまたはIN。
- アンチジョイン（一致が1つもない）→ NOT EXISTSまたはLEFT JOIN ... WHERE ... IS NULL。

-- セミジョイン：注文が1件以上ある顧客
SELECT c.id, c.name
FROM customers c
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);

-- アンチジョイン：注文のない顧客
SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);

NOT INはアンチジョインではありません。サブクエリーがNULLを1つでも返すと、比較が真になることはなく、結果は0行になります。5人の顧客と6件の注文（うち3件はcustomer_idがNULL）で測定すると、NOT EXISTSとLEFT JOIN … IS NULLは2行を返し、NOT INは0行を返します。PostgreSQL 17.6、MySQL 8.0.46、SQLite 3.51、SQL Server 2025のどれでも同じです。

パフォーマンス

1. ONの列にはインデックスを付けます。特に結合の「内側」（外側の行ごとに検索される側）に。
2. 結合の前に、できるだけ絞り込みます（必要に応じて各テーブルにWHERE）。
3. 式によるJOIN（ON LOWER(a.code) = LOWER(b.code)）は避けます。インデックスが使われません。
4. EXPLAINは、読み取りの順序と方式を、エンジンごとの用語で示します。

-- SQLiteで実行計画を求めるにはこう書く。EXPLAINだけではない
EXPLAIN QUERY PLAN
SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);

キーワード： 結合、JOIN、INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL OUTER JOIN、CROSS JOIN、SELF JOIN、EXISTS、セミジョイン、アンチジョイン、STRAIGHT_JOIN、ネステッドループ、CROSS APPLY、OUTER APPLY、FORCE ORDER

パフォーマンスを左右する変数：バッファプール、接続数、最大パケット、クエリーキャッシュ、そしてMySQLとMariaDBの重要な違い。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+

サーバのデフォルトの設定は、本番環境ではほとんどの場合最適ではありません。パフォーマンスと安定性に最も大きく影響する変数は次のとおりです。

innodb_buffer_pool_size

InnoDBの主なキャッシュで、テーブル、インデックス、データを持ちます。最も重要な変数です。

- 目安：MySQL専用のサーバでRAMの60%〜80%。
- 推奨される最小値：本番環境で1 GiB。
- MySQL 8.0以降とMariaDB 10.5以降では、オンラインで（再起動せずに）変更できます。

-- 現在のサイズを確認する
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

-- オンラインで変更する（8 GB）
SET GLOBAL innodb_buffer_pool_size = 8 * 1024 * 1024 * 1024;

max_connections

同時接続の最大数です。MySQLでもMariaDBでもデフォルトは151です。

- 接続ごとにメモリーを消費します（thread_stackとセッションごとのバッファで約256 KiB）。
- 値が大きすぎると、負荷がかかったときにパフォーマンスを損ないます（競合）。
- SHOW STATUS LIKE 'Max_used_connections'で測定します。上限に達したら、少しずつ増やします。

SHOW STATUS LIKE 'Max_used_connections';
SHOW STATUS LIKE 'Threads_connected';
SET GLOBAL max_connections = 500;

max_allowed_packet

プロトコルのパケットの最大サイズです（大きなINSERT、LOAD DATA、BLOB）。

- デフォルトはMySQL 8.0で64 MiB、それ以前のバージョンでは16 MiB。
- 操作がこれを超えると、Got a packet bigger than 'max_allowed_packet' bytesエラーになります。
- BLOBの多いワークロードでは、256 MiBや1 GiBに増やすのが一般的です。

SET GLOBAL max_allowed_packet = 256 * 1024 * 1024;
-- クライアントもパラメータを渡す必要がある
-- （コマンドライン：--max-allowed-packet=256M）

クエリーキャッシュ

SELECTクエリーの結果全体をキャッシュします。

SHOW VARIABLES LIKE 'query_cache%';
SET GLOBAL query_cache_type = 'ON';
SET GLOBAL query_cache_size = 64 * 1024 * 1024;

ログと永続性

innodb_flush_log_at_trx_commitは、REDOログをいつフラッシュするかを制御します：

- 1（デフォルト） — コミットのたびにフラッシュとfsync。永続性は最大、速度は最小。厳密なACID。
- 2 — コミットのたびにフラッシュし、fsyncは1秒に1回。OSがクラッシュすると約1秒分を失う可能性があります。ほぼACID。
- 0 — フラッシュとfsyncは1秒に1回。MySQLがクラッシュすると約1秒分を失う可能性があります。ACIDではない。

レプリカや、限られた損失を許容できる環境では、2でスループットが3倍から5倍になることがあります。リスクを理解せずにプライマリで変更しないでください。

thread_pool

tmp_table_size / max_heap_table_size

メモリー内の一時テーブルの最大サイズです。操作が上限を超えると、MySQLはそれをディスクに書き出し、速度が落ちます。2つの値は同じにしておきます。

SHOW VARIABLES LIKE 'tmp_table_size';
SHOW VARIABLES LIKE 'max_heap_table_size';
SET GLOBAL tmp_table_size = 256 * 1024 * 1024;
SET GLOBAL max_heap_table_size = 256 * 1024 * 1024;

-- ディスクに書き出された一時テーブルの数
SHOW STATUS LIKE 'Created_tmp_disk_tables';

innodb_io_capacity / innodb_io_capacity_max

InnoDBがダーティページの書き出しとパージに使えるIOPSです。デフォルトはMySQL 8.0とMariaDBで200 / 2000、現在のMySQLで10 000 / 20 000です（26.7で測定）。

- 最新のSSD：2000 / 4000以上。
- HDD：デフォルトのままにします。

設定の永続化

SET PERSIST innodb_buffer_pool_size = 8589934592;
SET PERSIST_ONLY max_connections = 500; -- 再起動のときだけ適用される
RESET PERSIST innodb_buffer_pool_size;   -- 永続化を解除する

MariaDBでは、my.cnf（/etc/my.cnf.d/）を編集して再起動するか、インクルード（!include）を使って永続化します。

全般的な推奨事項

1. 何かに手を付ける前にワークロードを知る。書き込みの多いOLTPと、読み取り専用のデータウェアハウスでは、設定が違います。
2. 一度に1つの変数だけを変え、影響を測定します。
3. my.cnfの変更はすべて、理由を説明するコメントを付けて記録します。
4. 理解せずにブログの設定をコピーしない — 「最適な」値はハードウェアとワークロードに大きく左右されます。

キーワード： 設定、バッファプール、innodb_buffer_pool_size、max_connections、max_allowed_packet、query_cache、thread_pool、tmp_table_size、innodb_flush_log_at_trx_commit、io_capacity、MY.CNF

データベース、テーブル、列の最大サイズ、識別子の名前の長さ、オブジェクト名に使える文字。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+

エンジンの制限を知っておくと、規模が大きくなったときに慌てずに済みます。ここでは、最近のMySQLとMariaDBで実際に効いてくる上限をまとめます。

データベースごと

- 全体のサイズ：ファイルシステムで決まります。innodb_file_per_table = ON（デフォルト）では、各テーブルが1つの.ibdファイルになります。ext4やXFSでの理論上の上限はエクサバイト単位で、実際の上限はストレージで決まります。
- データベースあたりのテーブル数：事実上無制限です。カタログ（information_schema、mysql.tables）は数十万個でも問題なく扱えます。10,000個を超えるテーブルを扱う負荷では、table_open_cacheの調整が必要です。

テーブルごと

- 行数：理論上は2⁶⁴行。実際には、スキーマとインデックスが適切なら数千億行。
- テーブルの最大サイズ：デフォルトのINNODB_PAGE_SIZE（16 KiB）で64 TiB。
- 列数：サーバではテーブルあたり最大4,096、InnoDBでは1,017ですが、実際の上限は数ではなく行サイズで決まります。
- 最大の行サイズ：65,535バイト（BLOB/TEXTは行の外に格納されるので含みません）。
- テーブルあたりのインデックス数：64。
- インデックスあたりの列数：16（InnoDBのBツリー）。
- インデックスキーの最大長：DYNAMIC/COMPRESSEDで3072バイト（MySQL 5.7以降とMariaDB 10.2以降のデフォルトの形式）。

-- テーブルのサイズを調べる
SELECT table_schema, table_name,
       ROUND((data_length + index_length) / 1024 / 1024, 2) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC
LIMIT 20;

列ごと

識別子（オブジェクト名）

- データベース、テーブル、列、インデックス、ビュー：64文字。
- 列のエイリアス：256文字。
- 関数、プロシージャ、トリガー、イベント：64文字。
- 制約（FK、CHECK、UNIQUE）：64文字。

識別子に使える文字

- バッククォートなし：ASCIIの英字、数字、_、$。数字だけで始めることや、数字だけの名前はできません。
- バッククォートあり（`weird name`）：U+0000（NUL）を除くすべてのUnicode文字。

推奨する規則：ASCIIのスネークケース（order_customer_id）。空白、アクセント記号付きの文字、大文字は避けてください。LinuxとmacOSで扱いが変わるシステムがあります。

-- 有効だが推奨しない
CREATE TABLE `orders 2024 year` (`Order Number` INT);

-- 推奨
CREATE TABLE orders_2024 (order_number INT);

大文字と小文字の区別

lower_case_table_names：

- 0：名前は作成したとおりに格納され、大文字と小文字を区別します。Linuxのデフォルト。
- 1：名前は小文字で格納され、比較では大文字と小文字を区別しません。Windowsのデフォルト。
- 2：名前はそのまま格納されますが、比較では大文字と小文字を区別しません。macOSとWindowsのみで、macOSのデフォルト。

既存のインストールでこの値を変えると、データが壊れます。サーバの初期化のときに決めてください。

クエリーごと

- 入れ子のサブクエリー：最大64階層。
- UNION：理論上は無制限ですが、数百を超えるとオプティマイザの性能が落ちます。
- プリペアドステートメントのパラメータ：65,535。
- IN(...)の値の数：実用的なのは数千まで。それを超えるなら、一時テーブルとのJOINを使ってください。

セッションごと

- セッション変数（@@SESSION.xxx）：実行時に変えられるグローバル変数のほとんどを設定できます。
- ユーザ変数（@variable）：名前は最大64文字。

文字セットと照合順序

- 推奨する文字セット：utf8mb4（完全なUTF-8、4バイト）。別名のutf8は歴史的なもので、3バイトに限られます（絵文字を扱えません）。
- MySQL 8.0以降で推奨する照合順序：utf8mb4_0900_ai_ci（大文字と小文字を区別せず、アクセントも区別しない、Unicode 9ベース）。
- MariaDBでは：utf8mb4_unicode_ciまたはuca1400_ai_ci（10.10以降）。

ALTER DATABASE my_db
    CHARACTER SET utf8mb4
    COLLATE utf8mb4_unicode_ci;

ALTER TABLE customers
    CONVERT TO CHARACTER SET utf8mb4
    COLLATE utf8mb4_unicode_ci;

推奨事項

1. 余裕を持って設計する：1,000万行を見込むなら、インデックスとパーティションは1億行に合わせて設計します。
2. BIGINT UNSIGNEDを使う：大きくなりうるテーブルの主キーに。INTは約20億で埋まります。
3. 文字セットと照合順序を明示する：データベース、テーブル、列の各レベルで。デフォルトに頼ると、移行が壊れることがあります。
4. モデルの制限を文書にする（年あたりの想定行数、列ごとの最大サイズ）。容量計画にも、異常なクエリーを見つけるのにも役立ちます。

キーワード： 制限、最大、サイズ、列、行、識別子、文字セット、照合順序、utf8mb4、lower_case_table_names、インデックス、行サイズ

スキーマ設計、命名規則、バックアップ、レプリケーション、ユーザのセキュリティ、最小限のGRANT、監査。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+ SQL Server 2022+

アマチュアのデータベースと、本番環境で保守できるデータベースを分ける運用上の推奨事項です。

スキーマ設計

CREATE TABLE orders (
    id           BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    customer_id  BIGINT UNSIGNED NOT NULL,
    status       TINYINT UNSIGNED NOT NULL DEFAULT 0,
    created_at   DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
    updated_at   DATETIME(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6)
                             ON UPDATE CURRENT_TIMESTAMP(6),
    FOREIGN KEY (customer_id) REFERENCES customers(id)
        ON DELETE RESTRICT ON UPDATE CASCADE,
    INDEX idx_orders_customer (customer_id),
    INDEX idx_orders_created (created_at)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4
  COLLATE = utf8mb4_unicode_ci;

-- まずスキーマを、独自のバッチで：CREATE SCHEMA sales;
CREATE TABLE sales.orders (
    id           BIGINT IDENTITY(1, 1) CONSTRAINT pk_orders PRIMARY KEY,
    customer_id  BIGINT       NOT NULL,
    status       TINYINT      NOT NULL CONSTRAINT df_orders_status DEFAULT 0,
    created_at   DATETIME2(3) NOT NULL CONSTRAINT df_orders_created_at DEFAULT SYSUTCDATETIME(),
    updated_at   DATETIME2(3) NOT NULL CONSTRAINT df_orders_updated_at DEFAULT SYSUTCDATETIME(),
    CONSTRAINT fk_orders_customers FOREIGN KEY (customer_id)
        REFERENCES sales.customers (id) ON UPDATE CASCADE,
    CONSTRAINT ck_orders_status CHECK (status BETWEEN 0 AND 4)
);
CREATE INDEX idx_orders_customer_id ON sales.orders (customer_id);
CREATE INDEX idx_orders_created_at  ON sales.orders (created_at);

命名規則

- テーブル：snake_case。コレクションを表すなら複数形（orders、customers）。
- 列：snake_case。冗長な接頭辞は付けません（customersの中ではcustomer_nameではなくname）。
- 外部キー：<table>_id（customer_id）。
- インデックス：idx_<table>_<columns>、一意ならuq_<table>_<columns>。
- 明示的な外部キー制約：fk_<table>_<target_table>。
- プロシージャと関数：接頭辞sp_／fn_は任意で、動詞は原形にします（fn_calculate_discount）。

一貫性は個人の好みに勝ります。規則をチームで合意し、例外なく適用してください。

バックアップ

-- トランザクションの一貫性を保った論理ダンプ
-- （SQLではなくシェルから）：
-- mysqldump --single-transaction --routines --triggers --events \\
--           -u root -p my_db > my_db.sql

-- 物理バックアップ（mariabackup）：
-- mariabackup --backup --target-dir=/srv/backup/full \\
--             --user=root --password=...

ALTER DATABASE my_db SET RECOVERY FULL;
BACKUP DATABASE my_db TO DISK = N'/var/opt/mssql/data/my_db_full.bak'
    WITH CHECKSUM, COMPRESSION, INIT;
BACKUP LOG my_db TO DISK = N'/var/opt/mssql/data/my_db_log.trn'
    WITH CHECKSUM, INIT;
RESTORE VERIFYONLY FROM DISK = N'/var/opt/mssql/data/my_db_full.bak'
    WITH CHECKSUM;

レプリケーション

ユーザと権限

最小権限の原則：どの接続も、できるだけ制限されたユーザを使います。

-- 権限を絞ったアプリケーション用のユーザを作成
CREATE USER 'app_orders'@'10.0.%.%' IDENTIFIED BY 'strong_password';

GRANT SELECT, INSERT, UPDATE, DELETE
   ON my_db.orders          TO 'app_orders'@'10.0.%.%';
GRANT SELECT
   ON my_db.customers       TO 'app_orders'@'10.0.%.%';

-- 本番環境では決して使わない
-- GRANT ALL PRIVILEGES ON *.* TO 'app'@'%';
FLUSH PRIVILEGES;

USE master;
CREATE LOGIN app_orders WITH PASSWORD = N'Strong-Password-2026',
    CHECK_POLICY = ON, DEFAULT_DATABASE = my_db;
USE my_db;
CREATE USER app_orders FOR LOGIN app_orders WITH DEFAULT_SCHEMA = sales;
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::sales TO app_orders;

-- 本番環境では決して使わない
-- ALTER SERVER ROLE sysadmin ADD MEMBER app_orders;
-- ALTER ROLE db_owner ADD MEMBER app_orders;

監査

INSTALL SONAME 'server_audit';
SET GLOBAL server_audit_logging = ON;
SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';
SET GLOBAL server_audit_file_path = '/var/log/mysql/audit.log';

USE master;
CREATE SERVER AUDIT aud_sales TO FILE (FILEPATH = N'/var/opt/mssql/data/');
ALTER SERVER AUDIT aud_sales WITH (STATE = ON);
USE my_db;
CREATE DATABASE AUDIT SPECIFICATION das_sales FOR SERVER AUDIT aud_sales
    ADD (SELECT, INSERT, UPDATE, DELETE ON SCHEMA::sales BY public)
    WITH (STATE = ON);

SELECT event_time, action_id, server_principal_name, statement
FROM sys.fn_get_audit_file(N'/var/opt/mssql/data/aud_sales*.sqlaudit', DEFAULT, DEFAULT);

Calíopeは、サーバのログとは別に、実行したクエリーのローカルログ（「SQLログ」）を接続セッションごとに保持します。

本番環境の最低限のチェックリスト

キーワード： ベストプラクティス、設計、命名規則、バックアップ、レプリケーション、GTID、バイナリログ、GRANT、監査、セキュリティ、InnoDB、外部キー、TLS、SQL Server、IDENTITY、SEQUENCE、スキーマ、ログイン、XACT_ABORT、SQL Server Audit

EXPLAINによるクエリーの分析、スロークエリーログ、ボトルネックの特定、InnoDBのキャッシュ、performance_schemaの使い方。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+

最適化は測定から始まります。データがなければ、最適化は当て推量です。基本的な道具は次のとおりです。

EXPLAIN

オプティマイザがクエリーに選んだ実行計画を表示します。クエリーは実行しないので、本番環境でも安全に使えます。

EXPLAIN SELECT c.name, COUNT(o.id) AS orders
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE c.active = 1
GROUP BY c.id;

重要な列：

- type — アクセス方法。良いものから悪いものへ：system → const → eq_ref → ref → range → index → ALL。ALLはテーブルのフルスキャンで、大きなテーブルでは良くありません。
- key — 選ばれたインデックス。NULLはインデックスを使っていないことを示します。
- rows — 調べると推定される行数。返される行数よりずっと多ければ、改善の余地があります。
- Extra — 役に立つヒント：
- Using index — カバリングインデックス（とても良い）。
- Using where — 行を読んだあとにフィルタを適用。
- Using temporary — 一時テーブルが必要（高コスト）。
- Using filesort — インデックスの外での並べ替え（大きなテーブルでは高コスト）。

EXPLAIN ANALYZE（MySQL 8.0.18以降。MariaDBでは単にANALYZE）

クエリーを実行し、ノードごとの実際の時間を表示します。EXPLAINより高コストですが、得られる情報はずっと多くなります。

EXPLAIN ANALYZE
SELECT c.name, COUNT(o.id) AS orders
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.id;

Calíopeには、実行計画のツリーを描画する実行計画ビューアが組み込まれています。SQLエディタのツールバーの「実行計画ビューア」ボタンを、選んだクエリーに対して使います。

スロークエリーログ

long_query_time秒より長くかかったクエリーをすべて記録します。

SHOW VARIABLES LIKE 'slow_query%';
SHOW VARIABLES LIKE 'long_query_time';

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;     -- 1秒
SET GLOBAL log_queries_not_using_indexes = 'ON';
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

ログの分析：

- mysqldumpslow — MySQLに含まれている昔からのツール。
- pt-query-digest（Percona Toolkit） — 事実上の標準。フィンガープリントでまとめて統計を表示します。

performance_schema

サーバの詳細な統計を持つスキーマです。

-- 累積時間の合計が多い上位10件のクエリー
SELECT digest_text,
       count_star            AS exec,
       ROUND(sum_timer_wait/1e9, 2) AS total_ms,
       ROUND(avg_timer_wait/1e9, 2) AS avg_ms,
       sum_rows_examined     AS rows_exam
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_timer_wait DESC
LIMIT 10;

-- I/Oが最も多いテーブル
SELECT object_schema, object_name,
       count_read, count_write,
       ROUND(sum_timer_wait/1e9, 2) AS total_ms
FROM performance_schema.table_io_waits_summary_by_table
WHERE object_schema = DATABASE()
ORDER BY sum_timer_wait DESC
LIMIT 10;

InnoDBのキャッシュ

- バッファプール — データとインデックス。重要な指標はヒット率（1 − Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests）。目標は99%超です。

SELECT ROUND((1 - r.v / q.v) * 100, 2) AS buffer_pool_hit_pct
FROM (SELECT VARIABLE_VALUE AS v FROM performance_schema.global_status
      WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads') r,
     (SELECT VARIABLE_VALUE AS v FROM performance_schema.global_status
      WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests') q;

-- performance_schemaなしで（MariaDBではデフォルトでオフ）、2つのカウンタを手で：
SHOW STATUS LIKE 'Innodb_buffer_pool_read%';

- アダプティブハッシュインデックス — バッファプールのよく使われるページに対して自動で作られるハッシュ。MySQL 8.0ではデフォルトでオン、現在のMySQLとMariaDBではオフです（測定結果：8.0.46では1、26.7とMariaDB 13.0では0）。
- チェンジバッファ — バッファプールにないページへの変更をバッファします。

よくあるボトルネック

クエリーの最適化 — よくあるパターン

1. 必要なものだけを選ぶ。アプリケーションではSELECT *を避けます。
2. インデックスのある列に関数を使わない：
- 悪い例：WHERE YEAR(date) = 2024 → インデックスを使いません。
- 良い例：WHERE date >= '2024-01-01' AND date < '2025-01-01'。
3. 大きなオフセットを伴うLIMITは高コスト — 深いページ送りにはキーセットページネーションを使います：WHERE id > :last_seen ORDER BY id LIMIT 50。
4. 大きなテーブルでのCOUNT(*) — InnoDBはカウンタを保持していません。集計用の列や推定値（information_schema.tables.table_rows）を検討します。
5. 相関のないサブクエリーは1回だけ実行され、相関サブクエリーは外側の行ごとに1回実行されます。可能ならJOINに書き換えます。

推奨事項

基本的な監視用のダッシュボードを作ります（Calíopeにはあります：「ダッシュボード」）。内容は：

- 接続数（Threads_connected、Threads_running）。
- バッファプールのヒット率。
- 1分あたりのスロークエリーの数。
- レプリケーションの遅延。
- 表領域ごとのディスク容量。

劣化に早く気づくほど、直すのは簡単になります。

キーワード： パフォーマンス、最適化、EXPLAIN、EXPLAIN ANALYZE、スロークエリーログ、performance_schema、バッファプール、ファイルソート、カバリングインデックス、フィルタ、ボトルネック、PT-QUERY-DIGEST

ACID、COMMITとROLLBACK、4つの分離レベルと、それぞれが許す異常。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+

トランザクションは、複数の文を1つの単位にまとめ、すべて適用されるか、まったく適用されないかのどちらかにします。InnoDBではすべての文がトランザクションの中で実行されます。自分で開かなければ、サーバが文ごとに1つ開いてコミットします（autocommit = 1）。

ACID
- 原子性 — すべての変更が適用されるか、何も適用されないか。
- 一貫性 — データベースはある有効な状態から別の有効な状態へ移り、制約は守られます。
- 分離性 — 同時に実行されるトランザクションが、互いの途中の状態を見ることはありません。
- 永続性 — コミットしたものは、サーバがクラッシュしても残ります。

手動での制御
COMMITは確定し、ROLLBACKはSTART TRANSACTION以降に行ったことをすべて取り消します。

START TRANSACTION;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
UPDATE cuentas SET saldo = saldo + 100 WHERE id = 2;
COMMIT;

セーブポイント
SAVEPOINTを使うと、トランザクションの残りを失わずに一部だけを取り消せます：

START TRANSACTION;
INSERT INTO pedidos (cliente_id) VALUES (42);
SAVEPOINT tras_pedido;
INSERT INTO lineas (pedido_id, sku) VALUES (LAST_INSERT_ID(), 'X-1');
ROLLBACK TO SAVEPOINT tras_pedido;
COMMIT;

4つのレベル

InnoDBのデフォルトはREPEATABLE READです。MVCCとギャップロックのおかげで、InnoDBはこのレベルでもファントムリードを防ぎます。SQL標準はそれを求めていません。

レベルを変更する

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

SELECT @@transaction_isolation;

DDLに注意
CREATE、ALTER、DROP、TRUNCATEは暗黙のコミットを引き起こします。ROLLBACKでは取り消せません。途中で止まった移行は、テーブルをそのときの状態のまま残します。

長いトランザクション
開いたままのトランザクションがあると、InnoDBは一貫性のある読み取りのために、すべての行の古いバージョンを保持し続けなければなりません。忘れられたSTART TRANSACTIONはUNDOログを増やし、サーバ全体を劣化させます。次のようにして見つけます：

SELECT trx_id, trx_started, trx_mysql_thread_id, trx_query
FROM information_schema.INNODB_TRX
ORDER BY trx_started;

推奨事項
トランザクションは短く保ち、ビジネスロジックは外に、SQLだけを中に入れます。READ COMMITTEDはロックを減らし、多くのWebアプリケーションが使っています。同じトランザクションの中で2回の読み取りが同じ結果を返す必要があるなら、REPEATABLE READのままにします。

キーワード： トランザクション、COMMIT、ROLLBACK、SAVEPOINT、分離、ACID、MVCC、READ COMMITTED、REPEATABLE READ、SERIALIZABLE、AUTOCOMMIT、innodb_trx

InnoDBが何をロックするか、デッドロックがなぜ起きるか、推測に頼らずに診断する方法。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+

InnoDBはテーブルではなく行をロックし、書き込みのときに自動でロックします。同時実行の問題のほとんどは、クエリーが結果としてどの行をロックしたかに行き着き、それは使ったインデックスで決まります。

ロックの種類
- 共有（S）：複数のトランザクションが同じ行を同時に読めます。
- 排他（X）：書き込む側が取ります。ほかの誰も、その行をロック付きで読むことも書くこともできません。
- ギャップ：挿入を防ぐために、2つのインデックス値の*間*の範囲をロックします。REPEATABLE READとSERIALIZABLEのときだけです。
- ネクストキー：行と、その前のギャップ。インデックスを走査するときのInnoDBの通常のモードです。
- インテンション（IS/IX）：中に行ロックがあることをテーブルのレベルで示し、LOCK TABLESが割り込むのを防ぎます。

実務上の帰結：クエリーがインデックスを使わないと、InnoDBはテーブル全体を走査し、一致した行だけでなく調べたすべての行をロックします。よいインデックスは速くするだけでなく、ロックされる範囲も小さくします。

ロック付きの読み取り
普通のSELECTは何もロックしません（MVCCで一貫したバージョンを読みます）。読んでから書くまでの間に誰にも割り込まれたくないなら、FOR UPDATEかFOR SHAREで明示的にロックを求めます：

START TRANSACTION;
SELECT saldo FROM cuentas WHERE id = 1 FOR UPDATE;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
COMMIT;

デッドロックとは
2つのトランザクションが、それぞれ相手の持つロックを待っている状態です。どちらも先に進めません：

-- A
START TRANSACTION;
UPDATE cuentas SET saldo = saldo - 10 WHERE id = 1;
UPDATE cuentas SET saldo = saldo + 10 WHERE id = 2;

-- B
START TRANSACTION;
UPDATE cuentas SET saldo = saldo - 10 WHERE id = 2;
UPDATE cuentas SET saldo = saldo + 10 WHERE id = 1;

InnoDBは自分でこれを検出し、ロールバックのコストが最も小さいトランザクションを強制終了します。そのトランザクションはエラー1213 Deadlock found when trying to get lockを受け取ります。サーバの障害でもデータの破損でもありません。正しい動作であり、アプリケーションはそのトランザクションを再試行しなければなりません。

エラー1205 Lock wait timeout exceededは別物です。こちらには循環がなく、待ち時間がinnodb_lock_wait_timeout（デフォルトは50秒）を超えただけです。

診断
SHOW ENGINE INNODB STATUSの「LATEST DETECTED DEADLOCK」セクションには、最後のデッドロックが、両方のトランザクションと関係した文とともに残っています。今まさに保持されているロックを見るには、MySQL 8.0以降ではperformance_schemaを使います（MariaDBにはdata_locksがありません。そこではinformation_schema.INNODB_LOCK_WAITSとINNODB_TRXです）：

SHOW ENGINE INNODB STATUS;

SELECT * FROM performance_schema.data_locks;

SELECT * FROM performance_schema.data_lock_waits;

SELECT @@innodb_lock_wait_timeout;

避ける方法
1. 常に同じ順序でアクセスする：すべてのコードが同じ順序でテーブルと行に触れれば、循環は生まれません。
2. トランザクションを短くする：ロックを持つ時間が短いほど、衝突の機会も減ります。
3. 絞り込みに使う列にインデックスを付ける：一致さえしなかった行をロックせずに済みます。
4. 再試行する：同時実行のシステムでは、たまのデッドロックは普通のことです。トランザクションを、間隔を空けて再試行する処理で包みます。
5. 不要なSELECT ... FOR UPDATEを避ける：書き込まないなら、ロックを求めないでください。

推奨事項
ロックの問題に向き合うときは、まずクエリーの実行計画を見てください。実際のデッドロックのほとんどは、足りないインデックスを追加すれば消えます。Calíopeの「プロセスリスト」で、どのセッションが待っているかがわかります。

キーワード： ロック、デッドロック、ギャップロック、ネクストキーロック、FOR UPDATE、FOR SHARE、エラー1213、InnoDBステータス、data_locks、ロック待ちタイムアウト

RANGE、LIST、HASH、KEY、パーティションプルーニング、DROP PARTITIONによる即時のパージ。

対象： MySQL 5.7+ MariaDB 10.5+ Aurora 2+

パーティション分割は、1つのテーブルをいくつかの物理的な部分に分けますが、サーバからは1つのテーブルに見えたままです。クエリーを魔法のように速くするわけではありません。得られるのはパーティションプルーニングと、なによりも数百万行を一瞬で削除できることです。

効果があるとき
はっきりしているのは、日付とともに増え、古いデータをパージするテーブルです：ログ、イベント、指標、監査。そこではDROP PARTITIONが、何時間もかかるDELETEの代わりになります。

CREATE TABLE eventos (
    id        BIGINT NOT NULL AUTO_INCREMENT,
    ocurrido  DATE   NOT NULL,
    payload   JSON,
    PRIMARY KEY (id, ocurrido)
)
PARTITION BY RANGE (YEAR(ocurrido)) (
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p2025 VALUES LESS THAN (2026),
    PARTITION pmax  VALUES LESS THAN MAXVALUE
);

4つの種類
- RANGE — 順序付けできる値の区間ごと。ほとんどの場合は日付です。最も役に立ちます。
- LIST — 離散的な値の集合に属するかどうか。
- HASH — 整数式による均等な分散。書き込みを分散させるには良いですが、プルーニングには向きません。
- KEY — HASHと似ていますが、サーバ内部の関数を使います。整数以外の列も受け付けます。

RANGE COLUMNSとLIST COLUMNSという派生形は、関数で包まずに複数の列や整数以外の型を受け付けます：

PARTITION BY LIST (region_id) (
    PARTITION europa VALUES IN (1, 2, 3),
    PARTITION asia   VALUES IN (4, 5)
);

PARTITION BY HASH (cliente_id) PARTITIONS 8;

PARTITION BY KEY (uuid) PARTITIONS 4;

PARTITION BY RANGE COLUMNS (pais, alta) (
    PARTITION p_es_2024 VALUES LESS THAN ('ES', '2025-01-01')
);

パーティションプルーニング
本当の利点です。WHEREがパーティション分割の列で絞り込んでいれば、サーバは結果を含みうるパーティションだけを読みます。EXPLAINのpartitions列で確認します。すべてのパーティションが表示されるなら、何もプルーニングしておらず、パーティション分割はコストになっているだけです。

EXPLAIN SELECT COUNT(*) FROM eventos
WHERE ocurrido BETWEEN '2025-03-01' AND '2025-03-31';

SELECT partition_name, table_rows
FROM information_schema.PARTITIONS
WHERE table_name = 'eventos';

最初に知っておくべき制限
1. パーティション分割のキーは、すべての一意キーに含まれていなければなりません。主キーも含みます。だから例ではidだけではなくPRIMARY KEY (id, ocurrido)としています。
2. 外部キーは使えません。パーティション分割したテーブルは、FOREIGN KEYを持つことも参照されることもできません。
3. テーブルあたり最大8192パーティションで、それぞれがファイルディスクリプタを消費します。
4. キーで絞り込まないクエリーはすべてのパーティションに触れ、パーティション分割しない場合より遅くなります。
5. インデックスは各パーティションにローカルです。グローバルなインデックスはありません。

メンテナンス
次の期間のパーティションを追加し、最も古いものを削除するのが通常の作業です。DROP PARTITIONは実質的に一瞬で終わり、本当に領域を解放します。大量のDELETEではそうはなりません：

ALTER TABLE eventos DROP PARTITION p2023;

ALTER TABLE eventos REORGANIZE PARTITION pmax INTO (
    PARTITION p2026 VALUES LESS THAN (2027),
    PARTITION pmax  VALUES LESS THAN MAXVALUE
);

ALTER TABLE eventos REBUILD PARTITION p2025;

推奨事項
日付でパーティション分割するのは、日付でパージするときだけにし、将来のパーティションは前もって作成します（またはスケジュールしたイベントで）。どの範囲にも収まらない行が届くと、INSERTは失敗します。安全網として、常にpmaxを残しておきます。

キーワード： パーティション分割、パーティション、RANGE、LIST、HASH、KEY、プルーニング、DROP PARTITION、REORGANIZE、information_schema.partitions、パージ

WITH、WITH RECURSIVE、OVER ()：入れ子のサブクエリーや一時テーブルを使わずに済む、モダンなSQL。

対象： MySQL 8.0+ MariaDB 10.2+ Aurora 3+ PostgreSQL 13+ SQLite 3.35+ SQL Server 2022+

CTE（WITH）とウィンドウ関数（OVER ()）は、MySQL 8.0とMariaDB 10.2で導入されました。PostgreSQLには、これらのないサポート中のバージョンはなく、SQLiteではどちらもこのハンドブックの最低バージョンよりずっと前からあります（CTEは3.8.3から、ウィンドウは3.25から）。以前は入れ子のサブクエリー、一時テーブル、セッション変数が必要だったことを、読みやすい1つのクエリーで解決できます。

CTE：途中の段階に名前を付ける
CTEは、クエリーの実行中だけ存在する名前付きの結果です。長いクエリーを段階に分け、同じ途中結果を繰り返し書かずに2回参照できます：

WITH ventas_mes AS (
    SELECT vendedor_id, DATE_FORMAT(fecha, '%Y-%m') AS mes, SUM(total) AS total
    FROM pedidos
    GROUP BY vendedor_id, mes
)
SELECT * FROM ventas_mes WHERE total > 10000;

WITH ventas_mes AS (
    SELECT vendedor_id, date_trunc('month', fecha) AS mes, SUM(total) AS total
    FROM pedidos
    GROUP BY vendedor_id, mes
)
SELECT * FROM ventas_mes WHERE total > 10000;

WITH ventas_mes AS (
    SELECT vendedor_id, strftime('%Y-%m', fecha) AS mes, SUM(total) AS total
    FROM pedidos
    GROUP BY vendedor_id, mes
)
SELECT * FROM ventas_mes WHERE total > 10000;

WITH ventas_mes AS (
    SELECT vendedor_id, DATETRUNC(month, fecha) AS mes, SUM(total) AS total
    FROM pedidos
    GROUP BY vendedor_id, DATETRUNC(month, fecha)
)
SELECT * FROM ventas_mes WHERE total > 10000;

再帰CTE：階層
WITH RECURSIVEは、組織図、入れ子のカテゴリー、部品表といった木構造を、アプリケーション側でループを書かずにたどります。最初の部分が基本ケースで、2つ目の部分は行を返さなくなるまで繰り返されます：

WITH RECURSIVE arbol AS (
    SELECT id, nombre, jefe_id, 1 AS nivel
    FROM empleados
    WHERE jefe_id IS NULL

    UNION ALL

    SELECT e.id, e.nombre, e.jefe_id, a.nivel + 1
    FROM empleados e
    JOIN arbol a ON e.jefe_id = a.id
)
SELECT * FROM arbol ORDER BY nivel, nombre;

ウィンドウ関数：グループ化せずに計算する
GROUP BYは行をまとめてしまいますが、ウィンドウ関数は関連する行の集合に対して計算し、すべての行を残します。そのおかげで、累計、移動平均、グループ内での順位を1回の処理で求められます：

SELECT
    vendedor_id,
    fecha,
    total,
    SUM(total)    OVER (PARTITION BY vendedor_id ORDER BY fecha) AS acumulado,
    AVG(total)    OVER (PARTITION BY vendedor_id
                        ORDER BY fecha
                        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS media_7,
    RANK()        OVER (PARTITION BY vendedor_id ORDER BY total DESC) AS puesto,
    LAG(total, 1) OVER (PARTITION BY vendedor_id ORDER BY fecha) AS anterior
FROM pedidos;

よく使うもの
- ROW_NUMBER()：パーティション内の通し番号。同順位はありません。
- RANK() / DENSE_RANK()：同順位のある順位。RANKは番号を飛ばし、DENSE_RANKは飛ばしません。
- LAG() / LEAD()：前または次の行の値。自己結合は要りません。
- FIRST_VALUE() / LAST_VALUE()：ウィンドウの両端。
- NTILE(n)：行をn個のグループに分けます。四分位数や百分位数に。
- OVER付きの集計：SUM、AVG、COUNT、MIN、MAXを、行をまとめずに。

フレーム（ROWS BETWEEN ...）は、各行の計算にどの行を含めるかを決めます。デフォルトでは、ORDER BY付きの集計はパーティションの先頭から現在の行までを対象にします。まさにこれが累計になります。

最も役に立つパターン：グループごとの上位N件
カテゴリーごとに売れ筋の製品を3つ取り出すには、ウィンドウを使わないと行ごとに相関サブクエリーが必要です。ROW_NUMBER()を使えば素直に書けます：

WITH ranking AS (
    SELECT
        p.*,
        ROW_NUMBER() OVER (PARTITION BY categoria_id ORDER BY ventas DESC) AS rn
    FROM productos p
)
SELECT * FROM ranking WHERE rn <= 3;

パフォーマンス
どちらもただではありません。ウィンドウはパーティションごとに並べ替える必要があるので、PARTITION BYとORDER BYの順序ですでに行を返すインデックスがあれば、その並べ替えを省けます。見た目のよい書き方に落ち着く前に、EXPLAINで確かめてください。

推奨事項
クエリーを読みやすくするためにCTEを使い、サーバが1回の処理でできることをアプリケーションでやらずに済むようにウィンドウ関数を使ってください。サーバがMySQL 5.7やMariaDB 10.1なら、どちらも使えません。そこでは今もサブクエリーが主役です。

キーワード： CTE、WITH、WITH RECURSIVE、ウィンドウ関数、OVER、PARTITION BY、ROW_NUMBER、RANK、DENSE_RANK、LAG、LEAD、NTILE、フレーム、階層、グループごとの上位N件

1つのエラーがトランザクション全体を止める理由、セーブポイントで抜け出す方法、各レベルが実際にすること、そしてロールバックされるDDL。

対象： PostgreSQL 13+

トランザクションは、複数の文を、すべて適用されるか、まったく適用されないかの単位にまとめます。明示的なBEGINがなければ、PostgreSQLは各文を個別にコミットします。

MySQLから来ると最初に驚くこと
エラーはトランザクション全体を中断させます。それ以降は、ROLLBACKするまで、どの文も同じ応答を返します：current transaction is aborted, commands ignored until end of transaction block、SQLSTATE 25P02。これはアプリケーションのバグではなく設計で、思っていたのとはもう違う状態のままトランザクションが進むのを防ぎます。

抜け道はセーブポイントです
SAVEPOINTは戻るための地点を記録し、ROLLBACK TO SAVEPOINTは、それより前の作業を失わずにトランザクションを救います：

BEGIN;
INSERT INTO cuentas (id, saldo) VALUES (3, 0);
SAVEPOINT tras_alta;
INSERT INTO cuentas (id, saldo) VALUES (3, 0);  -- 失敗：23505
ROLLBACK TO SAVEPOINT tras_alta;
COMMIT;

DDLもロールバックされます
CREATE、ALTER、DROPはトランザクションの中で実行されます。ここには暗黙のコミットはありません。移行が途中で失敗しても、作りかけのテーブルが残ることはありません。

BEGIN;
ALTER TABLE cuentas ADD COLUMN moneda text;
ROLLBACK;   -- この列は存在しなかったことになる

4つのレベル

READ UNCOMMITTEDは受け付けられ、そのとおりに報告されますが、READ COMMITTEDと同じように動作します：PostgreSQLには、どのレベルでもダーティリードがありません。デフォルトはREAD COMMITTEDです。

REPEATABLE READとSERIALIZABLEはブロックせず、中断します
直列化できないトランザクションは、待つ代わりにSQLSTATE 40001（could not serialize access…）で終わります。つまり、アプリケーションが再試行する必要があります：この2つのレベルでは、40001は失敗ではなく通常の動作です。SERIALIZABLEはSSIを使い、読み書きの依存関係を検出し、追加のロックは取りません。

ロックとデッドロック
デッドロックはdeadlock_timeout（デフォルトは1秒）のあとに検出され、サーバは2つのうち一方をSQLSTATE 40P01で終了させます。待たないようにするには、あるいは作業を複数のコンシューマに分けるには：

SELECT id FROM cuentas ORDER BY id FOR UPDATE SKIP LOCKED;

FOR UPDATE NOWAITは、待つ代わりにすぐに55P03で失敗します。注意：その失敗もトランザクションを中断させます。

長いトランザクション
ここでは、開いたままのトランザクションはUNDOログを増やしません。代わりにサーバ全体で、VACUUMが不要になった行バージョンを片付けるのを妨げ、テーブルは新しい行がなくても大きくなります。次のように見つけます：

SELECT pid, state, xact_start, now() - xact_start AS duracion, query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_start;

idle_in_transaction_session_timeoutはデフォルトで0、つまり無制限です。これを設定しておくことが、忘れられたセッションがデータベース全体を劣化させるのを防ぐ安全網になります。

推奨事項
トランザクションは短く保ち、ビジネスロジックはその外に置きます。REPEATABLE READやSERIALIZABLEに上げるなら、本番で最初の40001が出てからではなく、上げる前に再試行の処理を書いてください。

キーワード： トランザクション、COMMIT、ROLLBACK、SAVEPOINT、分離、MVCC、READ COMMITTED、REPEATABLE READ、SERIALIZABLE、SSI、25P02、40001、40P01、デッドロック、SKIP LOCKED、pg_stat_activity

新しい行がないのにテーブルが大きくなる理由、各操作が実際に片付けるもの、カウンタが当てにならないとき、そしてトランザクションIDの周回とは何か。

対象： PostgreSQL 13+

PostgreSQLでは、行を更新してもその行は変更されません：新しいバージョンを書き込み、古いものを不要な行として残します。削除しても、すぐには何も解放されません。これがここでのMVCCの仕組みで、あとで回収するのがVACUUMです。InnoDBには相当するものがなく、容量に関する驚きのほとんどはこれが原因です。

どう見えるか
50,000行のテーブルが12 MBでした。全行に対する1回のUPDATEで、1行も増えないまま23 MBになりました：50,000個の古いバージョンがまだファイルに残っているのです。PostgreSQL 17.6で測定しました。

それぞれが何をするか
- VACUUMは不要な領域を再利用可能としてマークします。オペレーティングシステムに容量を返しはしません：VACUUMのあとも例のテーブルは23 MBのままで、次の書き込みがその中に収まるようになっただけです。
- VACUUM FULLはテーブル全体を書き直し、容量を返します（11 MBまで減りました）。ただしACCESS EXCLUSIVEロックを取ります：実行中は誰も読み書きできず、完全なコピーのための領域も必要です。日常のメンテナンスではなく、最後の手段です。
- ANALYZEは何も片付けません：プランナの統計情報を更新します。

autovacuumは最初からオンです
autovacuumはonで出荷されています。不要な行がautovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor × rowsを超えると、テーブルがキューに入ります。デフォルト値では「50 + 20 %」です。1,000万行のテーブルなら、何かが動き出すまでに200万行の不要な行が必要になるので、大きくて更新の多いテーブルでは、テーブルごとに係数を下げます：

ALTER TABLE pedidos SET (autovacuum_vacuum_scale_factor = 0.02);

動いているかを確かめる

SELECT relname, n_live_tup, n_dead_tup, last_autovacuum, autovacuum_count
FROM pg_stat_user_tables
WHERE n_dead_tup > 0
ORDER BY n_dead_tup DESC
LIMIT 10;

このカウンタには注意してください：推定値で、即時ではありません。17.6で測定したところ、50,000行を更新した直後はまだ0でした。ANALYZEのあとでようやく50,000になり、VACUUMのあとで0に戻りました。大量に書き込んだ直後に数値が動かなくても、保留中の作業がないという意味ではありません。

実行中のVACUUMは次のように追跡します：

SELECT pid, relid::regclass AS tabla, phase, heap_blks_scanned, heap_blks_total
FROM pg_stat_progress_vacuum;

敵は開いたままのトランザクション
VACUUMが片付けられるのは、もう誰からも見えないものだけです。開いたままのトランザクション（またはhot_standby_feedbackを使うレプリカ）はその境界を止めてしまい、そうなるとVACUUMは実行されて成功を報告しても、何も解放しません。だからこそ、idle in transactionのまま忘れられた1つのセッションが、触れてもいないテーブルを大きくするのです。

トランザクションIDの周回は本当の緊急事態です
トランザクションIDは32ビットで、再利用されます。どの行も未来に置かれることがないように、VACUUMは古いものを凍結します。autovacuum_freeze_max_ageはデフォルトで200,000,000です：その年齢を超えると、サーバは延期できないautovacuumを起動し、それでも追いつかなくなると、書き込みの受け付けを止めます。次のように監視します：

SELECT datname, age(datfrozenxid) AS edad
FROM pg_database
ORDER BY edad DESC;

その年齢が2億を大きく下回っているあいだは、何もする必要はありません。

推奨事項
autovacuumを無効にしないでください。新しい行がないのにテーブルが大きくなるなら、次の順に疑います：開いたままのトランザクション、サイズに対して高すぎるscale_factor、そして最後にVACUUM FULL。最後のものはテーブル全体をロックするので、メンテナンスの時間枠を取って行います。

キーワード： VACUUM、autovacuum、肥大化、MVCC、n_dead_tup、VACUUM FULL、FREEZE、周回、pg_stat_user_tables、pg_stat_progress_vacuum、DATFROZENXID、hot_standby_feedback、IDLE IN TRANSACTION

各文が実際に何をロックするか、なぜALTER TABLEがあなたのSELECTを止めることがあるのか、誰が誰を待っているかを見る方法、そして40P01をどうするか。

対象： PostgreSQL 13+

PostgreSQLでは、ロックは2つの異なる場所にあり、それを取り違えると問題が見つからなくなります。テーブルのロックはpg_locksにあります。行のロックは行そのもの、そのヘッダの中にあるので、メモリーを使わず、テーブルロックに昇格することもなく、pg_locksにも現れません。100万行をロックしても、1行と同じコストです。

そして、例外のないルールが1つあります：ただのSELECTが行を待つことはありません。MVCCによって自分のバージョンを読みます。SELECTを止められるのはテーブルロックだけです。

どの文がどのテーブルモードを取るか

最初の3つは互いに邪魔をしないので、通常の負荷ではブロックが起きません。最後のものはSELECTも含めてすべてと競合します。

落とし穴：待っているALTER TABLEは後ろのすべてを並ばせる
そのACCESS EXCLUSIVEは列に割り込みません：列に並びます。そして待っている間、あとから来たものはすべてその後ろで待ちます。前にある文とは何の問題もなかったはずのSELECTでさえもです。SELECTを実行しただけの開いたトランザクションが1つあれば、ALTER TABLEは何の作業も始めないまま、全員に対してテーブルを凍らせてしまいます。だから本番環境のDDLは上限を付けて発行し、再試行します：

SET lock_timeout = '3s';
ALTER TABLE cuentas ADD COLUMN moneda text;

行のモードは2つではなく4つ
強いものから弱いものへ：FOR UPDATE、FOR NO KEY UPDATE、FOR SHARE、FOR KEY SHARE。共存できるのは3組だけです（共有の2つどうしと、FOR NO KEY UPDATEとFOR KEY SHARE）。FOR UPDATEは4つすべてと競合します。大事なのはその変わった組み合わせです：キーに触れないUPDATEはFOR NO KEY UPDATEを取るので、その行を指す外部キーの検査をブロックしません。その検査が求めるのがFOR KEY SHAREです。

BEGIN;
SELECT saldo FROM cuentas WHERE id = 1 FOR UPDATE;
UPDATE cuentas SET saldo = saldo - 100 WHERE id = 1;
COMMIT;

ここでは待ち時間は無限
lock_timeoutはデフォルトで0、つまり上限なしです。50秒で打ち切るMySQLのinnodb_lock_wait_timeoutに相当するものはありません。セッションごとに危険な文の前で、あるいは設定で、これを設定することが、終わらない待ちをアプリケーションが再試行できるエラーに変えます。発動するとSQLSTATEは55P03です。

わざと待たない

SELECT id FROM cuentas WHERE id = 3 FOR UPDATE NOWAIT;

SELECT id FROM cuentas ORDER BY id FOR UPDATE SKIP LOCKED;

NOWAITはすぐに55P03で失敗します（そしてその失敗は、ほかの失敗と同じくトランザクション全体を中断させます）。SKIP LOCKEDは失敗しません：返す行が減ります。3行目を別のセッションがロックしているとき、2つ目のクエリーは1、2、4、5を返しました。これが、作業キューを複数のコンシューマで衝突も待ちもなく分け合う方法です。

デッドロック

-- セッションA
BEGIN;
UPDATE cuentas SET saldo = saldo - 10 WHERE id = 1;
UPDATE cuentas SET saldo = saldo + 10 WHERE id = 2;

-- セッションB
BEGIN;
UPDATE cuentas SET saldo = saldo - 10 WHERE id = 2;
UPDATE cuentas SET saldo = saldo + 10 WHERE id = 1;

サーバは2つのうち一方をSQLSTATE 40P01（deadlock detected）で終了させ、詳細にはどのプロセスとどの行かが書かれます。ただし、すぐには検出しません：待ちがdeadlock_timeout（デフォルトで1秒）を超えてはじめて循環を探すので、犠牲になる側が終わるまでその1秒がかかります。InnoDBはすぐに検出します。ここではデッドロックは1秒の待ちのコストがかかります。deadlock_timeoutを下げるのはただではありません：その作業は大多数を占める通常の待ちにも費やされるからです。

40P01はサーバの故障ではありません：正しい動作であり、アプリケーションはそのトランザクションを再試行しなければなりません。

診断
ここにはSHOW ENGINE INNODB STATUSはありません。クエリーが2つあり、どちらもロックが続いている間に実行する必要があります：

SELECT pid, pg_blocking_pids(pid) AS bloqueado_por,
       wait_event_type, wait_event, left(query, 40) AS consulta
  FROM pg_stat_activity
 WHERE cardinality(pg_blocking_pids(pid)) > 0;

SELECT l.pid, c.relname, l.locktype, l.mode, l.granted
  FROM pg_locks l LEFT JOIN pg_class c ON c.oid = l.relation
 WHERE NOT l.granted;

pg_blocking_pidsは、もう一方が求めているものを持っているプロセスの一覧を返します。それがあなたが本当に知りたいことです。pg_locksで見えないのは行のロックです：行を待っている側はtransactionid、つまりその行を持っているトランザクションの番号を待っているように表示されます。そして、すでに起きたことの痕跡を残すには、log_lock_waitsがdeadlock_timeoutより長い待ちをすべてサーバのログに書きます。

Calíopeの「プロセス」は、その待ちを状態の列に表示します：ブロックされたセッションはLock: transactionidと表示されます。

アドバイザリーロック
テーブルもデータもありません：アプリケーションの2つのプロセスが同じことを同時にしないよう、サーバがあなたのために保持する番号です。

SELECT pg_try_advisory_lock(42);
SELECT pg_advisory_unlock(42);

あるセッションが42を持っている間、別のセッションからのpg_try_advisory_lock(42)は待たずにfalseを返します。スコープに注意してください：セッションレベルのものは「COMMITのあとも残り」、解放するか接続を閉じるまで解放されません。pg_advisory_xact_lockはトランザクションが終わると自動で解放されます。ほとんどの場合、欲しいのはこちらです。

SERIALIZABLEはブロックしない
このレベルではpg_locksにSIReadLockロックが現れます。これは誰もブロックしません：トランザクションが読んだものの印であり、競合は待ちとしてではなく、コミット時の40001として届きます。

推奨事項
どのエンジンでも同じく、行には常に同じ順序で触れ、トランザクションは短く保ってください。ここに特有なのは2つです：DDLの前には必ずlock_timeoutを設定すること（待っている側が全員を後ろに並ばせるため）、そして本番環境に出す前に再試行を書いておくこと。40P01を無害にするのはそれだけです。

キーワード： ロック、デッドロック、40P01、55P03、pg_locks、pg_blocking_pids、lock_timeout、deadlock_timeout、ACCESS EXCLUSIVE、FOR UPDATE、FOR KEY SHARE、SKIP LOCKED、NOWAIT、アドバイザリーロック

6つのインデックス方式とそれぞれが合う場面、部分インデックスと式インデックス、Index Only Scanがそれでもテーブルを読みに行くことがある理由、そして誰も使っていないインデックスの見つけ方。

対象： PostgreSQL 13+

インデックスは、容量と書き込みのたびの作業を代償に検索を速くします。MySQLから来て変わるのはその考え方ではなく、ここでは例外付きの1つではなく6つの方式があること、そしてMySQLでインデックスのオプションだったもののほとんど（プレフィックス、不可視）が、ここでは別のものだということです。

6つの方式

選び方は、理論よりサイズのほうがよく説明します。200,000行、22 MBのテーブルで、挿入とともに増えるタイムスタンプについて：

- その列のBツリー：4,408 kB。
- まったく同じ列のBRIN：24 kB。

BRINは行を保存せず、各ブロックの最小値と最大値を保存します。だから物理的な順序が値の順序に似ているときにしか役立ちません。そして似ているときは、ほとんどコストがかかりません。同じテーブルで、顧客の列のハッシュインデックスは7,032 kB、その列のBツリーは1,400 kBでした：より小さく、しかも範囲とソートにも使えます。だからBツリーがデフォルトの答えで、ハッシュは特定の場合のものです。

部分インデックス：考え方は半分、サイズは10分の1
インデックスはWHEREを持つことができ、そのときは一致する行だけをインデックスします。保留中のキューを問い合わせていて、保留中が5 %なら、その5 %をインデックスします：

CREATE INDEX idx_pendientes ON pedidos (cliente_id) WHERE estado = 'pendiente';

同じテーブルで測定すると、列の完全なインデックスは1,400 kB、部分インデックスは88 kBでした。クエリーのWHEREはインデックスのWHEREを含意していなければならず、そうでなければプランナは使いません。

ここにはプレフィックスインデックスはない：代わりに式インデックス
CREATE INDEX … ON paginas (url(64))は有効な構文ではありません。サーバはurl(64)を関数呼び出しと読み、42883 function url(integer) does not existと答えます。同等のものは式をインデックスすることです：

CREATE INDEX idx_url ON paginas (left(url, 64));
CREATE INDEX idx_email ON usuarios (lower(email));

そして細かい注意点：インデックスが効くのは、クエリーが式を同じように書いたときだけです。WHERE lower(email) = 'ana@ejemplo.com'は使いますが、WHERE email ILIKE 'Ana@%'は使わず、テーブル全体を読みます。

カバリングインデックスと、カバーしないことがある理由
INCLUDEは、インデックスに保存されるがソートには使われない列を加えます：

CREATE INDEX idx_cobertura ON pedidos (cliente_id) INCLUDE (estado);

これでEXPLAINはIndex Only Scanを表示します。しかし「だけ」というのは半分の約束です：PostgreSQLはインデックスから行があなたのトランザクションに見えるかどうかを判断できないので、VACUUMが保守する可視性マップを参照します。測定結果：1,000行を更新した直後、同じプランはHeap Fetches: 2と表示し、VACUUMのあとはHeap Fetches: 0でした。書き込まれて掃除されないテーブルのカバリングインデックスは、それでもテーブルを読みに行きます。

左端プレフィックスのルールは厳密ではない
MySQLでは、(A, B)のインデックスはWHERE B = ?には役に立ちません。ここでは役立つことがあります：測定すると、2番目の列だけで絞り込むクエリーが、複合インデックスに対するIndex Only Scanで解決されました。魔法でも正しいインデックスの代わりでもありません（インデックスを下るのではなく全体をたどります）が、インデックスがテーブルよりずっと小さければ、それでも得になります。実際的な結論：「足りない」インデックスを作る前にプランを見てください。すでに使われているものがあるかもしれません。

フィールドの中にあるものにはGIN

CREATE INDEX idx_datos ON eventos USING gin (datos);

SELECT count(*) FROM eventos WHERE datos @> '{"tags":["t7"]}';

インデックスがなければそのクエリーはシーケンシャルスキャンで、あればBitmap Index Scanです。テストのGINは200,000行で864 kBでした。jsonbで@>でしか問い合わせないなら、jsonb_path_opsのほうが小さく済みます：同じデータで、通常のGINの864に対して640 kBです。

テーブルを止めずに作る
通常のCREATE INDEXはSHAREロックを取ります：読み取りは許しますが、書き込みを止めます。CREATE INDEX CONCURRENTLYはSHARE UPDATE EXCLUSIVEを取るので何も止めません。その代わりにテーブルを2回走査し、3つのルールがあります：

CREATE INDEX CONCURRENTLY idx_pedidos_cliente ON pedidos (cliente_id);

-- 作りかけのまま残ったものはないか
SELECT indexrelid::regclass AS indice, indisvalid
  FROM pg_index WHERE NOT indisvalid;

1. トランザクションの中では実行できません：25001 CREATE INDEX CONCURRENTLY cannot run inside a transaction block。
2. 失敗すると無効なインデックスが残ります：誰も使いませんが、書き込みのたびに保守されます。上のクエリーで見つけて削除する必要があります。
3. PostgreSQL 12からはREINDEX INDEX CONCURRENTLYがあり、肥大化したインデックスをテーブルを止めずに再構築する方法です。

誰も使っていないインデックス

SELECT relname AS tabla, indexrelname AS indice, idx_scan,
       pg_size_pretty(pg_relation_size(indexrelid)) AS tamano
  FROM pg_stat_user_indexes
 WHERE idx_scan = 0
 ORDER BY pg_relation_size(indexrelid) DESC;

削除する前に2つの注意があります。1つ目：カウンタは即時ではありません。テストでは、インデックスを使ったクエリー3回のあと、直後も1秒後も0のままで、3秒後にようやく3になりました。2つ目：最後のpg_stat_reset()からの数であり、レプリカではレプリカ自身の作業を数えます。だから月末のレポートだけが使うインデックスは、ほかの29日間は使われていないように見えます。

推奨事項
余分なインデックスは、すべてのINSERTと、その列のすべてのUPDATEで代償を払います。うまくいく順序は、プランを見る、CONCURRENTLYでインデックスを作る、もう一度プランを見る、1か月後にpg_stat_user_indexesを確認する、です。誰も使わないインデックスは中立ではありません：書き込み、容量、VACUUMの時間のコストがかかります。

キーワード： インデックス、BTREE、BRIN、GIN、GIST、SPGIST、HASH、部分インデックス、式インデックス、INCLUDE、INDEX ONLY SCAN、HEAP FETCHES、CONCURRENTLY、REINDEX、pg_stat_user_indexes、INDISVALID、jsonb_path_ops、可視性マップ

プランを読んで見積もりと測定値を比べること、互いを含意する列のための拡張統計情報、work_memが操作ごとである理由、そしてキャッシュヒット率が本当に測っているもの。

対象： PostgreSQL 13+

ここで診断するとは、プランを読んで2つの数字を比べることです。それ以外のすべて（インデックス、メモリー、統計情報）は、その比較から導かれます。

EXPLAINは実行しない。EXPLAIN ANALYZEは実行する
1つ目の形はプランを求めるだけです。2つ目は測定するために本当にクエリーを実行します。UPDATEやDELETEも含めてです。文が書き込むなら、包んでください：

BEGIN;
EXPLAIN (ANALYZE) DELETE FROM pedidos WHERE creado < '2020-01-01';
ROLLBACK;

大事な2つの数字
どのノードにも見積もりと測定値があります：rows=…はプランナが信じたもの、actual rows=…は実際に出たものです。この2つが大きく離れているとき、悪いプランは原因ではなく結果です。

互いを含意する2つの列（市と県）で測定した例：

- 補助なしでは、プランナは11,710行と見積もり、実際には60,000行出ました：2つの確率を独立しているかのように掛け合わせたのです。
- 拡張統計情報があると、見積もりは59,610になりました。

CREATE STATISTICS st_ciudad_prov (dependencies, ndistinct)
    ON ciudad, provincia FROM pedidos;
ANALYZE pedidos;

これはMySQLにはない道具で、「プランが私のインデックスを無視する」という類いの問題全体を解決します：テーブルの20 %を読むのにサーバが4 %だと思っていれば、もっともな理由で悪い選択をします。

頼まないと出ないBUFFERS

EXPLAIN (ANALYZE, BUFFERS) SELECT … ;

shared hitはメモリーにあったブロック、shared readは取りに行かなければならなかったブロックです。そしてtemp read/writtenが決め手です：クエリーがディスクにあふれたということです。また、track_io_timingはデフォルトでオフなので、オンにするまでI/Oの時間は表示されません。

work_memは接続ごとではなく操作ごと
これは最も驚かれ、最も間違えられる設定です。ソート、ハッシュ結合、ハッシュ集計のそれぞれがwork_memまで使うことができ、そうした操作を3つ含む（あるいは並列ワーカーが2つある）クエリーはその倍数を使います。出荷時の値は4 MBです。

300,000行で、ORDER BY付きの同じクエリーを測定すると：

- work_mem = 64kBでは：Sort Method: external merge Disk: 15680kBで、ソートのノードは約144 msかかりました。
- work_mem = 64MBでは：Sort Method: quicksort Memory: 29627kBで、約70 msでした。

本当のことを言う数字はSort Methodです。work_memを全体で上げると接続数と操作数で掛け算になります。慎重なやり方は、それが必要なセッションで上げることです：

SET work_mem = '64MB';

どのクエリーが最もコストがかかるか：pg_stat_statements
スロークエリーログに相当するものですが、集計されています：クエリーの形ごとに1行で、呼び出し回数、合計時間、行数があります。
Calíopeでは、クエリーを書かずに同じものを読めます：「スロークエリー」ツールがこの概要を表示し、拡張機能がないのか、ライブラリが読み込まれていないのかを区別し、どの行もエディタに送れます。

SELECT calls, round(total_exec_time::numeric, 1) AS ms_total,
       round(mean_exec_time::numeric, 2) AS ms_media, rows, query
  FROM pg_stat_statements
 ORDER BY total_exec_time DESC
 LIMIT 20;

細かい注意点：CREATE EXTENSIONだけでは足りません。shared_preload_librariesに加えてサーバを再起動する必要があります。拡張機能を作成しただけだと、最初のクエリーは55000 pg_stat_statements must be loaded via "shared_preload_libraries"と答えます。mean_exec_timeではなくtotal_exec_timeでソートしてください：午後を食いつぶすクエリーは、たいてい100万回実行される速いクエリーです。

キャッシュヒット率

SELECT blks_hit, blks_read,
       round(100.0 * blks_hit / nullif(blks_hit + blks_read, 0), 2) AS pct
  FROM pg_stat_database
 WHERE datname = current_database();

これは、Calíopeの「ダッシュボード」が「データキャッシュ」として表示する数字です。最後に統計情報がリセットされてから、ファイルシステムまで降りずに済んだ読み取りがどれだけあったかを測るもので、使用中のメモリーの量ではありません。小さなデータベースでは、定義上とても高く出ます：テストでは99.85 %でした。低い値が続くなら、shared_buffersが小さすぎるということです。高い値は、すべてが順調だという証明にはなりません。

並列処理
max_parallel_workers_per_gatherはデフォルトで2で、プランナがそれを使うとGatherやGather Mergeのノードが現れます。各ワーカーはそれぞれのwork_memを持ちます。これが上の落とし穴のもう半分です。

推奨事項
うまくいく順序：pg_stat_statementsでクエリーを見つけ、EXPLAIN (ANALYZE, BUFFERS)で見て、rowsとactual rowsを比べ、そのうえで足りないのがインデックスなのか、統計情報なのか、メモリーなのかを決めます。プランを読む前にshared_buffersをいじるのは遠回りです。

キーワード： パフォーマンス、EXPLAIN、ANALYZE、BUFFERS、プラン、プランナ、見積もり、CREATE STATISTICS、拡張統計情報、work_mem、SORT METHOD、EXTERNAL MERGE、pg_stat_statements、shared_preload_libraries、pg_stat_database、キャッシュ、track_io_timing、並列処理

各パラメータがどこに書かれ、どれが優先されるか、何に再起動が必要か、effective_cache_sizeがメモリーを確保しない理由、そしてmax_connectionsを上げるべきではない理由。

対象： PostgreSQL 13+

PostgreSQLには378個のパラメータがあります（このサーバで数えました）が、よい知らせは、触るのはほんの一握りだということです。最初に学ぶべきなのは、どれを触るかではなく、どこに書かれ、いつ反映されるかです。

4つの場所があり、どれが勝ったかはサーバが教えてくれます
- postgresql.conf：通常のファイルで、手で編集します。
- postgresql.auto.conf：ALTER SYSTEMが書き込み、手では編集しません。そのことはファイル自身の1行目に書かれています。
- データベースごと、またはロールごと：ALTER DATABASE … SET、ALTER ROLE … SET。
- セッションごと：SET。接続が続くあいだ有効です。

どれが勝ったかは推測ではありません：pg_settingsのsource列が教えてくれます。測定結果：ALTER DATABASE demo SET work_mem = '32MB'のあと、新しい接続はsource = databaseで32MBを読みました。RESETのあとは、source = defaultで4MBでした。

SELECT name, setting, unit, context, source, pending_restart
  FROM pg_settings
 WHERE name IN ('shared_buffers','work_mem','max_connections','max_wal_size');

パラメータの3つのクラスと、痛い目にあうもの
context列が、変更に何が必要かを示します：
- user / superuser：セッションでのSETで足ります（work_mem、effective_cache_size）。
- sighup：再読み込みが必要です（checkpoint_timeout、max_wal_size、autovacuumのほぼすべて）。
- postmaster：サーバの再起動が必要です。このサーバでは378個中65個で、その中にshared_buffers、max_connections、wal_level、shared_preload_libraries、autovacuum_max_workersがあります。

ALTER SYSTEM SET max_wal_size = '4GB';
SELECT pg_reload_conf();

-- 再起動を待っているものはあるか
SELECT name, setting FROM pg_settings WHERE pending_restart;

驚かずに済む、測定した細部：pending_restartは、再読み込みのその瞬間には点きません。直後はまだfalseで、0.5秒後にtrueになりました。同じ流れの中ではなく、あとで問い合わせてください。

shared_buffersとeffective_cache_sizeは同じではなく、一方は何も確保しません
- shared_buffersは実際のメモリーで、サーバ自身のキャッシュです。初期値は128 MBで、専用のサーバには少なすぎます。一般的な目安はRAMの25 %です。
- effective_cache_sizeは何も確保しません。PostgreSQLのキャッシュとオペレーティングシステムのキャッシュのあいだにあるとプランナが想定する量で、インデックスが割に合うかどうかの判断にだけ使われます。変えてもメモリーは1バイトも動かず、変わるのはプランです。

両者を取り違えると、キャッシュが増えると思ってeffective_cache_sizeを上げたり、プランが変わると思ってshared_buffersを上げたりすることになります。

max_connectionsは上げずに、前にプールを置きます
初期値は100で、ここでは各接続はスレッドではなく、オペレーティングシステムのプロセスです。1,000に上げるのは、数を大きくすることではありません：1,000個のプロセスと、そのメモリーと、操作ごとのwork_memです。答えはコネクションプーラ（PgBouncerなど）です。そして、これは再起動が必要なパラメータの1つです。

WALとチェックポイント
max_wal_size（初期値は1 GB）とcheckpoint_timeout（5分）が、すべてをディスクに書き出す頻度を決めます。チェックポイントが時間ではなくサイズで発生していると、サーバは集中的に書き込みます。log_checkpointsをオンにすると見え、max_wal_sizeを上げると直ります。checkpoint_completion_targetは最初から0.9で、これがその書き込みを集中させずに時間に分散させます。

autovacuum
ここではautovacuum_naptimeが60秒、autovacuum_max_workersが3（これは再起動が必要です）、autovacuum_vacuum_scale_factorが0.2、つまり行の20 %が変わるとテーブルが片付けられます。10億行のテーブルでは2億個の不要なバージョンを待つことになるので、大きなテーブルには専用の設定を持たせます：

ALTER TABLE eventos SET (autovacuum_vacuum_scale_factor = 0.01);

synchronous_commit：約束を変える唯一のパラメータ
オフにすると、COMMITはWALがディスクに届くのを待たなくなります。レイテンシが改善する代わりに、停電のときに最後のトランザクションを失う危険を負います（データベースの整合性ではなく、最新のコミットだけです）。これはuserなので、そのトレードオフを受け入れる場所でだけオフにできます：

SET synchronous_commit = off;

推奨事項
触るのは少なく、1つずつ、測りながら。ファイルを編集する代わりにALTER SYSTEMを使い（記録が残り、ALTER SYSTEM RESETで元に戻せます）、全体よりも先にデータベースごと、ロールごとに設定します。夜間のレポートにしか要らない設定の代償を、ほかの時間帯に払わせるべきではありません。

キーワード： 設定、postgresql.conf、postgresql.auto.conf、ALTER SYSTEM、pg_settings、pending_restart、pg_reload_conf、shared_buffers、effective_cache_size、work_mem、max_connections、プール、WAL、チェックポイント、autovacuum、synchronous_commit

アカウントにホストが含まれない理由、ユーザでもありグループでもあるロール、付与が明日のテーブルには届かないという罠、そして行レベルセキュリティがオンなのに効かないことがある理由。

対象： PostgreSQL 13+

MySQLとの根本的な違いは、ここではアカウントにホストが含まれないことです。ana@192.168.1.%はありません：あるのはロールanaで、どこから接続でき、どう認証するかは、別のファイルpg_hba.confが決めます。

pg_hba.conf：最初に一致した行が勝ちます
上から下へ読まれ、そこで止まります。そして、見るためにファイルを開く必要はありません：

SELECT type, database, user_name, address, auth_method, error
  FROM pg_hba_file_rules
 ORDER BY rule_number;

error列は、ある行の書き方が間違っているかどうかを教えてくれます（これが、サーバが戻ってこない再起動から救ってくれます）。変更はSELECT pg_reload_conf()で、再起動なしに反映されます。テスト用のサーバには7つのルールがあり、127.0.0.1のものはtrust、そのほかすべてに当たる最後のものはscram-sha-256でした：順序こそがポリシーです。

ロールはユーザであり、同時にグループです
2つの概念があるわけではありません：CREATE USERはCREATE ROLE … LOGINそのものです。人とグループを分けるのはLOGIN属性だけで、ほかには何もありません。

CREATE ROLE app_ro;                       -- LOGINなし：グループとして働く
CREATE ROLE ana LOGIN PASSWORD 'secreta';
GRANT app_ro TO ana;                      -- anaはapp_roの権限を継承する

ロールはデフォルトで継承するので、anaは何もしなくてもapp_roの権限を使えます。NOINHERITにすると、権限はSET ROLEで明示的に取得しなければなりません。手順を明示的にしたいときに使います。

パスワードはscram-sha-256で保存されます。PostgreSQL 14からのデフォルトで、テスト用のサーバでも確認できました。md5はまだありますが、使うべきではありません。

本当の罠：付与は未来には届きません
GRANT … ON ALL TABLES IN SCHEMAが権限を与えるのは、今日存在するテーブルです。測定結果：付与のあと、app_roは既存のテーブルは読めましたが、1分後に作成されたテーブルは読めませんでした。未来をカバーするのは別の文です：

GRANT USAGE ON SCHEMA public TO app_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_ro;          -- 今日のテーブル
ALTER DEFAULT PRIVILEGES IN SCHEMA public
      GRANT SELECT ON TABLES TO app_ro;                          -- 明日のテーブル

そして細かい注意：デフォルト権限は、スキーマではなくそれを宣言したロールのものです。そのため、テーブルを別のロールが作成するなら、FOR ROLEでも宣言する必要があります。宣言した内容はpg_default_aclに表示されます。

付与は、元に戻す必要のある痕跡も残します：ON ALL TABLESのあとでは、ロールの削除はDependentObjectsStillExistと、権限が残っているテーブルの一覧とともに失敗します（テストではPostGISのテーブルまで出てきました）。対になるのはREVOKE、またはDROP ROLEの前のDROP OWNED BY roleです。

publicスキーマは、もうみんなのものではありません
PostgreSQL 15から、PUBLICはスキーマpublicに対するUSAGEを持ち続けますが、CREATEはもう持っていません。17.6で測定：作成したばかりのロールではUSAGE = true、CREATE = falseになります。以前のバージョンのスクリプトを持ち込むと、以前はできていたユーザの最初のCREATE TABLEが失敗するのを目にすることになります。

定義済みロール：スーパーユーザなしで監視する
サーバには、すぐに使えるロールが15個付いています。余計なスーパーユーザを作らずに済むものは：
- pg_read_all_data、pg_write_all_data：すべてを読む、またはすべてに書く。それ以上の権限はありません。
- pg_monitor：統計情報のビューをすべて見られます。pg_read_all_statsとpg_read_all_settingsを含みます。
- pg_signal_backend：ほかの人のクエリーをキャンセルし、セッションを閉じます。
- pg_maintain（PostgreSQL 17以降）：所有者でなくてもVACUUM、ANALYZE、REINDEXを実行できます。

行レベルセキュリティ
ポリシーは、同じテーブルの中で、各ロールがどの行を見るかを絞り込みます：

ALTER TABLE pedidos ENABLE ROW LEVEL SECURITY;

CREATE POLICY solo_lo_mio ON pedidos
    FOR SELECT USING (dueno = current_user);

信頼する前に、測っておくべきことがあります。同じポリシーと同じテーブルで：

- ポリシーの対象のロールは1行を見ました。正しい結果です。
- テーブルの所有者（スーパーユーザではない）は両方を見ました：所有者は、ALTER TABLE … FORCE ROW LEVEL SECURITYを宣言するまで、自分のポリシーの対象になりません。FORCEを付けると、1行になりました。
- スーパーユーザは、FORCEがあっても両方を見ました。スーパーユーザと、BYPASSRLSを持つロールは、常にポリシーを無視します。

つまり、テーブルの所有者として接続するアプリケーション（スーパーユーザならなおさら）では、行レベルセキュリティはオンなのに効いていません。確かめるには、実際のロールで接続して行を数えます。

推奨事項
アプリケーションごとに1つのロール、グループにはLOGINなし、そして管理用以外はSUPERUSERを持たせない。ALTER DEFAULT PRIVILEGESはGRANTと同じ変更の中に入れてください。そうしないと、権限は次のテーブルまでしか持ちません。そして、一括で付与したものは書き留めておいてください。1年後のDROP ROLEがそれを求めてきます。

キーワード： セキュリティ、ロール、ユーザ、グループ、pg_hba.conf、pg_hba_file_rules、SCRAM-SHA-256、GRANT、REVOKE、ALTER DEFAULT PRIVILEGES、pg_default_acl、PUBLIC、pg_read_all_data、pg_monitor、RLS、行レベルセキュリティ、CREATE POLICY、BYPASSRLS、DROP OWNED BY

論理と物理、それぞれの用途、pg_dumpが置いていくもの（そのせいで誰もログインできなくなるもの）、PITRがそのままでは動かない理由、そしてディスクを埋めかねないスロット。

対象： PostgreSQL 13+

バックアップには2つの種類があり、同じ目的のためのものではありません。選び間違えると、それがわかるのは復元の日です。

論理バックアップ

-- SQLエディタではなく、コマンドラインで：
-- pg_dump -d demo -Fc -f demo.dump
-- pg_restore -d demo_nueva -j 4 demo.dump

デフォルトで使うべきは-Fc（カスタム）形式です：同じデータベースで、プレーンテキストのダンプは3.1 MB、カスタムは905 kBでした。しかも目次を持っているので（pg_restore -lは30のデータブロックを一覧にしました）、1つのテーブルだけを復元でき、-jで並列にもできます。

pg_dumpが運ばないもの、そして痛いのはそこ
ロールとクラスタ全体の設定は中に入っていません。測定結果：データベースのダンプにはCREATE ROLEが1つもなく、pg_dumpall --globals-onlyは存在した2つを出力しました。ダンプだけを復元すると、完璧なのに誰もログインできないデータベースが残ります。完全な論理バックアップは2つのファイルです：
- pg_dumpall --globals-only：ロール、パスワード、クラスタの権限。
- 各データベースのpg_dump。

pg_dumpは一貫性があり（スナップショットに対して動きます）、書き込み側をブロックしません。ただしACCESS SHAREロックを取るので、同時に発行されたALTER TABLEは待ち始め、すべてがその後ろに並びます。

物理バックアップ
pg_basebackupはクラスタ全体をコピーします。テストサーバで測定すると：-X streamで1.3秒で84 MBでした。このオプションはコピー中に生成されたWALも持ってきます。それがないとコピーは復元できません。WALのどの位置から再生するかを書いたbackup_labelが残ります：

START WAL LOCATION: 0/13000028 (file 000000010000000000000013)

PITR：ある時点までの復旧
物理バックアップが存在する理由ですが、そのままでは動きません：このサーバで測定すると、archive_modeはオフで出荷されています。アーカイブがなければ、物理バックアップは取得した瞬間をそのまま復元するだけで、1秒先にも進めません。

必要なものは3つです：
1. archive_mode = onと、WALの各セグメントを安全な場所にコピーするarchive_command（または別のマシンからのpg_receivewal）。
2. 定期的なpg_basebackup。
3. 復元時：バックアップのファイル、セグメントを取ってくるrestore_command、recovery_target_time = '…'、そしてデータディレクトリの空のrecovery.signalファイル。

古いバージョンから来た人がつまずくのは最後の点です：PostgreSQL 12からはrecovery.confはありません。パラメータはpostgresql.confに書き、「これは復旧である」と宣言するのはシグナルファイルです。

レプリケーションスロットは諸刃の剣
スロットは、コンシューマがまだ読んでいないWALをサーバが削除しないことを保証します。コンシューマが消えてスロットが残ると、ディスクがいっぱいになるまでWALがたまります（そしてディスクがいっぱいになるのは警告ではなく停止です）。次のように見張ってください：

SELECT slot_name, active, wal_status,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retenido
  FROM pg_replication_slots;

max_slot_wal_keep_sizeが上限を決めます：それを超えると、サーバはディスクを使い切るよりスロットを無効にするほうを選びます。

Calíopeのバックアップは論理バックアップ
バックアップツールが作るのはSQL（CREATEとINSERT）で、pg_basebackupではなくpg_dumpの系統です。移行とデータの復旧には向いています。サーバ全体をある時点まで復旧するには上に書いたものが必要で、それはクライアントではなくオペレーティングシステムの仕事です。

推奨事項
論理バックアップの2つのファイル（--globals-onlyとダンプ）を常に一緒に取り、バックアップではなく復元を試してください：エラーなく生成されたファイルでも復元に失敗することがあり、それを知る唯一の方法は実際のサーバに復元してみることです。

キーワード： バックアップ、pg_dump、pg_restore、pg_dumpall、GLOBALS、pg_basebackup、WAL、archive_mode、archive_command、PITR、recovery_target_time、recovery.signal、レプリケーションスロット、wal_status、復元

DDLはトランザクション対応であること、コストがかかるのはALTERではなくロックであること、テーブル全体を書き直す変更、そしてデータベースを止めずに済むNOT VALID + VALIDATEのパターン。

対象： PostgreSQL 13+

ここではDDLはトランザクション対応です。これはマイグレーションの書き方を変えるもので、ALTERのたびにそれだけでコミットされるMySQLから来たときに最初に理解すべきことです。

BEGIN;
ALTER TABLE pedidos ADD COLUMN moneda text;
CREATE INDEX idx_moneda ON pedidos (moneda);
CREATE TABLE monedas (codigo text PRIMARY KEY);
ROLLBACK;

確認済み：そのROLLBACKのあと、3つのものはどれも残っていませんでした。途中で失敗したマイグレーションは、中途半端なデータベースを残しません。だから健全なやり方は、マイグレーション全体をトランザクションの中に入れることです。

例外は片手で数えられます：CREATE INDEX CONCURRENTLY、VACUUM、ALTER SYSTEMはトランザクションの中に入れることができません。

コストがかかるのはALTERではなくロック
ほとんどすべてのALTER TABLEはACCESS EXCLUSIVEを取り、これはSELECTとさえ競合します。変更自体は1ミリ秒で済んでも、ロックを待つのに何時間もかかることがあります（そして待っている間、後ろに来たものはすべて並びます）。だから本番環境のDDLは常に次のように発行します：

SET lock_timeout = '3s';
ALTER TABLE pedidos ADD COLUMN moneda text;

ロックが取れなければ3秒で失敗し、再試行されます。これがないと、1ミリ秒のマイグレーションがアプリケーション全体を止めることがあります。

テーブルを書き直すものと、そうでないもの
書き直すとはテーブル全体をコピーすることです：サイズに比例した時間がかかり、その間は2倍のディスクが必要です。500,000行、32 MBで測定すると：

この表をまとめるルール：広げるのはただで、狭めると書き直す。そしてデフォルト値付きのADD COLUMNは、PostgreSQL 11で書き直しをしなくなりました：列を空で追加してバッチで埋めるという昔の回り道は、もう必要ありません。

時間には表れない注意が2つあります：
- DROP COLUMNが一瞬で終わるのは、列を削除済みと印を付けるだけだからです：テーブルが書き直されるまで容量は戻りません。
- SET NOT NULLと通常のCHECKは書き直しませんが、ロックを持ったままテーブル全体を走査します。大きなテーブルでは、それだけでもう停止です。

データベースを止めずに済むパターン：NOT VALIDのあとにVALIDATE
制約は2段階で追加できます：まず、すでにあるものを検査せずに宣言し（一瞬で終わります）、そのあと検証します。検証は遅い部分ですが、ずっと弱いロックで済みます。

ALTER TABLE ddl_hija
    ADD CONSTRAINT fk_p FOREIGN KEY (padre) REFERENCES ddl_demo (id) NOT VALID;

ALTER TABLE ddl_hija VALIDATE CONSTRAINT fk_p;

測定結果：NOT VALIDの宣言はSHARE ROW EXCLUSIVE（読み取りは許す）で0.7 ms、検証はSHARE UPDATE EXCLUSIVEで67 msで、これは書き込み側すらブロックしません。一度に行っても時間は同じでしたが、強いロックを最初から最後まで持ったままでした。実際のテーブルでは、その違いがデプロイと停止を分けます。

制約がNOT VALIDになった瞬間から、サーバは新しい行にはそれを適用します。残っているのは古い行の検査だけです。

インデックス
通常のCREATE INDEXは書き込みを止めます。CREATE INDEX CONCURRENTLYは何も止めませんが、マイグレーションのトランザクションには入らないので、独立したステップにして、あとで確認します（pg_index.indisvalid）。

推奨事項
lock_timeoutは必ず。マイグレーションは、入れられないものを除いてトランザクションの中に。大きなテーブルの制約にはNOT VALID + VALIDATE。そして型の変更に注意してください：書き直しが隠れているのはそこです。型を狭める必要があるなら、ほとんどの場合、新しい列を追加し、バッチでコピーし、名前を変えるほうが得策です。

キーワード： DDL、ALTER TABLE、マイグレーション、トランザクション対応、ROLLBACK、lock_timeout、ACCESS EXCLUSIVE、書き直し、RELFILENODE、ADD COLUMN、DROP COLUMN、SET NOT NULL、NOT VALID、VALIDATE CONSTRAINT、CREATE INDEX CONCURRENTLY

存在せず構文エラーになるもの、textがvarcharより劣らない理由、numericと浮動小数点、timestamptzが本当に保存しているもの、そしてjsonbが容量を節約しない理由。

対象： PostgreSQL 13+

型は、MySQLからの移行が最初の試みで失敗する数少ない場所の1つで、それはかえって好都合です：存在しないものは、半分受け入れられる代わりに構文エラーになります。

ここに存在しないもの
- UNSIGNED：42601 syntax error at or near "unsigned"。符号なし整数はありません。1つ上の型かCHECK (n >= 0)を使ってください。
- INT(11)：これも42601です。MySQLの表示幅は存在せず、見かけどおりの意味だったこともありません。
- TINYINT、DATETIME、括弧付きのDOUBLE、そしてMySQLのSET型とENUM型。対応するのはsmallint、timestamptz、double precision、そして本来のenum型です。

テキスト：textを使えばそれで済む
同じ値'hola'で測定すると：textは5バイト、varchar(50)は5、char(50)は51でした。3つとも同じように保存されます。varchar(n)は長さの検査を加えるだけで、char(n)は空白で埋めます。そしてその空白は比較を変えます：'x' = 'x 'はtextでは偽、charでは真です。

ここではtextはvarcharより劣りません：ペナルティはありません。上限が業務上のルールであるときはvarchar(n)を、char(n)はほとんど使いません。

数値：お金にはnumeric、そしてそれは迷信ではない

SELECT (0.1::float8 + 0.2::float8) = 0.3::float8,   -- false
       (0.1::numeric + 0.2::numeric) = 0.3::numeric; -- true

測定結果：浮動小数点では0.1 * 3は0.30000000000000004、numericでは正確に0.3でした。numericは正確で任意精度ですが、その代償を容量と速度で払います（その値でfloat8の8に対して10バイト、そしてソフトウェアによる演算）。お金と、顧客の前で合計するあらゆる数字にはnumericを。

測定したサイズ：intは4、bigintは8、booleanは1、uuidは16（テキストなら36かかるところ）。

日付：ほとんどの場合timestamptz
timestampとtimestamptzは同じ8バイトです。違いはサイズでも、一方がタイムゾーンを保存することでもありません：どちらもタイムゾーンを保存しません。timestamptzは瞬間を保存し（入るときにUTCに、出るときにセッションのタイムゾーンに変換します）、timestampは時計の読みを保存するだけです。

同じ瞬間を、2つのセッションのタイムゾーンで測定すると：

同じ瞬間を2通りに言っているのです。timestampでは変換はまったくありません：入れたものがそのまま出てきて、本当は何時だったのかを知る必要がある人には、それを知る手段がありません。dateは4バイト、intervalは16バイトです。

jsonかjsonbか：ほとんどの場合jsonb、そしてサイズのためではない

SELECT '{"b":1,"a":2,"a":3}'::json::text,   -- {"b":1,"a":2,"a":3}
       '{"b":1,"a":2,"a":3}'::jsonb::text;  -- {"a": 3, "b": 1}

jsonは届いたままのテキストを保存します：順序も空白も、重複したキーさえも保ちます。jsonbは解析済みのツリーを保存します：キーを並べ替え、重複は最後のものを残し、空白を正規化します。だからjsonbは問い合わせが速く、GINでインデックスでき、jsonが正しいのは、届いたとおりバイト単位でドキュメントを返さなければならないときだけです。

正しくないのは、jsonbが容量を節約するという話です：同一のドキュメント200,000件で測定すると、jsonは14 MB、jsonbは16 MBでした。jsonbを選ぶのは問い合わせ方のためで、重さのためではありません。

配列
配列は第一級の型で、独自の演算子（包含の@>、array_length）とGINインデックスがあります。タグや短いリストには便利です。要素が独自の属性を必要としたり、別のテーブルと結合しなければならなくなったりすると、すぐに便利ではなくなります。配列は節約したテーブルではありません：値です。

serialかIDENTITYか
serialは型ではありません：シーケンスを作り、そのnextvalをデフォルト値に設定する糖衣構文です。GENERATED ALWAYS AS IDENTITYは標準のもので、しかも列を保護します：値を手で挿入しようとすると428C9 cannot insert a non-DEFAULT value into columnと答えました。新しいテーブルにはIDENTITYを。

推奨事項
テキストにはtext、お金にはnumeric、瞬間にはtimestamptz、問い合わせるドキュメントにはjsonb、キーにはIDENTITY。そしてMySQLから移行するときは、構文エラーに仕事をさせてください：受け入れられて別の意味になる型よりはましです。

キーワード： データ型、TEXT、VARCHAR、CHAR、NUMERIC、FLOAT、DECIMAL、TIMESTAMPTZ、TIMESTAMP、タイムゾーン、JSON、JSONB、配列、UUID、SERIAL、IDENTITY、UNSIGNED、ENUM

毎日目にするコード、コードではなくクラスを相手にプログラムする理由、誰も見せてくれないDETAILとHINTが実際に言っていること、そして接続が開きもしないときにコードがある場所。

対象： PostgreSQL 13+

ここにはエラー番号はありません。あるのはSQLSTATEです：5文字で、そのうち最初の2文字がクラスです。そしてプログラムが相手にするのはクラスです：何が失敗したのかを正確に知らなくても、何をすべきかを教えてくれます。

毎日目にするもの

見るべきなのはクラス

実際的な結論：アプリケーションはクラス40を再試行し、クラス42は再試行しません。再試行がこの2つを区別しないと、正当なトランザクションが失われるか、決して動かないクエリーが1,000回繰り返されます。

メッセージは3つの部分からなり、役に立つのは3つ目
MESSAGEは何が起きたか、DETAILは行や値、HINTは何をすべきかを伝えます。測定結果：

- 23505：MESSAGE：duplicate key value violates unique constraint "er_d_pkey"。DETAIL：Key (id)=(1) already exists.
- 42883：MESSAGE：operator does not exist: text = integer。HINT：No operator matches the given name and argument types. You might need to add explicit type casts.
- 42703：MESSAGE：column "ids" does not exist。HINT：Perhaps you meant to reference the column "er_d.id".

MESSAGEしか表示しないクライアントは情報の半分を捨てています（しかも、抜け出す方法を教えてくれるほうの半分です）。Calíopeは3つすべてを組み立てて表示します。

さらに、エラーには個別のフィールドがあります：テーブル、列、制約の名前です。23505にはconstraint = er_d_pkeyが付いてきました。これがあるので、メッセージのテキストを解析せずに「そのメールアドレスはすでに登録されています」に変えられます。

エラーはトランザクションを中断させる
BEGINの中でエラーが起きると、ROLLBACKするまで、それ以降はすべて25P02と答えます。クライアントのバグではありません：そういう設計で、うまく抜け出す方法はセーブポイントです。

接続のエラーは応答には届かない
ロールやデータベースが存在しない、あるいはパスワードが間違っていると、接続は開きません：クライアントには「接続に失敗しました」としか見えません。コードはサーバのログにあり、それも頼んだときだけです：

ALTER SYSTEM SET log_error_verbosity = 'verbose';
SELECT pg_reload_conf();

これで、ログはFATAL: database "no_existe" does not existからFATAL: 3D000: database "no_existe" does not existになりました（存在しないロールなら28000）。誰かが「接続できない」と報告してきたときに、推測するか知っているかの違いです。

推奨事項
アプリケーションのコードではクラスで分岐し、完全なコードはユーザが見るメッセージ（23505→「すでに存在します」）にだけ使ってください。SQLSTATEは必ず自分のログに保存してください：メッセージのテキストはサーバの言語で変わりますが、コードは変わりません。

キーワード： エラー、SQLSTATE、コード、クラス、23505、23503、42P01、42601、42883、42501、25P02、40001、40P01、55P03、57014、3D000、28000、DETAIL、HINT、再試行、log_error_verbosity

宣言的パーティション分割とプランナが本当にプルーニングするもの、グローバルインデックスも単一列の一意性もない理由、68 msのATTACHを0.5ミリ秒にするCHECK、そしてデフォルトパーティションのコスト。

対象： PostgreSQL 13+

ここでのパーティション分割は宣言的です：キーを宣言し、各パーティションは本物のテーブルです。親は1行も持ちません（測定結果：0バイトで、データは子に分散しています）。

CREATE TABLE pt (id bigserial, creado date NOT NULL, importe numeric)
    PARTITION BY RANGE (creado);

CREATE TABLE pt_2024 PARTITION OF pt
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

CREATE TABLE pt_resto PARTITION OF pt DEFAULT;

形は3つあります：RANGE（日付、金額）、LIST（国、状態）、HASH（分散させるための分散）。

肝心なのはプルーニング
3年分の300,000行で測定すると：WHERE creado BETWEEN '2024-03-01' AND '2024-03-31'のクエリーは「pt_2024だけ」を走査しました。同じテーブルで、キーではない列で絞り込むと、すべてのパーティションに対してParallel Appendを行いました。

それが設計を決めるルールです：パーティションキーは、ほとんど常に絞り込みに使う列にする。クエリーがそれに触れなければ、パーティション分割は読み取りを減らしません：分散させるだけです。

存在しないもの：グローバルインデックス
親に作ったインデックスはパーティションごとに1つ作られます（測定結果：4つのパーティションに4つのインデックス）。テーブル全体にまたがる単一のインデックスはなく、そこから、設計する前に知っておくべき制限が生まれます：

ALTER TABLE pt ADD CONSTRAINT pt_uni UNIQUE (id, creado);

(id)だけのUNIQUEは0A000 unique constraint on partitioned table must include all partitioning columnsで拒否されます。宣言的パーティション分割では、識別子のグローバルな一意性は保証できません。それは制約ではなく、構造上一意であるシーケンスから得ます。

ATTACH：68 msと0.5ミリ秒の違い
既存のテーブルをアタッチすると、サーバはそのすべての行が範囲に収まるかを検査しなければなりません。300,000行で測定すると：

つまり：テーブルがすでに範囲を含意するCHECK制約を持っていれば、サーバは走査を省略します。10億行のテーブルでは、それが一瞬のACCESS EXCLUSIVEと30分間のそれとの違いです。

デフォルトパーティションはただではない
DEFAULTはどの範囲にも入らないものを受け止め、想定外の日付が挿入されたときのエラーを防ぎます。その代わりに、測定結果：ALTER TABLE … DETACH PARTITION … CONCURRENTLYは55000 cannot detach partitions concurrently when a default partition existsと答えました。さらに、新しいATTACHのたびに、入ってくる範囲の行を隠していないか確かめるためにデフォルトパーティションを走査しなければなりません。

本当にパーティション分割する理由
クエリーの速さのためではなく（それはインデックスの役目です）、メンテナンスのためです：
- ある期間をまるごと削除するのは、そのパーティションのDROP TABLEです：測定すると2.3 msで、容量はファイルシステムに戻ります。同等のDELETEはもっと時間がかかり、なによりVACUUMが掃除すべき不要行と、戻ってこない容量を残します。
- VACUUMとANALYZEはパーティションごとに動くので、メンテナンスの作業が履歴全体とともに増え続けることはなくなります。
- 古いデータは、稼働中のテーブルに触れずにデタッチしてアーカイブできます。

推奨事項
問い合わせるものではなく、削除するものでパーティション分割してください。そして、クエリーがWHEREにキーを含んでいるかは、思い込みではなくプランを見て確かめてください。既存のテーブルを分割する前に、本当に必要なのがインデックスではないか確認してください：パーティション分割は、メンテナンスを安くする代わりに動く部品を増やし、その取引はある程度のサイズを超えてはじめて元が取れます。

キーワード： パーティション分割、パーティション、RANGE、LIST、HASH、プルーニング、ATTACH、DETACH、DEFAULT、グローバルインデックス、UNIQUE、0A000、DROP PARTITION、メンテナンス

ここにutf8の落とし穴がない理由、エンコーディングと照合順序の違い、それぞれで並び順がどう変わるか、そしてプレフィックスのLIKEがインデックスを使わない理由。

対象： PostgreSQL 13+

MySQLからの移行であれほど高くついた落とし穴は、ここにはありません：UTF-8ではないutf8は存在しません。エンコーディングはデータベースを作成するときに宣言し、UTF8はUTF-8のすべてです。

通常のtext列に4つの文字列を保存して測定すると：

特別な宣言は何も必要ありませんでした。length()は文字を、octet_length()はバイトを数えます。MySQLでは型ごとに追いかけなければならなかった区別です。

エンコーディングと照合順序は別のもの
- エンコーディング：バイトをどう保存するか。データベースに属し、作成時に固定され、あとから変更できません：変えるにはダンプして作り直すことになります。
- 照合順序：どうソートし、どう比較するか。データベースごと、列ごと、式ごと、さらにはORDER BYの中でも設定できます。

テストサーバでは：server_encoding = UTF8で、データベースはlibcプロバイダのen_US.utf8でした。利用できる照合順序は815あり、2つのプロバイダから来ています：システムのもの（C、POSIX、en_US.utf8）とICUのもの（es-ES-x-icu、unicode）で、後者はPostgreSQL 15からデータベースのデフォルトのプロバイダにもできます。

照合順序で何が変わるか

SELECT array(SELECT s FROM (VALUES ('a'),('B'),('á'),('b'),('A')) v(s) ORDER BY s COLLATE "C"),
       array(SELECT s FROM (VALUES ('a'),('B'),('á'),('b'),('A')) v(s) ORDER BY s COLLATE "es-ES-x-icu");

測定すると、結果はまるで似ていません：

- C：A, B, a, b, á。文字の番号でソートします：大文字がすべて小文字より前で、アクセント付きは最後です。
- es-ES-x-icu：a, A, á, b, B。辞書のようにソートします。

そして比較もそれとともに変わります：'a' < 'B'はCでは偽、スペイン語の照合順序では真です。「並び順がおかしく出る」リストは、ほとんどの場合アプリケーションのバグではありません：列の照合順序です。

LIKEにインデックスが役立つかは照合順序が決める
これは、自分で見つけるのが最も難しい実際的な細部です。言語的な照合順序（データベースのもの）では、通常のBツリーインデックスはプレフィックス検索の役に立ちません。200,000行で測定すると：

- WHERE s = 'usuario42' → Index Only Scan。
- WHERE s LIKE 'usuario42%' → インデックスがすぐそこにあるのに「Seq Scan」。
- 正しい演算子クラスでインデックスを作り直すと、同じクエリーはBitmap Index Scanになりました。

CREATE INDEX idx_prefijo ON ch_like (s text_pattern_ops);

text_pattern_opsはバイト単位で比較します。それこそがLIKE 'something%'に必要なものです。列の照合順序がCなら不要です。もともとそう比較するからです。

照合順序にはバージョンがあり、それが重要
データベースは、インデックスを作ったときの照合順序のバージョンを記録しています（測定結果：datcollversion = 2.36、システムのライブラリのもの）。オペレーティングシステムをアップグレードしてそのバージョンが変わると、順序が変わることがあり、前の順序で作られたインデックスは正しくなくなります：そこにある行が見つからない検索です。PostgreSQLはその不一致を警告し、答えはREINDEXです。

だから多くの人は、システムのアップグレードを生き延びなければならないデータベースにC照合順序かICUを選びます：ICUは独自のバージョンを持ち、システムのものに依存しません。

推奨事項
常にUTF8。照合順序はデータベースを作成するときに決めます。あとから変えるのは高くつくからです：コード、識別子、パスである列にはC（ソートが速く、LIKEでも使えます）、人が読むものには言語的な照合順序を。そしてLIKE 'x%'のクエリーがインデックスを使わないなら、クエリーをいじる前に照合順序を見てください。

キーワード： エンコーディング、UTF8、照合順序、COLLATE、ICU、LIBC、text_pattern_ops、LIKE、プレフィックス、ORDER BY、DATCOLLVERSION、REINDEX、octet_length

本当に痛いもの（63バイトの名前、1,600列、インデックスあたり32列）、識別子の上限がエラーではなく通知になる理由、そしてページに収まらない値をTOASTがどうするか。

対象： PostgreSQL 13+

PostgreSQLの上限はInnoDBのものとは似ておらず、日々痛いのは大きな上限ではありません。

実際にぶつかるもの

最初の3つは測定済みです：1,600列は問題なく作成でき、1,601列は失敗しました。32列のインデックスは作成でき、33列のものはできませんでした。

エラーにならないのは識別子の上限だけ
72文字の名前は63文字で保存され、サーバは通知でそれを伝えました：

identifier "t_aaa…" will be truncated to "t_aaa…"

通知はエラーではありません：文は続行されました。だから64文字目以降しか違わない2つの長い名前は同じオブジェクトになり、失敗はずっとあとになって現れます。これにぶつかるのは名前の生成器（インデックス、制約、バッチごとの一時テーブル）で、人の手ではありません。

大きな上限は、ほとんど問題にならない
ここでは測定していません（ディスクを埋めることになるので）。公式の数字です：

- テーブルの最大サイズ：32 TB。
- フィールドの最大サイズ：1 GB。
- 行の最大サイズ：1.6 TB。
- テーブルあたりの行数：上限は定められていません。
- クラスタあたりのデータベース数とデータベースあたりのテーブル数：実用上の上限はありません。

そのどれよりもずっと先に尽きるのはメンテナンスです：テラバイト級のテーブルに対するVACUUM、バックアップ、インデックスの再構築です。

TOAST：1 GBのtextが8 kBのページを壊さない理由
1行は1ページに収まらなければならず、1ページは8 kBです。大きな値は圧縮され、横のテーブル（TOASTと呼ばれるもの）に自動的に移されます。宣言は何も要りません。

text列に100,000バイトのテキストを保存して測定すると：

- octet_length：データは100,000バイト。
- pg_column_size：1,156バイト。つまり圧縮されました。
- テーブルは8,192バイトで、TOASTを含めると16 kBでした。

そこから実際的な結論が出ます：大きな列を持つテーブルへのSELECT *は、誰も見なくてもそれらの列を読むコストを払います。必要な列だけを求めるのはスタイルではなく、I/Oの問題です。

設定で決まる上限
これらはエンジンではなくインスタンスに属するので、pg_settingsに現れます：max_connections（出荷時は100）、max_locks_per_transaction（64）、max_wal_size、work_mem。実際のサーバで尽きるのはこちらです。上の表のものは、ほとんど尽きません。

推奨事項
見張るのは2つだけです：何かが名前を生成するときの63バイトと、誰かがスキーマの半分を入れた複合インデックスを提案してきたときのインデックスあたりの列数。そのほかのことは、ドキュメントではなくpg_settingsで知ることができます。

キーワード： 制限、識別子、63バイト、切り詰め、1600列、32列、インデックス、TOAST、ページ、8 kB、32 TB、1 GB、pg_settings、max_connections

varcharとnvarchar、Nプレフィックス、_UTF8の照合順序、各サフィックスの意味、照合順序の競合、そしてN'…'のパラメータでインデックスが使われなくなる理由。

対象： SQL Server 2022+

MySQLから来た人へ：ここにはutf8mb4もSET NAMESもありません。SQL Serverでは、テキストのエンコーディングは別に宣言するものではありません。それを決めるのは照合順序で、テキスト型には2つのファミリーがあります。

varcharとnvarcharは2つのエンコーディング
- nvarchar（とnchar）はUTF-16で保存します。照合順序が何であれ、あらゆるUnicode文字を保存できます。
- varchar（とchar）はその照合順序のコードページのバイトで保存します。Latin1_General_CI_ASのような従来の照合順序ではそれはWindows-1252で、その外にあるものは?として保存されます。
- _UTF8で終わる照合順序（SQL Server 2019以降）では、varcharはUTF-8で保存します。

テスト用サーバ（SQL Server 2025）で、データベースをLatin1_General_100_CI_AS_SC_UTF8にして測定した結果：

LEN()は文字を、DATALENGTH()はバイトを数えます。varchar(n)のnはバイト数で、nvarchar(n)ではバイトの組の数です。文字数ではありません。測定結果：UTF-8のvarchar(10)にはñが5つ入り、10個ではMsg 2628（String or binary data would be truncated）になります。nvarchar(10)にはñが10個入りますが、絵文字6つは入りません。

Nプレフィックス
前にNのないリテラルはvarcharで、どの列に届くよりも前にデータベースのコードページに変換されます。Latin1_General_CI_ASのデータベースで測定した結果：

- 'Zúrich ✓' → Zúrich ?
- N'Zúrich ✓' → Zúrich ✓

さらに、そのデータベースのvarchar列では、リテラルにNを付けても、Zúrich ✓ 日本はZúrich ? ??として保存されました。データは書き込みの時点で失われ、エラーも警告も出ません。あとから列の照合順序を変えても戻りません。保存されたものはすでに疑問符です。

各サフィックスの意味

SELECT CASE WHEN 'a' = 'A' COLLATE Latin1_General_100_CI_AS THEN 1 ELSE 0 END AS ci,
       CASE WHEN 'a' = 'A' COLLATE Latin1_General_100_CS_AS THEN 1 ELSE 0 END AS cs,
       CASE WHEN 'e' = 'é' COLLATE Latin1_General_100_CI_AI THEN 1 ELSE 0 END AS ai,
       CASE WHEN 'e' = 'é' COLLATE Latin1_General_100_CI_AS THEN 1 ELSE 0 END AS acc;

測定結果：1, 0, 1, 0。

- _CI / _CS — 大文字と小文字を区別しない／区別する。
- _AI / _AS — アクセントを区別しない／区別する。
- _SC — 絵文字のような基本面の外にある文字を1文字として数えます。測定結果：LEN(N'😀')は_SCありで1、なしで2になり、_SCがないとLIKE N'_'はそれに一致しません。
- _UTF8 — varcharをUTF-8にします。
- _BIN2 — コードポイントで比較します。A, B, a, b, n, o, á, ñの順に並べました。Latin1_General_100_CI_ASとModern_Spanish_100_CI_ASではA, a, á, b, B, n, ñ, oでした。
- 100はソート表のバージョンです。これのないもの（Latin1_General_CI_AS）はより古く、SQL_で始まるものはSQL Server 2000からのレガシーなものです。

テスト用サーバには5540の照合順序があり、そのうち1585が_UTF8です（sys.fn_helpcollations()）。

サーバ、データベース、列、式

SELECT SERVERPROPERTY('Collation'), DATABASEPROPERTYEX('demo', 'Collation');

照合順序は4つのレベルで設定され、それぞれ作成されるときに1つ上のレベルのものを受け継ぎます：

- サーバ — masterとtempdbのもので、インストール時に選びます。
- データベース — CREATE DATABASE … COLLATE …。
- 列 — name varchar(40) COLLATE Latin1_General_100_CS_AS。
- 式 — WHERE a = b COLLATE Latin1_General_100_CI_AS、またはORDER BYの中。

ALTER DATABASE … COLLATEはすでにある列には触れません。測定すると、データベースは_UTF8に移りましたが、その列はLatin1_General_CI_ASのままでした。列はそれぞれ専用のALTER TABLE … ALTER COLUMNで変更します。

照合順序の競合
照合順序の異なる2つのテキストは、そのままでは比較できません：

- WHERE a = b → Msg 468、Cannot resolve the collation conflict。
- 両方の列のUNION ALL → Msg 457。カタログのテキスト（sys.*はLatin1_General_CI_AS）と組み合わせると → Msg 451。
- 片方にCOLLATEを付ければ解決します。

最もよくあるのは一時テーブルです。#tmpはtempdbにあり、あなたのデータベースではなくサーバの照合順序で作られます。_UTF8のサーバ上のLatin1_General_100_CI_ASのデータベースで測定すると、#tmpとのJOINはMsg 468になりました。解決策は、その列をCOLLATE DATABASE_DEFAULTで宣言することです。

照合順序とインデックス
列にインデックスのある100,000行で：

- WHERE s = 'usuario42' → Index Seek。列の側にCOLLATEを付けると → Index Scanで、インデックス全体を読みます。
- WHERE s LIKE 'usuario42%' → Index Seek。PostgreSQLとは違います。
- varchar列に対するN'…'のパラメータ：Windowsの照合順序（Latin1_General_100_CI_AS）では、インデックスは引き続き使われ、論理読み取りは7でした。SQL_の照合順序（SQL_Latin1_General_CP1_CI_AS）では、列全体がnvarcharに変換され、プランはIndex Scanになります：3に対して334の読み取りです。等価検索が遅く、パラメータがnvarcharで届いているなら、列の照合順序を確認してください。

推奨事項
新しいデータベースには、varcharを完全なUTF-8にする_100_…_SC_UTF8の照合順序を。一時テーブルの列はCOLLATE DATABASE_DEFAULTで宣言します。そして照合順序はデータベースを作成するときに決めてください。あとから変えるのは列ごとの作業になります。

キーワード： エンコーディング、照合順序、COLLATE、VARCHAR、NVARCHAR、UTF8、UTF-16、Nプレフィックス、Unicode、_SC、_BIN2、468、451、457、2628、TEMPDB、DATABASE_DEFAULT、DATALENGTH

datetimeとdatetime2、booleanの代わりのbit、moneyとdecimal、断片化しないGUID、日付ではないrowversion、8000バイトの上限、2025のjson型。

対象： SQL Server 2022+

MySQLから来た人へ：いくつかの型は名前が似ていて動作が違い、2つの名前は誤解を招きます。timestampは日付ではなく、datetimeは丸めます。存在しないものはエラーになり、それはよいことです。UNSIGNEDはなく、tinyintは0から255までしかなく（-1ではMsg 220、算術オーバーフローになります）、SELECT TRUEはMsg 207になります。TRUEは言語の語ではありません。

日付：datetimeではなくdatetime2
datetimeは古い型で、1/300秒単位に丸めます。測定結果：

最後の行がレポートを壊すものです。datetimeに対するWHERE fecha <= '2026-09-30 23:59:59.999'は、翌日の午前0時を含みます。1日分を取るには、どの型でもfecha >= '2026-09-30' AND fecha < '2026-10-01'を使います。

datetime2は100ナノ秒単位まで保存し（datetime2(7)では.1234567が書いたとおりに残りました）、1年から始まり（datetimeで'1700-01-01'はMsg 242、範囲外になります）、同じかそれ以下の容量しか使いません。測定結果：datetimeは8バイト、datetime2(7)は8、datetime2(3)は7、datetime2(0)は6です。そして考えずに混ぜないでください。同じ12:00:00.001でも、datetime2(3)とdatetimeでは等しくありません。datetimeはすでに.000として保存しているからです。

測定したほかのサイズ：dateは3バイト、timeは5、smalldatetimeは4（分単位）、datetimeoffsetは10です。

datetimeoffsetはオフセットを保存する
PostgreSQLのtimestamptzとは違い、書き込まれたときのオフセットを保存し、時点で比較します。'2026-09-30T12:00:00+05:30'と'2026-09-30T06:30:00+00:00'は等しいという結果でした。SWITCHOFFSET(value, '+00:00')でUTCに移し、AT TIME ZONE 'Central European Standard Time'は夏時間を適用して08:30 +02:00を返しました。Calíopeはそれを値自身の時刻で、横にオフセットを付けて表示します。

booleanはない：あるのはbit
bitは0か1の数値で、真偽値ではありません。測定結果：5、-1、文字列'true'を代入すると1が保存されます。WHERE @bだけではMsg 4145になり（WHERE @b = 1と書く必要があります）、bit + bitはMsg 402になります。Calíopeは1または0として表示します。

金額：decimal、そしてmoneyは注意して

DECLARE @m money = 100, @m3 money = 3;
DECLARE @d decimal(19,4) = 100, @d3 decimal(19,4) = 3;
SELECT @m / @m3 * @m3 AS con_money,     -- 99.9999
       @d / @d3 * @d3 AS con_decimal;   -- 100.000000

moneyには4桁の固定小数があり、途中の結果でもそうです。1 / 3は.3333になり、3を掛けても整数に戻りません。decimalは結果のスケールを広げます（.3333333333333333333になりました）。計算にはdecimalを使います。moneyは8バイト、smallmoneyは4バイトです。floatはどこでもそうであるように2進数です。0.1 + 0.2は0.30000000000000004になり、0.3との等価は偽でした。decimalでは真です。

GUID：uniqueidentifier、そして順序が大事
uniqueidentifierは16バイトです。クラスタ化主キーにすると、NEWID()は行をインデックス全体にランダムに散らします。20,000行を1行ずつ挿入して測定した結果：

NEWSEQUENTIALID()は列のDEFAULTとしてしか使えません。SELECT NEWSEQUENTIALID()はMsg 302になります。CalíopeはGUIDを、SQL Serverと同じく大文字で表示します。

rowversionは日付ではない
rowversion（以前はtimestampと呼ばれていた型で、列の作成時にはその名前も今も受け付けられます）は、行への書き込みのたびに変わる8バイトのデータベースのカウンタです。測定結果：2つの行が0x…07D4と0x…07D5で作られ、1つ目を更新すると0x…07D6に変わりました。時刻はまったく保存しません。これは楽観的な同時実行制御のためのものです。バージョンを読み、WHERE ver = @readで更新します。Calíopeはバイナリとして[8 bytes]と表示します。

テキスト：8000バイト、またはmax
max以外では、varchar(n)は8000まで、nvarchar(n)は4000までです。varchar(8001)はMsg 131に、nvarchar(4001)はMsg 2717になります。それを超えるものはvarchar(max)とnvarchar(max)です。

行にも上限があります。1つのテーブルにchar(5000)の列が2つあるとMsg 1701になります（最小の行が10,007バイトになり、最大は8060です）。いっぱいのvarchar(8000)2つなら入ります（測定結果：1行に16,000バイト）。可変長のデータは、収まらないときにページの外に移るからです。

そして警告の出ない落とし穴：varchar(max)に代入したREPLICATE('x', 10000)は8000文字になりました。関数は引数の型で動作するからです。REPLICATE(CAST('x' AS varchar(max)), 10000)なら10,000文字です。

JSON：json型はSQL Server 2025から
SQL Server 2022では、JSONはnvarchar(max)に保存し、CHECK (ISJSON(col) = 1)で検証します。これは不正なテキストをMsg 547で拒否します。2025からはjson型があり、書き込み時にMsg 13609で拒否し、解析済みの形で保存します。142文字の注文を20,000件コピーして測定すると、jsonは5.4 MB、nvarchar(max)は6.0 MBでした。ごく小さなドキュメント{"b":1,"a":2}では逆で、60バイトに対して26バイトでした。

そして目に見える違いが1つあります。キーが重複していると、ISJSONは{"b":1,"a":2,"a":3}を受け付けますが、json型はそれを{"b":1,"a":2}として返しました。最初のキーを残し、何も言いません。キーの順序は保持します。Calíopeはjsonをテキストとして受け取り、そのまま表示します。

特殊な型
- geographyとgeometry — WKBではない独自のバイナリ形式を持つ型です。geography::Point(40.4168, -3.7038, 4326)は22バイトで、そのSTAsText()はPOINT (-3.7038 40.4168)になります。コンストラクタは緯度、経度を求め、テキストは経度、緯度で出てきます。Calíopeはセルを[22 bytes]と表示します。読むには、クエリーでcol.STAsText()を使います。
- hierarchyid — ツリーの中のパスです。'/1/3/'は2バイトで保存され、レベルは2、親は/1/でした。Calíopeはこれをデコードせず、セルにはunsupported type: hierarchyidと表示されます。クエリーでcol.ToString()を使えば読めます。
- sql_variant — 複数の型の値を、それぞれ自分の型のまま保持する列です。SQL_VARIANT_PROPERTY(@v, 'BaseType')はdecimalを返しました。Calíopeは基本型で表示します。カタログ（sys.extended_properties）では意味がありますが、自分のテーブルでは、たいてい設計のまずい列です。

IDENTITYかSEQUENCEか
IDENTITYは列のプロパティで、列を保護します。手で値を挿入するとMsg 544になります。SET IDENTITY_INSERT tabla ONを使えば挿入でき、そのあとカウンタは最大値から続きます（100を挿入したあと、次の行は101でした）。そして欠番が出ます。ROLLBACKで取り消したINSERTは3を使い切り、次の行は4でした。欠番はデータの消失ではありません。

SEQUENCEは、複数のテーブルで共有できる独立したオブジェクトです。2つのテーブルでDEFAULT NEXT VALUE FOR sqを使うと、値は一方に1と3、もう一方に2と分かれました。挿入する前に番号が必要なとき、または共有するときに使います。テーブルのキーにはIDENTITYを使います。

推奨事項
時計の読みにはdatetime2、時点にはdatetimeoffset、金額にはdecimal、bitは数値であることを承知のうえで使い、クラスタ化キーがGUIDならNEWSEQUENTIALID()か整数を、そしてjson型は最も古いサーバが2025の場合にだけ使います。テキストについては「エンコーディングと照合順序（SQL Server）」を参照してください。

キーワード： 型、DATETIME、DATETIME2、DATETIMEOFFSET、DATE、TIME、BIT、BOOLEAN、MONEY、DECIMAL、FLOAT、UNIQUEIDENTIFIER、GUID、NEWSEQUENTIALID、ROWVERSION、TIMESTAMP、VARCHAR、NVARCHAR、MAX、JSON、ISJSON、HIERARCHYID、GEOGRAPHY、SQL_VARIANT、IDENTITY、SEQUENCE、UNSIGNED

Msgの読み方、レベルが教えること、毎日目にする番号、トランザクションを中断するエラーとしないエラー、THROWを使ったTRY…CATCH、そして18456の理由がある場所。

対象： SQL Server 2022+

MySQLから来た人へ：ここにも番号があります（PostgreSQLのようなSQLSTATEはありません）。ただし、すべてのエラーは4つのデータを持ち、そのすべてが重要です。Calíopeは次のように1行で表示します。sqlcmdは2行に分けます：

Msg 2627, Level 14, State 1, Line 1: Violation of PRIMARY KEY constraint 'PK__padre__3213E83F9B0ABF57'. Cannot insert duplicate key in object 'dbo.padre'. The duplicate key value is (1).

- Msg：番号です。調べるときも、コードで対処するときも、この番号を使います。
- Level：重大度で、0から25まであります。誰の責任か、そして接続がどうなるかを示します。
- State：同じ番号を持つ原因をサーバが区別するためのサブコードです。ほとんどのエラーでは関係ありませんが、18456では、理由を示す唯一のものです。
- Line：バッチ内（2つのGOの間にあるもの）またはプロシージャ内の行です。プロシージャ内のエラーはProcedure p_falla, Line 3のように表示されます。

まず見るべきはレベル

20以上のレベルは、sysadminでなく、WITH LOGも付けずに手で発生させることはできません。Msg 2754になります。Calíopeはレベル20以上を接続の切断として扱います。

毎日目にするもの
SQL Server 2025に対して1つずつ発生させました：

任意の番号のテキストを見るには：SELECT text FROM sys.messages WHERE message_id = 1205 AND language_id = 1033;。英語のメッセージは16,785件あり、言語は22あります。

各エラーが何を取り消すか：PostgreSQLから来た人への罠
PostgreSQLでは、エラーはトランザクション全体を中断します。ここではエラーによって異なり、ほとんどはその文だけを中断します。何もオンにしない状態で測定しました：

BEGIN TRAN;
INSERT padre VALUES (10, 'd@x.es', 1);
INSERT padre VALUES (10, 'e@x.es', 1);  -- Msg 2627
INSERT padre VALUES (11, 'f@x.es', 1);
COMMIT;
-- 行10と11が残った

トランザクションは開いたままで、COMMITはうまくいったものをコミットし、バッチは何事もなかったかのように続きました。測定した各エラーの結果：

- その文だけ：2627、2601、547、515、2628、8134、そして1222も。待機が尽きたあとも@@TRANCOUNTは1のままでした。
- バッチとトランザクション：245（変換）は何もオンにしなくてもトランザクションをロールバックし、バッチを打ち切りました。犠牲者側の1205も同じです。トリガー内のROLLBACKはMsg 3609になり、バッチを打ち切ります。
- 接続：レベル20以上。

SET XACT_ABORT ONで変わる：これをオンにすると、同じ2627がトランザクション全体をロールバックし、バッチを打ち切りました（行20と21は残りませんでした）。トランザクションを開くすべてのプロシージャの先頭に書くものです。

TRY…CATCHと、それが捕捉しないもの

SET XACT_ABORT ON;
BEGIN TRY
  BEGIN TRAN;
  -- …
  COMMIT;
END TRY
BEGIN CATCH
  IF @@TRANCOUNT > 0 ROLLBACK;
  THROW;
END CATCH;

CATCHの中では、ERROR_NUMBER()、ERROR_SEVERITY()、ERROR_STATE()、ERROR_LINE()、ERROR_PROCEDURE()、ERROR_MESSAGE()がエラーの詳細を返します（測定結果：2627、14、1、4、NULL）。そしてXACT_STATE()は、そのトランザクションで何ができるかを示します。XACT_ABORTなしでは1（コミットできる）、ありでは-1（ロールバックしかできない）でした。

TRYが捕捉しないもの：自分のスコープ内に存在しないオブジェクトです。TRY内のSELECT * FROM tabla_que_no_existeは、CATCHを通らずにMsg 208として出てきました。コンパイル時に失敗するからです。EXEC sp_executesqlの中なら捕捉されました。レベル10以下のものも捕捉しません。

THROWとRAISERROR
- CATCHの中で引数なしのTHROW;は元のエラーを再スローします。外に届いた番号は8134のままでした。RAISERROR(ERROR_MESSAGE(), 16, 1)で再スローすると50000に変わり、元の番号は失われました。
- RAISERRORはバッチを止めません。そのあとに書いたものは実行されました。THROWは止めます。
- THROW 50001, 'text', 1は独自のエラーを発生させます。常にレベル16で、番号は50000以上です。RAISERRORはsp_addmessageで登録した番号も受け付け、その引数を埋めます。RAISERROR(50100, 16, 1, 42)はEl pedido 42 no existeになりました。

テキストは言語で変わり、番号は変わらない
SET LANGUAGE Spanishでは、8134はError de división entre cero.として届きました。同じ番号で、テキストが違います。言語はセッションのもので、Calíopeはログインのデフォルトの言語で接続します。だから、コードでも自分のログでも、比較するのは番号で、テキストでは決してありません。

18456：理由はサーバのログにある
失敗したログインは、クライアントには常に同じ形で届きます：Msg 18456, Level 14, State 1、Login failed for user '…'。3つの異なる原因で測定したところ、クライアントには3回ともState 1が見えました。本当の状態はサーバのログにしかありません：

EXEC xp_readerrorlog 0, 1, N'Login failed';

接続時に要求したデータベースが存在しない場合は、18456の前に4060が届き（Cannot open database … requested by the login）、こちらは理由を示します。誰かが「入れない」とき、外からは同じ文に見えるものを、サーバのログなら一瞬で見分けられます。

Calíopeが表示するもの
文が失敗すると、Calíopeはサーバのメッセージを結果タブに全文で、上のMsg, Level, State, Lineの形で表示し、すべてのメッセージを1行に1つずつ表示します。制約名が重複したCREATE TABLEは2714に続けて1750を返し、どちらにも意味があります。それらのエラーはそのタブにとどまります。接続を妨げるもの（18456、4060）と、接続を切断するレベル20以上のものは、Calíopeのエラーログにも届きます。情報メッセージ（PRINT、レベル10のRAISERROR）は表示されません。

推奨事項
トランザクションを開くすべてのプロシージャで、SET XACT_ABORT ONと、IF @@TRANCOUNT > 0 ROLLBACK; THROW;を含むTRY…CATCHを使います。アプリケーションでは1205を再試行し（サーバがすでにロールバックしたトランザクション全体を再試行します）、データやプログラムの問題であるレベル14〜16は再試行しません。常に番号を保存し、テキストは保存しません。そして18456に直面したら、パスワードに触る前にサーバのログを読んでください。

キーワード： エラー、MSG、レベル、重大度、状態、18456、1205、2627、2601、547、208、102、2628、8152、515、229、916、4060、1222、TRY、CATCH、THROW、RAISERROR、xact_abort、xact_state、error_number、SYS.MESSAGES、xp_readerrorlog、再試行

テーブルそのものであるクラスタ化インデックス、キー検索とINCLUDEでそれをなくせる場合、フィルタ付きインデックス、式インデックスの代わりの計算列、列ストア、FILLFACTORと断片化、そして誰も使わないインデックス。

対象： SQL Server 2022+

MySQLから来た人へ：いちばん近いのはInnoDBです。ここでもテーブルはインデックスです。違うのは、そのインデックス（クラスタ化インデックス）を自分で選べて、主キーである必要がないこと、テーブルがそれを持たないこともあること、そしてプレフィックスインデックスや不可視インデックスの代わりに、フィルタ付きインデックス、計算列、列ストアがあることです。

以下はすべて、200,000行、約32 MBのテーブルで測定したものです。

テーブルはクラスタ化インデックス
PRIMARY KEYは、テーブルにまだなければクラスタ化インデックスを作成します。行はそのキーの順に保存されます。クラスタ化インデックスのないテーブルはヒープ（sys.indexesではHEAP）で、行は収まるところに置かれます。

MySQLからは見えないのがその代償です。クラスタ化キーはすべての非クラスタ化インデックスの中に入ります。インデックスはそれを使って行を見つけるからです。cliente_idに対する同じインデックスが、クラスタ化キーがintなら2,952 kB、uniqueidentifierなら5,416 kBでした。狭く、常に増えていくクラスタ化キーは、ほかのすべてのインデックスを安くします。NEWID()がクラスタ化キーとして良くない理由は、「データ型（SQL Server）」の項目で説明しています。

キー検索と、INCLUDEが直すもの
非クラスタ化インデックスが持つのは、自分の列とクラスタ化キーだけです。クエリーがそれ以外の列を求めると、見つかった行ごとにテーブルに戻らなければなりません。それがキー検索（Key Lookup）です。

CREATE INDEX ix_cliente ON dbo.pedidos (cliente_id);
SELECT cliente_id, total FROM dbo.pedidos WHERE cliente_id = 4242;
-- Index Seek (ix_cliente) + Clustered Index Seek … LOOKUP：論理読み取り29

CREATE INDEX ix_cliente_inc ON dbo.pedidos (cliente_id) INCLUDE (total);
-- Index Seek (ix_cliente_inc)だけ：論理読み取り3

INCLUDEは、その列で並べ替えずにインデックスのリーフに保存します。ここではインデックスが2,952 kBから4,752 kBに増えました。

キー検索は1行ごとに払うので、ごく早い段階で割に合わなくなります。測定結果：992行（テーブルの0.5 %）ではプランはまだインデックスとキー検索を使い、1,483行（0.7 %）ではもうテーブル全体をスキャンしていました。「使われない」インデックスは、たいていINCLUDEが足りないインデックスです。

左端のプレフィックスの規則
(fecha, cliente_id)のインデックスとWHERE cliente_id = 77では、SQL Serverはインデックスをたどってシークできません。PostgreSQLと同じく、テーブルより安ければインデックス全体をスキャンできます：Index Scanで論理読み取りは809。Index Seekではなく、列の順序はやはり重要です。

フィルタ付きインデックス
インデックスにはWHEREを付けられ、その場合は条件を満たすものだけをインデックスにします：

CREATE INDEX ix_pend ON dbo.pedidos (cliente_id) WHERE estado = 'pendiente';

未処理の注文が5 %のとき、同じ列の完全なインデックスの2,952 kBに対して160 kBでした。落とし穴は、プランがどんな値にも通用しなければならないことです。リテラルのWHERE estado = 'pendiente'では使われ、変数（WHERE estado = @e）では使われず、WITH (INDEX(ix_pend))で強制するとMsg 8622になります。

そして、MySQLのユーザが驚く使い方がもう1つあります。SQL Serverの一意インデックスは「NULLを1つしか許しません」。メールアドレスがNULLの行が2つあると、CREATE UNIQUE INDEX ux_email ON dbo.pedidos (email)はMsg 1505（The duplicate key value is (<NULL>)）になります。解決策はフィルタ付きインデックスです：

CREATE UNIQUE INDEX ux_email ON dbo.pedidos (email) WHERE email IS NOT NULL;

式インデックスはない：代わりに計算列
WHEREの列に関数をかけると、インデックスをたどってシークできなくなります。ある1か月の同じ14,400行で：

- WHERE YEAR(fecha) = 2023 AND MONTH(fecha) = 6：Index Scan、読み取り510。
- WHERE fecha >= '2023-06-01' AND fecha < '2023-07-01'：Index Seek、読み取り40。

式を範囲に書き直せないときは、計算列にインデックスを作成します：

ALTER TABLE dbo.pedidos ADD email_lower AS LOWER(email);
CREATE INDEX ix_email_lower ON dbo.pedidos (email_lower);

SELECT id FROM dbo.pedidos WHERE LOWER(email) = 'u77@ejemplo.com';
-- Index Seek (ix_email_lower)、計算列の名前を書かずに

そのインデックスを作成するときも、そのあとテーブルに書き込むときも、セッションでQUOTED_IDENTIFIERとANSI_NULLSがオンになっている必要があります。sqlcmdは-Iを渡さないと1つ目をオフにするので、Msg 1934で失敗します。

集計には列ストア
列ストアインデックスは、各列を別々に圧縮して保存します。同じテーブルが、通常のクラスタ化インデックスでは35,520 kB、CLUSTERED COLUMNSTOREでは7,104 kBでした。SELECT estado, SUM(total) … GROUP BY estadoは、前者では4,440ページを読んでCPUを19 ms使い、後者では147ページと2 msでした。キーで1行を探すには、今でも通常のインデックスのほうが優れています。業務用のテーブルでよくあるのは、集計する列でNONCLUSTERED COLUMNSTOREを追加することです（4列のもので3,128 kBでした）。

外部キーは自動ではインデックスにならない
InnoDBは外部キーごとにインデックスを作成しますが、SQL Serverは作成しません。測定結果：cliente_id int REFERENCES dbo.clientes(id)のあと、子テーブルには主キーのインデックスしかありませんでした。そのインデックスがないと、親テーブルでのDELETEのたびに、制約を確かめるために子テーブル全体がスキャンされます。

断片化とFILLFACTOR

SELECT i.name, p.avg_fragmentation_in_percent, p.page_count,
       p.avg_page_space_used_in_percent
  FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('dbo.pedidos'), NULL, NULL, 'DETAILED') p
  JOIN sys.indexes i ON i.object_id = p.object_id AND i.index_id = p.index_id
 WHERE p.index_level = 0;

ランダムな値のcliente_idに対するインデックスを、段階ごとに測定しました：

FILLFACTORは、挿入がページを分割せずに収まるように各ページに余白を残します。初日から容量を使い、あとの断片化を防ぎます。インデックスに保存されたまま残る（sys.indexes.fill_factor）ので、以降のREBUILDでも繰り返されます。REORGANIZEはブロックせずに圧縮し、中断できます。REBUILDはインデックス全体を作り直し、ONLINEなしでは実行中テーブルをロックします。

テーブルを止めずに再構築する

ALTER INDEX ix_cliente ON dbo.pedidos REBUILD WITH (ONLINE = ON, RESUMABLE = ON);

ONLINE = ONはEnterpriseエディションのものです（それと同じDeveloperエディションと、Azure SQLにもあります）。Standardには存在せず、REBUILDは実行中に書き込みを止めます。クラスタ化インデックスなら読み取りも止めます。RESUMABLE = ONで一時停止してあとから続けられ、ONLINE = ONが必要です（なければMsg 11438）。そしてONLINE = ONが失敗するケースが2つあります。テーブルに空間インデックスがある場合と、ALTER INDEX ALLの場合です。

不可視インデックスはない：代わりにDISABLE
ALTER INDEX … DISABLEがいちばん近いものですが、同じではありません。インデックスのデータを削除して定義だけを残すので、元に戻すにはREBUILD全体が必要です。そしてクラスタ化インデックスを無効にすると、テーブルが読めなくなります。SELECT COUNT(*)はMsg 8655になり、ついでにすべての非クラスタ化インデックスも無効にして、それぞれに警告を1つずつ出します。

誰も使わないもの、そして足りないもの

SELECT OBJECT_NAME(i.object_id) AS tabla, i.name AS indice,
       u.user_seeks, u.user_scans, u.user_lookups, u.user_updates
  FROM sys.indexes i
  LEFT JOIN sys.dm_db_index_usage_stats u
    ON u.object_id = i.object_id AND u.index_id = i.index_id
   AND u.database_id = DB_ID()
 WHERE OBJECTPROPERTY(i.object_id, 'IsUserTable') = 1 AND i.index_id > 1
 ORDER BY u.user_seeks + u.user_scans + u.user_lookups;

PostgreSQLよりも注意が必要です。このビューはメモリー上にあり、サーバを再起動すると空になります。測定結果：コンテナを再起動すると、そのテーブルの行は1つもなくなりました。インデックスを無効にしてもリセットされますが、REBUILDではリセットされません。月曜日に読み取り0のインデックスは、まだ誰も使う時間がなかっただけかもしれません。

もう半分は足りないものです。オプティマイザは、欲しかったインデックスをsys.dm_db_missing_index_detailsに記録します。cliente_idとestadoに対するクエリーのあと、推定効果99.6 %で[cliente_id], [estado]を提案しました。これはヒントであって命令ではありません。すでにあるインデックスを見ず、書き込みを考慮せず、空になる同じメモリー上にあります。

推奨事項
狭く、常に増えていくクラスタ化キー。検索や削除に使う外部キーごとにインデックス。プランにキー検索が出たら、別のインデックスより先にINCLUDE。そして「使われていない」インデックスを削除する前に、サーバがどれくらい前に起動したかを確かめてください（sys.dm_os_sys_infoのsqlserver_start_time）。

キーワード： インデックス、クラスタ化、非クラスタ化、ヒープ、キー検索、INCLUDE、フィルタ付きインデックス、計算列、列ストア、FILLFACTOR、断片化、REORGANIZE、REBUILD、ONLINE、RESUMABLE、DISABLE、dm_db_index_usage_stats、dm_db_missing_index_details、dm_db_index_physical_stats

実際にぶつかる制限（1行あたり8,060バイト、インデックスキーの900バイトと1,700バイト、1,024列、128文字の名前、2,100個のパラメータ）、テーブルの作成時には警告するだけであとで失敗するもの、そしてExpressエディションが決めるもの。

対象： SQL Server 2022+

SQL Serverの制限はInnoDBのものとはあまり似ておらず、日々ぶつかるのは大きなものではありません。SQL Server 2025に対して1つずつ発生させました。

実際にぶつかるもの

行はページに収まる。可変長のものを除いて
ページは8 KBで、行はそこに収まらなければなりません：8,060バイトです。固定長の列なら、サーバはテーブルの作成時にこれを確かめます。char(5000)の列が2つあるとMsg 1701になり、行の最小サイズが10,007バイトになると伝えます。

可変長の列では確かめません。同じ行に、いっぱいまで入れたvarchar(8000)の値を2つ（16,000バイト）、何のエラーもなく保存できました。収まらないものは別のページ、ROW_OVERFLOW_DATAに移されます。sys.allocation_unitsには、行内のページが2つ、オーバーフローのページが2つありました。動作はしますが、その行を読むとオーバーフローした列ごとに読み取りが1回増え、設計からはそれが起きていることがわかりません。

SELECT au.type_desc, SUM(au.used_pages) AS pages
FROM sys.allocation_units AS au
JOIN sys.partitions AS p ON au.container_id = p.partition_id
WHERE p.object_id = OBJECT_ID('dbo.my_table')
GROUP BY au.type_desc;

varchar(max)、nvarchar(max)、varbinary(max)は2 GBまで入り、同じようにして行の外に出ます。varchar(8001)が存在せずmaxに飛ばなければならない理由は、「データ型（SQL Server）」の項目で説明しています。

警告するだけの制限：インデックスキー
これがいちばん意外なものです。制限より幅の広い列に対するインデックスは、警告とともに作成されます：

Warning! The maximum key length for a clustered index is 900 bytes. The index 'cx' has maximum length of 1000 bytes.

警告ではデプロイは止まりません。テーブルは、誰かが長い値を保存する日まで動きます。900バイトは入り、901バイトでMsg 1946になりました。非クラスタ化インデックスでは制限は1,700バイトで、nvarcharでは1文字が2バイトなので、1,700文字ではなく850文字です。varchar(1000)に対するPRIMARY KEYはクラスタ化インデックスで、同じように動作します。

長い列で等価検索が必要なら、うまくいくのはダイジェストをインデックスにすることです。CHECKSUMかHASHBYTESを使った計算列にインデックスを作成し、完全な値も比較します。

名前：切り詰めではなくエラー
129文字の名前はMsg 103になり、文は実行されません。PostgreSQLは63バイトに切り詰めて先に進みますが、SQL Serverは名前を通しません。ローカルの一時テーブルの名前はもっと短く、116文字です。サーバがセッションを区別するための接尾辞を付けるからです。

パラメータ：2,100個、実際には2,098個
プロシージャは2,100個のパラメータを受け付け、呼び出しではそれ以上渡せません。しかし、ドライバやORMはパラメータ化クエリーをsp_executesql経由で送り、そこでは文と宣言も数に入ります。2,098個のパラメータは動作し、2,099個でMsg 180になりました。ある日増えたリストから生成したWHERE id IN (@p1, @p2, …)の典型的なエラーです。解決策はリストを分割することではありません。テーブルとして渡し（テーブル値パラメータか一時テーブル）、JOINすることです。文の中に6万個のリテラルを書いたINは動作しました。

もっと多くの列：列セットとSPARSE
1,025列はMsg 1702になります。SPARSE列とCOLUMN_SET FOR ALL_SPARSE_COLUMNSを使って、2,002列のテーブルを作成できました。列セットのない同じ列では、同じMsg 1702になりました。ドキュメントはこれを「ワイドテーブル」と呼んで上限を30,000列に上げていますが、行はやはり8,060バイトに収まらなければなりません。

入れ子：32レベル
自分自身を呼び出すプロシージャは@@NESTLEVELが32に達し、次のレベルでMsg 217になりました。プロシージャ、関数、トリガー、ビューはまとめて数えられます。トリガーのある別のテーブルを更新するトリガーは、誰にも見えないままレベルを使い切ります。

大きなもの。ほとんど問題にはならない
これらは測定していません（テストベッドはDeveloperエディションで、測定するにはディスクをいっぱいにする必要があります）。Microsoftのドキュメントの数値を示します：

- データベースのサイズ：524,272 TB。データファイル1つ：16 TB。
- 1テーブルあたりの行数：ストレージ以外の制限はありません。
- バッチのサイズ：ネットワークパケットサイズの65,536倍（デフォルトは4,096バイトなので256 MB）。
- 接続数：32,767（@@MAX_CONNECTIONS）で、user connectionsが0ならほかの上限はありません。

エディションが決めるもの
ここには実際にぶつかる制限があり、それはエンジンではなくライセンスから来ます。これも測定していません。テストベッドはDeveloperで、制限がないからです。

- Express：SQL Server 2022ではデータベースあたり10 GB、2025では50 GB。バッファプールのメモリーは約1.4 GB。1ソケットか4コアの少ないほう。サイズに達するとデータベースは大きくならず、書き込みが失敗します。
- Standard：データベースのサイズに上限はありませんが、メモリーとコアには上限があり、ONLINE = ONのREBUILDのような一部のEnterpriseの機能がありません。

接続しているサーバがどれかは、SELECT SERVERPROPERTY('Edition')でわかります。

推奨事項
3つに注意してください。テキストの列にインデックスを作るときのインデックスキー（警告するだけだから）、何かがINのリストを生成するときの2,098個のパラメータ、そしてサーバがExpressならデータベースのサイズです。それ以外はエラー番号で知ることになり、その番号は常に何が制限なのかを示しています。

キーワード： 制限、最大、8060、行、ページ、row_overflow_data、オーバーフロー、インデックスキー、900バイト、1700バイト、1024列、SPARSE、column_set、128文字、識別子、一時テーブル、2100パラメータ、sp_executesql、NESTLEVEL、入れ子、Express、10 GB、50 GB、エディション、Msg 1946、Msg 1702、Msg 180

ここではなぜSELECTがUPDATEを待つのか、READ_COMMITTED_SNAPSHOTで何が変わるか、誰が誰をブロックしているかの見方、1205のグラフが保存される場所、そして行ロックがいつテーブルロックに変わるか。

対象： SQL Server 2022+

MySQLやPostgreSQLから来た人がまずつまずくのはこれです：SQL Serverでは、デフォルトでSELECTがUPDATEを待ちます。InnoDBとPostgreSQLは行の最後にコミットされたバージョンを読んで先に進みますが、SQL Serverは素のREAD COMMITTEDでは共有ロックを要求し、相手がコミットするかロールバックするまで待ちます。ここで説明することはすべて、2つのセッションを同時に開いてSQL Server 2025に対して測定したものです。

待つSELECT

-- セッションA
BEGIN TRAN;
UPDATE dbo.cuentas SET saldo = 50 WHERE id = 1;

-- セッションB
SELECT saldo FROM dbo.cuentas WHERE id = 1;

セッションBは7.5秒間止まっていました。ちょうどAがROLLBACKするまでにかかった時間で、その行のキーに対するLCK_M_Sで待っていました。そしてAは何もしている必要はありません。トランザクションを開いて書き込み、そのまま黙ったセッション（statusがsleeping、open_transaction_countが1）でも同じようにブロックします。これが日常のケースです：COMMITを忘れたアプリケーション。

READ_COMMITTED_SNAPSHOT：ほかの2つと同じように読む

ALTER DATABASE my_db SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;

このオプションを使うと、READ COMMITTEDは行の最後にコミットされたバージョンを読み、同じ読み取りがすぐに古い値で返ってきました（コミットされていない50ではなく100）。オンにする前に3つのこと：
- これはセッションではなくデータベースのもので、オフの状態で来ます。新しく作成したデータベースでも、modelでも、私の検証環境のdemoでも、is_read_committed_snapshot_onは0です。
- WITH ROLLBACK IMMEDIATEがないと、ALTERは待ちます。データベースにほかのセッションが残っていなくなるまでです。1つ接続していると14.5秒待ちました。そのセッションが出ていくまでにかかった時間です。これを付けると、ほかのセッションを追い出し、そのトランザクションをロールバックします。
- 変わるのは読む側だけです。同じ行への2つの書き込みは、今でも互いを待ちます。セッションBのUPDATEは以前とまったく同じように待ちました。

誰が誰をブロックしているか
ブロックが続いている間に問い合わせます：

SELECT r.session_id, r.blocking_session_id, r.wait_type,
       r.wait_time, r.wait_resource
FROM sys.dm_exec_requests AS r
WHERE r.blocking_session_id <> 0;

SELECT request_session_id, resource_type, resource_description,
       request_mode, request_status
FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID();

1つ目は、実際に知りたいことに答えます。blocking_session_idは、このセッションが求めているものを握っているセッションです。2つ目ははしご全体を見せます。行を更新する側はキーにX、ページとテーブルにIXを持ち、待っている側はrequest_statusがWAITで表示されます。PostgreSQLと違い、ここでは行ロックが実際に一覧に、1行に1つずつ表示されます。

Calíopeの「プロセス」の一覧は「状態」列に待機を表示しますが（ブロックされたセッションはLCK_M_S、LCK_M_U、LCK_M_Xで表示されます）、誰がブロックしているかは表示しません。それは1つ目のクエリーでわかります。そして「KILL CONNECTION」は、ここでほかのセッションのロックを解放する唯一の方法です。KILLはセッション全体を閉じてそのトランザクションをロールバックします。SQL Serverでは、ほかのセッションのクエリーだけをキャンセルすることはできないからです。

UPDLOCK：ここでのFOR UPDATE
SELECT … FOR UPDATEはありません。その役目はヒントが果たします：

BEGIN TRAN;
SELECT saldo FROM dbo.cuentas WITH (UPDLOCK, ROWLOCK) WHERE id = 1;
UPDATE dbo.cuentas SET saldo = saldo - 100 WHERE id = 1;
COMMIT;

これはUロックを取ります。ほかのセッションからの通常の読み取りは待たずに通り、UPDLOCK付きの別の読み取りは待たされました。そして、いちばんばかげたデッドロックを防ぎます。REPEATABLE READの2つのセッションが同じ行を読んでから更新すると1205で終わりましたが、読み取りにUPDLOCKを付けると、2つとも順番に完了しました。

ここでも待機は無期限
@@LOCK_TIMEOUTは-1、つまり制限なしです。PostgreSQLのlock_timeoutと同じで、InnoDBの50秒とは違います。セッションごとに、ミリ秒単位で設定します：

SET LOCK_TIMEOUT 3000;

発動するとMsg 1222になり、何もロールバックしません。トランザクションは開いたままで、受け取った側がロールバックしなければなりません。各エラーが何をロールバックするかは、「エラー（SQL Server）」の項目で説明しています。

わざと待たない

SELECT saldo FROM dbo.cuentas WITH (NOWAIT) WHERE id = 3;

SELECT id FROM dbo.cuentas WITH (READPAST) WHERE id BETWEEN 1 AND 5;

NOWAITは同じ1222ですぐに失敗し、バッチは続きます。READPASTはここでのSKIP LOCKEDです。ほかのセッションが行3をロックしているとき、1、2、4、5を返しました。複数のコンシューマが互いを待たずに作業キューを共有する方法です。

NOLOCKは存在しなかったものを読む

SELECT saldo FROM dbo.cuentas WITH (NOLOCK) WHERE id = 3;

ほかのセッションが、あとでロールバックしたUPDATEの途中にあるとき、この読み取りは50を返しました。一度もコミットされなかった残高です。NOLOCKはREAD UNCOMMITTEDであり、「速く読む」ことではありません。ほかのトランザクションがまだ捨てるかもしれないものを読むことです。ドキュメントによると、読んでいる間にページが分割されると、行を飛ばしたり2回読んだりすることがあります。私はそれを再現していません。待たない読み取りが欲しいなら、答えはREAD_COMMITTED_SNAPSHOTです。待たず、コミットされたデータだけを見ます。

命取りの抱擁

-- セッションA
BEGIN TRAN;
UPDATE dbo.cuentas SET saldo = saldo - 10 WHERE id = 1;
UPDATE dbo.cuentas SET saldo = saldo + 10 WHERE id = 2;

-- セッションB
BEGIN TRAN;
UPDATE dbo.cuentas SET saldo = saldo - 10 WHERE id = 2;
UPDATE dbo.cuentas SET saldo = saldo + 10 WHERE id = 1;

2つのうち一方がMsg 1205（レベル13、… has been chosen as the deadlock victim. Rerun the transaction.）を受け取り、トランザクションとバッチの残りを失います。もう一方はコミットします。すぐには検出されません。6回実行したところ、循環が閉じてから犠牲者が倒れるまで0.1秒から4.8秒かかりました。ドキュメントがその幅を説明しています。モニタが5秒ごとに循環を探し、1つ見つけた直後はもっと頻繁に探すのです。

どちらが倒れるかは決められます。セッションAでSET DEADLOCK_PRIORITY HIGHにすると、3回ともBが犠牲者になりました。LOWは繰り返せるバッチ処理に向いています。1205は障害ではありません。アプリケーションがそのトランザクションを再試行しなければなりません。

グラフはすでに保存されている
オンにするものは何もありません。最初から動いているsystem_health拡張イベントセッションが、すべてのデッドロックをそのグラフとともに保存しています。誰が倒れたか、それぞれがどの文を実行していたか、どのインデックスのどのキーを待っていたか。

SELECT CAST(event_data AS xml) AS grafo
FROM sys.fn_xe_file_target_read_file('system_health*.xel', NULL, NULL, NULL)
WHERE object_name = 'xml_deadlock_report';

測定したことが2つあります。ファイルは遅れます。6つ発生させた直後には2つしかなく、数秒後にはすべてありました。そしてすぐにそれらを持っているセッションのring_bufferはメモリー上にあります。サーバを再起動すると、新しいものは持っていましたが以前のものは失っていて、ファイルにはまだ残っていました。

行からテーブルへ：エスカレーション
ロックはそれぞれメモリーを使い、1つの文が1つのテーブルにロックを溜めすぎると、SQL Serverはそれをテーブル全体に対する1つのロックに置き換えます。20,000行のテーブルの先頭N行を更新して数えました：
- 6,200行までは、キーに対するXロックが6,200個。
- 6,300行からは1つだけ：ページを経ずにテーブルにX。そして、誰も触れていない行20,000を取りに行った別のセッションは、LOCK_TIMEOUTまで待ちました。

ドキュメントの数値は5,000で、ここでは少し遅れて切り替わりました。REPEATABLE READでの8,000行のSELECTも、テーブルにSという同じ結果になりました。これはテーブルごとに制御します：

ALTER TABLE dbo.cuentas SET (LOCK_ESCALATION = DISABLE);

これで、20,000行すべてに対する同じUPDATEは、20,000個のキーロックを持ち、テーブルには1つも持ちませんでした。TABLEがデフォルトです。AUTOは、ドキュメントによると、パーティション分割されたテーブルではパーティションにエスカレーションします。オフにするのはただではありません（ロックはどれもサーバのメモリーです）。よくある解決策は別のものです：5,000行未満のまとまりで書き込むことです。

アプリケーションロック
PostgreSQLのアドバイザリーロックに相当するものです。アプリケーションの2つのプロセスが同じことを同時にしないように、サーバが保持する名前です。

DECLARE @r int;
EXEC @r = sp_getapplock @Resource = 'cierre-diario', @LockMode = 'Exclusive',
     @LockOwner = 'Session', @LockTimeout = 0;
-- …
EXEC sp_releaseapplock @Resource = 'cierre-diario', @LockOwner = 'Session';

リソースをほかのセッションが保持していると、待たずに-1を返しました。0は「許可された」という意味です。エラーにはならないので、番号を確かめる必要があります。デフォルトの@LockOwner = 'Transaction'では、トランザクションが終わると自動で解放され、トランザクションの外で要求すると-999を返しました。

推奨事項
どのエンジンでもそうであるように、行には常に同じ順序で触れ、トランザクションは短くします。ここに固有なのは3つです。アプリケーションが許すならすぐにREAD_COMMITTED_SNAPSHOTをオンにすること（読み取りが書き込みを待たなくなり、NOLOCKの誘惑がなくなります）。UPDATEで終わる読み取りにはUPDLOCK。そして1205の再試行を、本番環境に出る前に書いておくことです。

キーワード： ロック、デッドロック、ブロッキング、1205、1222、LCK_M_S、blocking_session_id、dm_tran_locks、dm_exec_requests、read_committed_snapshot、RCSI、NOLOCK、READPAST、UPDLOCK、NOWAIT、lock_timeout、deadlock_priority、エスカレーション、lock_escalation、system_health、sp_getapplock

DDLはトランザクション対応で、コストはSch-Mロックとそれが作る待ち行列であること、テーブルを書き直すALTER、ONLINE、RESUMABLE、WAIT_AT_LOW_PRIORITY、そしてここではなぜWITH NOCHECKでロックが軽くならないか。

対象： SQL Server 2022+

MySQLから来た人へ：まず、ここのDDLはPostgreSQLと同じくトランザクション対応です。PostgreSQLから来た人にとって変わるのは、ロックの名前と、PostgreSQLにはないいくつかのツールです。ここで説明することはすべて、200,000行のテーブルでSQL Server 2025に対して測定したものです。

BEGIN TRAN;
ALTER TABLE dbo.pedidos ADD moneda char(3) NULL;
CREATE INDEX ix_cliente ON dbo.pedidos (cliente);
CREATE TABLE dbo.monedas (codigo char(3) PRIMARY KEY);
EXEC sp_rename 'dbo.pedidos.nota', 'comentario', 'COLUMN';
ROLLBACK;

そのROLLBACKのあとには何も残りませんでした。列も、インデックスも、テーブルもなく、列の名前はnotaに戻っていました。移行全体が1つのトランザクションに収まります。見つかった例外：CREATE DATABASEとALTER DATABASE（Msg 226）、そしてRESUMABLEのインデックス（Msg 574）はトランザクションの中に入れられません。

コストはSch-Mと、それが作る待ち行列
ALTER TABLEはどれも、スキーマ変更ロックSch-Mを要求します。これはSELECTを含めすべてと競合します。危険なのは数ミリ秒で終わるかもしれないALTERではなく、待機です。ほかのセッションが、1行だけに触れたトランザクションの途中にあるとき：
- ALTER TABLE … ADDは7秒待ちました。wait_typeはLCK_M_SCH_Mです。
- そのうしろで始まった別の行のSELECTはLCK_M_SCH_Sで6秒待ち、そのblocking_session_idはトランザクションではなくALTERでした。

こうして1ミリ秒の変更がアプリケーション全体を止めます。対策はPostgreSQLと同じです：

SET LOCK_TIMEOUT 3000;
ALTER TABLE dbo.pedidos ADD moneda char(3) NULL;

3秒でALTERはMsg 1222になり、そのうしろのSELECTはその瞬間に通りました。あとで再試行します。

テーブルを書き直すもの、書き直さないもの
200,000行（1,364ページ）で測定しました。証拠は、それぞれの文が書いたトランザクションログです：

読み方：
- すべての行で同じデフォルト（定数、または一度だけ評価されるSYSDATETIME()）はメタデータに保存され、行には触れません。NEWID()は行ごとに違う値を与えるので、すべての行を書かざるを得ません。
- varcharを広げるのはただです。狭める、ファミリーを変える（nvarchar、max）、整数を大きくする、NOT NULLにする、decimalのディスク上のサイズを変える、これらはどれも書き直します。decimal(10,2)とdecimal(12,2)は同じ9バイトを使うので、あの変更は書き直しませんでした。
- 書き直すものはすべて、テーブルを2倍のサイズにします。それらの文のあと、テーブルは1,364ページから2,723ページになり、そのままでした。古い列がすべての行で場所を取ったままだからです。int → bigintのあと、ALTER TABLE dbo.pedidos REBUILDで1,495ページになりました。そしてDROP COLUMNが一瞬で終わるのは何も解放しないからです。前もあとも1,364ページで、REBUILDのあとで1,075ページでした。

PostgreSQLにはない障害が2つあります：
- インデックスのある列は型を変えられません。estadoにインデックスがあると、varchar(100)への変更は書き直さないので動作しましたが、varchar(30)とnvarchar(100)はMsg 5074（The index 'ix_estado' is dependent on column 'estado'）になりました。インデックスを削除し、列を変更して、インデックスをもう一度作成します。
- DEFAULTは名前の付いた制約で、それがある間は列を削除できません。同じMsg 5074になり、SQL Serverが自分で名前を付けたDF__pedidos__moneda__…という制約が示されます。先にALTER TABLE … DROP CONSTRAINTで削除します。だから、作成するときに名前を付けておく価値があります。

ドキュメントはエディションの条件を加えています。メタデータだけに触れるADD COLUMN … NOT NULL DEFAULTはEnterpriseの機能で、Standardではテーブルを書き直します。私の検証環境は、Enterpriseの機能をすべて持つDeveloperなので、それは測定できませんでした。

オンラインのインデックス：ONLINE = ON

ALTER INDEX ALL ON dbo.grande REBUILD WITH (ONLINE = ON);
CREATE INDEX ix_g ON dbo.grande (g) WITH (ONLINE = ON);

3,000,000行で、オンラインの再構築は47秒かかり、途中で始めたUPDATEは0.5秒で終わりました。ONLINEなしでは、その間ずっとテーブルがロックされたままです。ALTER COLUMNもこれを受け付けます（ALTER TABLE … ALTER COLUMN n bigint NOT NULL WITH (ONLINE = ON)）。228 msではなく395 msかかりましたが、テーブルは2倍にならず1,483ページのままでした。

3つの制限：
- テーブルに空間インデックスがあると、ALTER INDEX ALL … WITH (ONLINE = ON)はMsg 153で失敗し、空間インデックス自体もオンラインでは再構築できません。主キーと通常のインデックスは、1つずつならできます。
- ONLINEはロックがないという意味ではありません。開始時にテーブルにSロックを要求し、ドキュメントによると終了時には短いSch-Mを要求します。テーブルにトランザクションが開いていると、オンラインのREBUILDはSを待ち続け、そのうしろに来たUPDATEは待ち行列で6.6秒待ちました（LCK_M_IX）。SELECTは通りました。
- ドキュメントによると、ONLINE = ONはEnterpriseのもので、Standardではエラーになります。

WAIT_AT_LOW_PRIORITY：待ち行列を作らずに待つ
これはPostgreSQLにはありません。再構築は別の待ち行列でロックを待ち、うしろに来るものの邪魔をしません：

ALTER INDEX ALL ON dbo.pedidos REBUILD WITH (ONLINE = ON (
    WAIT_AT_LOW_PRIORITY (MAX_DURATION = 1 MINUTES, ABORT_AFTER_WAIT = SELF)));

同じトランザクションが開いたままで、そのうしろのUPDATEは0.5秒で通り、REBUILDはLCK_M_S_LOW_PRIORITYで待機中と表示されました。MAX_DURATIONが過ぎると、ABORT_AFTER_WAITが決めます：
- SELF：REBUILDがMsg 1222であきらめ、トランザクションは続きます。慎重なのはこれです。
- BLOCKERS：1分後、ブロックしていたセッションが接続を切断され（… disconnected because of a high priority DDL operation）、そのトランザクションはロールバックされました。REBUILDは完了しました。
- NONE：低い優先度で無期限に待ちます。

ALTER INDEX … REBUILDはこれを受け付け、私の2025ではCREATE INDEX … WITH (ONLINE = ON (WAIT_AT_LOW_PRIORITY …))も受け付けます。ALTER TABLEは受け付けません。ADD、ALTER COLUMN、ADD CONSTRAINTでは構文エラー（Msg 155）になります。それらに残るのはLOCK_TIMEOUTだけです。

再開可能なインデックス：RESUMABLE = ON

CREATE INDEX ix_relleno ON dbo.grande (relleno, g) WITH (ONLINE = ON, RESUMABLE = ON);
-- 別のセッションから：
ALTER INDEX ix_relleno ON dbo.grande PAUSE;
SELECT name, state_desc, percent_complete FROM sys.index_resumable_operations;
ALTER INDEX ix_relleno ON dbo.grande RESUME;

4秒で構築を一時停止しました。それを始めたセッションは接続を切断され（Msg 1219）、sys.index_resumable_operationsはPAUSEDと5 %を示し、インデックスはまだ存在しませんでした（sys.indexesにありませんでした）。RESUMEが残りを45秒で終えました。巨大なインデックスを、いくつかのメンテナンス時間帯に分けて作れます。ONLINE = ONが必要で（なければMsg 11438）、トランザクションの中には入れられず（Msg 574）、ドキュメントによると、SQL Server 2022からは主キーまたは一意キーのALTER TABLE … ADD CONSTRAINTでも使えます。2025では一意キーで確かめました。

WITH NOCHECK：ここではロックは軽くならない
PostgreSQLのNOT VALID + VALIDATEのパターンにはここにも双子がありますが、同じことはしません。3,000,000行で：

ALTER TABLE dbo.grande WITH NOCHECK ADD CONSTRAINT ck_id CHECK (id > 0);  -- 13 ms
ALTER TABLE dbo.grande WITH CHECK CHECK CONSTRAINT ck_id;                 -- 346 ms

一度に追加すると375 msかかりました。そして3つとも、検証も含めて、テーブルにSch-Mを取りました。2つに分けるとスキャンは分散されますが、PostgreSQLのように後半のためのもっと弱いロックはありません。

そして罠を残します。WITH NOCHECKで追加した制約は信頼されていない（is_not_trusted = 1）ので、オプティマイザはそれに頼りません。信頼されたCHECK (importe >= 0)があれば、WHERE importe < 0はテーブルを読みさえしませんでしたが、信頼されていないと論理読み取りは1,364でした。無効にしてからWITH CHECKなしで有効に戻したときも同じです（ALTER TABLE … CHECK CONSTRAINT ck_importeのあとも信頼されていないままでした）。一括読み込みがよくやることです。それを見つけるには：

SELECT name FROM sys.check_constraints WHERE is_not_trusted = 1;
SELECT name FROM sys.foreign_keys WHERE is_not_trusted = 1;

Calíopeでは
「テーブルメンテナンス」のOPTIMIZE操作は、SQL ServerではONLINEなしのALTER INDEX ALL … REBUILDです。再構築している間、テーブルをロックします。本番環境の大きなテーブルでは、エディタでREBUILD WITH (ONLINE = ON (WAIT_AT_LOW_PRIORITY …))を書いたほうがよいでしょう。

推奨事項
すべてのALTER TABLEの前にSET LOCK_TIMEOUT。移行はトランザクションの中で。インデックスにはWAIT_AT_LOW_PRIORITY … SELF付きのONLINE = ON。それぞれのDEFAULTにはきちんとした名前を。そして型の変更には注意してください。テーブルを書き直し、次のREBUILDまで2倍のサイズのままにします。大きな列を狭めたりファミリーを変えたりする必要があるなら、たいていは新しい列を追加し、まとまりごとにコピーして、sp_renameで名前を変えるほうがうまくいきます。

キーワード： DDL、ALTER TABLE、移行、トランザクション対応、ロールバック、SCH-M、LCK_M_SCH_M、lock_timeout、ONLINE、RESUMABLE、wait_at_low_priority、abort_after_wait、REBUILD、書き直し、ADD COLUMN、ALTER COLUMN、DROP COLUMN、WITH NOCHECK、is_not_trusted、sp_rename

パーティション関数とパーティション構成、オプティマイザが実際に除外するもの、一意インデックスがキーを含まなければならない理由、ミリ秒で削除するためのSWITCHとTRUNCATE、データの読み込みに必要な信頼されたCHECK、そして空のパーティションでしかただではないSPLITとMERGE。

対象： SQL Server 2022+

MySQLやPostgreSQLから来た人にとって変わるのは形です。ここではパーティションはテーブルではなくテーブルの一部で、その配置はテーブルより先に作成する2つのオブジェクトで記述します。ここで説明することはすべて、3年分に散らばる300,000件の売上でSQL Server 2025に対して測定したものです。

CREATE PARTITION FUNCTION pf_anio (date)
    AS RANGE RIGHT FOR VALUES ('2024-01-01', '2025-01-01', '2026-01-01');

CREATE PARTITION SCHEME ps_anio
    AS PARTITION pf_anio ALL TO ([PRIMARY]);

CREATE TABLE dbo.ventas (
    id bigint IDENTITY NOT NULL,
    creado date NOT NULL,
    cliente int NOT NULL,
    importe decimal(10,2) NOT NULL,
    CONSTRAINT pk_ventas PRIMARY KEY CLUSTERED (creado, id)
) ON ps_anio (creado);

関数が境界を決め、構成がそれぞれの部分をどのファイルグループに置くかを示します。3つの境界で4つのパーティションになります。2024年より前のすべて、続く2年のそれぞれ1年分、そして2026年以降のすべてです。LISTやHASHはなく、範囲だけです。そして未来を予測する必要はありません。最初の境界より前や最後の境界よりあとに来るものにも、常に置き場所があります。

RANGE RIGHTかRANGE LEFTか：境界がどちら側に入るか
RIGHTでは、境界はその右側のパーティションに属します。日付には自然な選択です。$PARTITION.pf_anio('2023-12-31')は1を返し、'2024-01-01'は2を返しました。同じ境界でLEFTにすると、1月1日は2023年のパーティションに入りました。何も失敗しません。ある日のデータが違う年に入るだけです。$PARTITIONは数えるのにも便利です：

SELECT $PARTITION.pf_anio(creado) AS particion, COUNT(*) AS filas
FROM dbo.ventas GROUP BY $PARTITION.pf_anio(creado);

肝心なのはパーティションの除外
実際のプラン（SET STATISTICS XML ON、RunTimePartitionSummaryの下）は、各クエリーがいくつのパーティションを読んだかを示します：

そこから読み取れることが2つあります：
- 変数やパラメータでも除外されます。コンパイル時ではなく実行時に決まるからです。だから推定プランには数が出ません。キーがフィルタにあれば[PtnId1000] >= RangePartitionNew(…)、なければ[PtnId1000] >= (1) AND [PtnId1000] <= (4)と表示されます。
- 列に関数をかけると、インデックスから隠れるのと同じように除外からも隠れます。YEAR(creado)は4つすべてを読みました。手で書いた範囲（>= '2024-01-01' AND < '2025-01-01'）は1つだけ読みます。

設計の規則はほかのエンジンと同じです：パーティションキーは、ほとんど毎回フィルタに使う列です。クエリーがそれに触れなければ、パーティション分割は読み取りを減らさず、散らすだけです。

アラインされたインデックスと一意性
ONなしで作成したインデックスはテーブルの構成を受け継ぎます。アラインされたインデックスで、パーティションごとに1つの部分を持ちます。その結果はPostgreSQLと同じです：

CREATE UNIQUE INDEX ux_id ON dbo.ventas (id);

これはMsg 1908を返しました。パーティション分割の列は、一意インデックスのキーの一部でなければなりません。ここにはPostgreSQLにはない逃げ道があります（ON [PRIMARY]でアラインされていないインデックスとして作成する）が、代償があります。そのようなインデックスがあると、下で説明するSWITCHが動かなくなります（Msg 7733）。だからdbo.ventasの主キーは(id)ではなく(creado, id)なのです。

SWITCHとTRUNCATE：1年分をミリ秒で削除する
2023年のすべて、100,009行を削除するのを、トランザクションの中で測定しました：

SWITCHはデータを動かしません。1つの部分を丸ごと別の持ち主に渡します。だから移動先のテーブルに多くを求め、それぞれの条件にはエラーがあります：
- 空であること：1行あるとMsg 4905。
- 同じ列と同じインデックス：列が1つ多いとMsg 4943。
- そして、ドキュメントによると、パーティションと同じファイルグループにあること。

データの読み込みには信頼されたCHECKが必要
これがPostgreSQLとの違いです。PostgreSQLではCHECKはスキャンを1回省くだけです。CHECKなしでテーブルをパーティションに戻すと、時間が長くかかるのではなく、Msg 4982で拒否されます。制約があると9.5 msで入りました：

ALTER TABLE dbo.ventas_2023 WITH CHECK
    ADD CONSTRAINT ck_2023 CHECK (creado < '2024-01-01');
ALTER TABLE dbo.ventas_2023 SWITCH TO dbo.ventas PARTITION 1;

そして信頼されている必要があります。無効にしてからWITH CHECKなしで有効に戻すと（多くの一括読み込みがすること）、SWITCHはMsg 4972を返しました。WITH CHECK CHECK CONSTRAINTのあとは入りました。こうして稼働中のテーブルに触れずに新しい期間を読み込みます。別のテーブルを埋め、CHECKを付けて、SWITCHで入れるのです。

SPLITとMERGE：空のパーティションでだけただ
境界は関数で動かします：

ALTER PARTITION SCHEME ps_anio NEXT USED [PRIMARY];
ALTER PARTITION FUNCTION pf_anio() SPLIT RANGE ('2027-01-01');

データの入ったパーティションを分割すると、境界の片側にある行が移動し、それぞれがログを書きます。コストは移動するものに比例して増えます。健全な習慣は、常に最後に空のパーティションを1つ置いておき、次の期間のデータが来る前にそれを分割することです。そしてSPLITはそのたびにNEXT USEDを使い切ります。もう一度宣言しないと、次のSPLITはMsg 7710を返し、何も変えませんでした。

パーティションごとのメンテナンス
変わるパーティションだけを再構築します：

ALTER INDEX pk_ventas ON dbo.ventas REBUILD PARTITION = 2 WITH (ONLINE = ON);

4つすべての214 msに対して、パーティション1つなら33 ms（オンラインで148 ms）でした。締めた年にはもう書き込みがありません。毎晩再構築する理由はありません。

ロックのエスカレーションをパーティションごとに
デフォルト（LOCK_ESCALATION = TABLE）では、2024年の16,440行のUPDATEがテーブル全体のXロックにエスカレーションし、ほかのセッションから2025年の行を更新するとMsg 1222になりました。次のようにすると

ALTER TABLE dbo.ventas SET (LOCK_ESCALATION = AUTO);

エスカレーションはパーティションにとどまり（HOBTにX）、2025年の行は9 msで更新されました。ドキュメントは、異なるパーティションでエスカレーションするセッションの間でAUTOがデッドロックを招くことがあると警告しています。エスカレーションのそれ以外のことは「ロックとデッドロック（SQL Server）」にあります。

SWITCHもSch-Mを取る
1行だけに触れたトランザクションが開いていると、SWITCHはSch-Mを待ち続け、そのあとに実行した別の行のSELECTはSWITCHのうしろの待ち行列で待ちました。対策はインデックスと同じです：

ALTER TABLE dbo.ventas SWITCH PARTITION 1 TO dbo.ventas_2023
    WITH (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 1 MINUTES, ABORT_AFTER_WAIT = SELF));

うしろのSELECTは0.5秒で終わり、SWITCHは61秒後にMsg 1222であきらめ、トランザクションには手を出しませんでした。その待ち行列のそれ以外のことは「オンラインでのスキーマ変更（SQL Server）」にあります。

制限とエディション
1つの関数で15,000個のパーティションが可能です。15,000個の境界ではMsg 7719になります。ドキュメントによると、パーティション分割はSQL Server 2016 SP1から、Expressを含むすべてのエディションにあります。

Calíopeでは
パーティション分割されたテーブルの行数とサイズは、すべてのパーティションの合計です。Calíopeが書くCREATE TABLE（テーブルのDDLとして表示するものと、「バックアップ」が保存するもの）の前には、それぞれIF NOT EXISTS付きのパーティション関数とパーティション構成が置かれ、最後はON ps_anio (creado)で終わります。[PRIMARY]上の非クラスタ化主キーのようにアラインされていないインデックスは、自分のONを保ちます。そのバックアップを空のデータベースに復元すると、同じようにパーティション分割され、各行は自分のパーティションに入ります。復元先にすでに同じ名前の関数があれば、既存のものがその境界とともに使われます。「スキーマ比較」はパーティション分割も見ます（テーブルがどこにあるか、各構成の境界）が、そのスクリプトは、すでにあるテーブルをパーティション分割したり、パーティション分割を解除したりはしません。それにはデータの入ったクラスタ化インデックスを再構築する必要があるので、あなたが行うための注記としてスクリプトに書かれます。Calíopeが表示するプランは推定プランなので、パーティションについては上のPtnId1000の形になります。実際にいくつ読まれたかは、実際のプラン、SET STATISTICS XML ONにしかありません。

推奨事項
削除するものでパーティション分割してください。本当の利点は、ログをいっぱいにするDELETEの代わりに、SWITCHかTRUNCATE … WITH (PARTITIONS)で期間を削除することです。主キーと一意インデックスにはパーティションキーを含め、すべてをアラインしたままにします。日付にはRANGE RIGHT。最後には常に空のパーティションを置いて、ただで分割できるようにします。そして、クエリーがパーティションを除外しているかどうかを、思い込まずに実際のプランで確かめてください。

キーワード： パーティション分割、パーティション、パーティション関数、パーティション構成、RANGE RIGHT、RANGE LEFT、$PARTITION、パーティションの除外、アライン、SWITCH、TRUNCATE、SPLIT RANGE、MERGE RANGE、NEXT USED、lock_escalation、1908、4982、7733

時間ではなく論理読み取り、推定プランと実際のプラン、パラメータスニッフィングと測定したその対策、「スロークエリー」が読むプランキャッシュ、最初からオンになっているクエリーストア、そして本当に何かを語る待機。

対象： SQL Server 2022+

MySQLやPostgreSQLから来た人にとって、ここでは3つのことが変わります。比べる数値は時間ではなく論理読み取りであること。プランはキャッシュされてほかの値でも再利用され、それが「昨日は問題なかった」の半分の原因であること。そしてpg_stat_statementsに相当するものは何もオンにしなくても最初からありますが、再起動すると失われること。ここで説明することはすべて、200,000件の注文でSQL Server 2025に対して測定したものです。

クエリーを測る：論理読み取り

SET STATISTICS IO, TIME ON;
SELECT COUNT(*), SUM(importe) FROM dbo.pedidos WHERE cliente_id = 4243;
SET STATISTICS IO, TIME OFF;

論理読み取り1回は、メモリーから読んだ8 kBのページ1つです。比べるべき数値はこれです。時間は負荷やキャッシュで変わりますが、これは変わらないからです。ある顧客の20件の注文で：
- インデックスなし：論理読み取り6,085（テーブル全体）、12 ms。
- cliente_idにインデックスあり：読み取り62。

Calíopeではそれらの行は表示されません。サーバはそれを情報メッセージとして送り、エディタが表示するのは行とエラーで、メッセージではないからです。同じ数値は、クエリーを実行した直後にプランキャッシュから読めます：

SELECT TOP (5) qs.last_logical_reads, qs.last_elapsed_time AS micros, st.text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
WHERE st.text LIKE N'%cliente_id = 4243%'
ORDER BY qs.last_execution_time DESC;

結果は62で、STATISTICS IOと同じでした。

推定プランと実際のプラン
SET SHOWPLAN_XML ONはクエリーを実行せずにプランを要求します。SET STATISTICS XML ONは実行して、起きたことを加えます。すべての演算子でEstimateRowsの横にActualRowsが付きます。文が書き込みをするなら、本当に実行されるので、BEGIN TRAN … ROLLBACKで囲んでください。

Calíopeの「実行計画ビューア」は推定プランを要求します。推定行数の演算子ツリーで、実際の行数も、時間も、コストもありません。形は見えます（Seekを期待したところにIndex Scanがある、など）。推定と現実を比べるには、実際のプランが必要です。

パラメータスニッフィング
プロシージャやパラメータ化クエリーが初めて実行されるとき、オプティマイザは渡された値を見て、その値に合わせてプランをコンパイルします。そのプランはキャッシュに残り、以降の実行は別の値が来てもそれを再利用します。プロシージャと2人の顧客で再現しました。注文が20件の顧客と100,000件の顧客です。

CREATE OR ALTER PROCEDURE dbo.pedidos_de @cliente int AS
  SELECT SUM(importe) AS total, COUNT(*) AS n
  FROM dbo.pedidos WHERE cliente_id = @cliente;

小さな顧客向けにコンパイルされたプランは、インデックスをシークして1行ずつテーブルに行きます。20行には完璧ですが、100,000行では読み取りが300,000回になり、テーブル全体をスキャンするより50倍多くなります。逆にコンパイルされると、小さな顧客がテーブル全体をスキャンします。決めるのは到着の順番で、再起動や統計情報の変化でそれが逆転します。だから「昨日は問題なかった」のです。

実際のプランを見れば推測せずにわかります。悪いケースではEstimateRows="20"とActualRows="100000"と示し、パラメータの中にParameterRuntimeValue="(1)"と並んでParameterCompiledValue="(4243)"がありました。

対策として試したもの：
- OPTION (RECOMPILE)：クエリーの最後に付けます。62と6,085になり、値ごとに専用のプランが使われます。代償は呼び出しのたびにコンパイルすることで（ここでは2〜3 ms）、1秒に何千回も実行されるクエリーではただではありません。
- OPTION (OPTIMIZE FOR UNKNOWN)：平均的な値（約20行）に合わせてコンパイルし、70と306,429になりました。とても大きな値が1つあるときには役に立ちません。
- EXEC sp_recompile 'dbo.pedidos_de'：プロシージャのプランを捨てます。その場しのぎであって、対策ではありません。
- SQL Server 2022からは、互換性レベル160以上で、サーバが値に応じて同じクエリーに複数のプランを持てます。デフォルトでオンですが、100,000行対20行では発動しませんでした。200,000行対1行では発動し、プランが2つになりました。当てにしないでください。

いちばんコストのかかるクエリー：プランキャッシュ
サーバは、キャッシュしたすべてのプランの数値を記録しています。実行回数、時間、読み取り、行数です。query_hashはクエリーの形でまとめます。顧客番号だけが違う5つのSELECTをそれぞれ単独で実行すると、キャッシュには5つのプラン（80 kB）と、ただ1つのquery_hashが残りました。

SELECT TOP (20) CONVERT(varchar(20), qs.query_hash, 1) AS forma,
       SUM(qs.execution_count) AS ejecuciones,
       SUM(qs.total_elapsed_time) / 1000 AS ms_total,
       SUM(qs.total_logical_reads) AS lecturas
FROM sys.dm_exec_query_stats AS qs
GROUP BY qs.query_hash
ORDER BY SUM(qs.total_elapsed_time) DESC;

それがCalíopeの「スロークエリー」の「SQL文ごと」表示に出るものです。形ごとに1行で、いちばんコストの高いプランのテキストを付け、サーバのすべてのデータベースから集めます。VIEW SERVER STATE権限が必要です。そして履歴は残りません。サーバを再起動すると、ビューは23行から0行になりました。プランがキャッシュから外れたときも残りません。

すでにオンになっているクエリーストア
クエリーストアは永続するほうです。テキスト、プラン、数値を、間隔ごとにデータベース自体の中に保存します。SQL Server 2025では、誰も頼んでいないのに、demoでも新しく作成したデータベースでもオン（READ_WRITE）になっていました。ドキュメントによると、SQL Server 2022から新しいデータベースではそうなっています。

SELECT TOP (20) q.query_id, SUM(rs.count_executions) AS ejecuciones,
       SUM(rs.avg_duration * rs.count_executions) / 1000 AS ms_total,
       COUNT(DISTINCT p.plan_id) AS planes, qt.query_sql_text
FROM sys.query_store_query_text AS qt
JOIN sys.query_store_query AS q ON q.query_text_id = qt.query_text_id
JOIN sys.query_store_plan AS p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id = p.plan_id
GROUP BY q.query_id, qt.query_sql_text
ORDER BY ms_total DESC;

planes列が1より大きいのは、パラメータスニッフィングの痕跡です。測定した注意点が2つあります。再起動のあと、11個のクエリーのテキストは残っていましたが、それ以前の数値は残っていませんでした。900秒ごとにディスクに書き込むからです。そしてデータベースごとであって、サーバごとではありません。

Calíopeはこれを使いません。「スロークエリー」は、サーバ全体に対してすでにあるプランキャッシュを読みます。オンにもオフにもしません。それは管理のためのALTER DATABASEだからです。

待機：時間がどこに行くか
sys.dm_os_wait_statsは、最後の再起動以降にサーバがどれだけ、なぜ待ったかを合計します。1,547種類あり、フィルタしないと一覧の先頭は仕事を待っているスレッドです：DISPATCHER_QUEUE_SEMAPHORE、BROKER_TASK_STOP、SLEEP_…のたぐい。これらは除外しなければなりません。本当に何かを語るもの：
- LCK_M_…：ロック。「ロックとデッドロック（SQL Server）」で説明しています。
- PAGEIOLATCH_…：ディスクからのページを待っています。メモリーかインデックスが足りません。
- WRITELOG：コミットのたびにトランザクションログを待っています。
- CXPACKETとCXCONSUMER：並列処理。
- SOS_SCHEDULER_YIELD：CPU。
- RESOURCE_SEMAPHORE：並べ替えやハッシュのためのメモリーを待っているクエリー。

累積なので、1回のスナップショットはあまり役に立ちません。2回取って差を取ってください。私が再起動したあと、合計は1,210万msから70万msに下がりました。

並列処理
最初の状態では、cost threshold for parallelismは5、max degree of parallelismは0（すべてのコア）です。しきい値がとても低いので、中くらいのスキャンでももう並列になり得ます。別の200,000行のテーブルでは、1つのスキャンが16スレッドを使い、実時間152 msに対してCPUを2,094 ms使いました。高いCXPACKETはエラーではありません。その2つの値が最初のままになっているしるしです。

ほかの項目にあること
- SQL_照合順序のvarchar列に対するnvarcharのパラメータは、読み取りが3から334になります：「エンコーディングと照合順序（SQL Server）」。
- キー検索、プランがインデックスをやめてテーブルを読むとき、YEAR(fecha)と範囲の違い、そしてサーバが欲しがるインデックス：「インデックス（SQL Server）」。
- 信頼されていないCHECK制約はオプティマイザに使われません（読み取り1,364対0）：「オンラインでのスキーマ変更（SQL Server）」。
- クエリーがいくつのパーティションを読んだかは、実際のプランにしか示されません：「パーティション分割（SQL Server）」。

推奨事項
うまくいく順番：「スロークエリー」で（履歴が必要ならクエリーストアで）クエリーを見つけ、SET STATISTICS XML ONでその実際のプランを要求し、EstimateRowsとActualRowsを比べます。ずれていて、コンパイル時の値が今の値でなければ、パラメータスニッフィングです。同じ値でずれているなら統計情報です。一致しているのにそれでも多く読んでいるなら、インデックスが足りません。プランを読む前にメモリーや並列処理に手を出すのは遠回りです。

キーワード： パフォーマンス、STATISTICS IO、STATISTICS TIME、論理読み取り、showplan_xml、STATISTICS XML、実行計画、実際のプラン、パラメータスニッフィング、RECOMPILE、OPTIMIZE FOR UNKNOWN、sp_recompile、dm_exec_query_stats、query_hash、プランキャッシュ、クエリーストア、dm_os_wait_stats、待機、並列処理

3つの復旧モデルとログを増やし続けるのはどれか、サーバのディスク上のBACKUP DATABASEとBACKUP LOG、ログチェーン、STOPATでDELETEの1分前に戻る方法、COPY_ONLY、そしてCalíopeのバックアップとの違い。

対象： SQL Server 2022+

MySQLから来た人へ：ここにはmysqldumpも独立したバイナリログもありません：物理バックアップはT-SQLのSQL文で、そこから先へ進めるための履歴は、各データベースのトランザクションログです。PostgreSQLから来た人にとっての違いは単位です：バックアップと復元の単位はサーバ全体ではなく1つのデータベースです。ここで説明することはすべてSQL Server 2025で測定したものです。

復旧モデルがほとんどすべてを決める
これは各データベースのプロパティで、3つあります：

新しいデータベースはmodelのモデルをコピーし、このサーバではそれがFULLです：

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases;

ログのバックアップなしのFULLはディスクをいっぱいにする
これが落とし穴です。データベースが最初の完全バックアップを持つまでは、FULLはSIMPLEのように振る舞います：2 kBの行を20,000行挿入すると、ログの使用量は42.2 MBに達し、CHECKPOINTで8.1 MBに下がりました。最初のBACKUP DATABASEの後は、同じことをしても何も解放されませんでした：55.4 MB、次に102.8 MBで、ファイルは72 MBから136 MBに増えました。再利用できない理由はlog_reuse_wait_descが伝えます：

- LOG_BACKUP：BACKUP LOGを待っています。ディスクがいっぱいになるほとんどすべての原因です。
- ACTIVE_TRANSACTION：誰も閉じない、開いたままのトランザクション。
- CHECKPOINT：心配はいりません。次のチェックポイントで解放されます。

BACKUP LOGで使用量は15.1 MBに下がりましたが、ファイルは136 MBのままでした：ログをバックアップすると中の領域は解放されますが、ディスクに返すわけではありません。FULLのデータベースで誰もBACKUP LOGをスケジュールしていないなら、スケジュールするか、SIMPLEに切り替えてください。

バックアップを取る

BACKUP DATABASE tienda TO DISK = '/var/opt/mssql/backup/tienda_full.bak'
    WITH CHECKSUM, INIT;

BACKUP DATABASE tienda TO DISK = '/var/opt/mssql/backup/tienda_dif.bak'
    WITH DIFFERENTIAL, CHECKSUM, INIT;

BACKUP LOG tienda TO DISK = '/var/opt/mssql/backup/tienda_0930_1200.trn'
    WITH CHECKSUM, INIT;

パスは自分のではなくサーバのディスクのものです：ファイルを書くのはSQL Serverのプロセスです。Linuxでは通常のフォルダは/var/opt/mssql/backup/です。テスト用のコンテナにはそれがなく、最初のBACKUPが作成しました。

- 完全バックアップはデータベース全体をコピーします：私のテストでは150 MB。
- 差分バックアップは、最後の完全バックアップ以降に変わったものをコピーします：2,000行を変えた後で3.1 MB。
- ログのバックアップは前回以降のログをコピーし、これで特定の時点に到達できます。

CHECKSUMはデフォルトではオンになっておらず（backup checksum defaultは0）、検証するときに気づきます：それなしで取ったバックアップに対するRESTORE VERIFYONLY … WITH CHECKSUMはMsg 3187になりました。常に使い、検証してください：

RESTORE VERIFYONLY FROM DISK = '/var/opt/mssql/backup/tienda_full.bak'
    WITH CHECKSUM;

ログチェーン
ログのバックアップはそれぞれ前回が終わったところから始まり、すべてを順番に復元します。1つ飛ばすと、欠けているLSNとともにMsg 4305になりました。警告なしにそれを壊すものが2つあります：

- SIMPLEに切り替えてからFULLに戻すこと：その後、以前の完全バックアップがあっても、次の完全バックアップまでBACKUP LOGはMsg 4214になりました。
- 自分の知らないファイルへの、ほかの誰かのBACKUP LOG。履歴はmsdbにあります：

SELECT b.type, b.is_copy_only, b.first_lsn, b.last_lsn,
       b.backup_finish_date, m.physical_device_name
FROM msdb.dbo.backupset b
JOIN msdb.dbo.backupmediafamily m ON m.media_set_id = b.media_set_id
WHERE b.database_name = 'tienda'
ORDER BY b.backup_start_date;

COPY_ONLY：邪魔をしないコピー
通常の完全バックアップは、その後の差分バックアップの基点になります。データベースを別のマシンに移すために一度だけ取ると、今夜の差分バックアップはもう日曜日の完全バックアップと合いません。WITH COPY_ONLYならそうはなりません：次の差分バックアップは前の完全バックアップを指したままで、それをCOPY_ONLYの上に復元するとMsg 3136になりました。ルーチン外のコピーはすべてCOPY_ONLYで取ります。

DELETEの1分前に戻る
最初から最後まで再現しました：500件の注文、4秒後のWHEREなしのDELETE、そして元のデータベースに触れずに新しいデータベースへ復旧：

RESTORE DATABASE tienda_rec FROM DISK = '/var/opt/mssql/backup/tienda_full.bak'
    WITH NORECOVERY,
    MOVE 'tienda' TO '/var/opt/mssql/data/tienda_rec.mdf',
    MOVE 'tienda_log' TO '/var/opt/mssql/data/tienda_rec_log.ldf';

RESTORE LOG tienda_rec FROM DISK = '/var/opt/mssql/backup/tienda_log1.trn'
    WITH NORECOVERY;

RESTORE LOG tienda_rec FROM DISK = '/var/opt/mssql/backup/tienda_log2.trn'
    WITH STOPAT = '2026-09-30T17:50:09.926', RECOVERY;

500件すべてが戻りました。知っておくべきこと：

- NORECOVERYはデータベースをRESTORINGのままにし、続きを待ちます：読むとMsg 927になります。最後の手順にRECOVERYを付けます。
- 別の名前で復元するときはMOVEが必須です。付けないと元のデータベースのファイルとぶつかります。その論理名はRESTORE FILELISTONLYでわかります。
- STOPATはサーバの時刻で、小数点以下3桁です：7桁にするとMsg 3217になりました。
- 先にログの末尾をバックアップせずに、稼働中のデータベースの上に復元するとMsg 3159になりました。末尾とは最後のBACKUP LOG以降に起きたことで、BACKUP LOG … WITH NORECOVERYでバックアップします。これもデータベースをRESTORINGのままにします。

BULK_LOGGEDとその代償
21 MBのテーブルのSELECT … INTOは、FULLでは22.1 MBのログを書き、BULK_LOGGEDでは1.0 MBでした。しかし次のログのバックアップは、読み込んだページを運ぶので同じ22.1 MBになりました。そしてそのバックアップをSTOPAT付きで復元するとMsg 4341になりました：一括読み込みを含む区間では、特定の時点ではなく終わりにしか到達できません。読み込みのためにBULK_LOGGEDに切り替え、すぐにFULLに戻し、その前後でBACKUP LOGを取ってください。

別のサーバで復元する
データベースのバックアップにはそのユーザが含まれますが、masterにあるサーバのログインは含まれません。別のマシンで復元すると、各ユーザはそのログインから孤立します。見つけ方とつなぎ直し方は、SQL Serverのセキュリティのトピックにあります。

Calíopeがすること
「バックアップ」は.bakではなくテキストのスクリプトを書きます：バッチの間にGOを挟んだSQL文、1,000行ずつのINSERTの行、ISO 8601の日付、0x…のバイナリなので、別のサーバでも、別のバージョンでも、セッションが別の言語でも同じように戻ります。「ユーザのパスワードを含める」をオンにすると、ログインはCREATE LOGIN … WITH PASSWORD = 0x… HASHEDとして、各データベースのユーザはCREATE USER … FOR LOGINとして書かれます：スクリプトを復元しても、誰も孤立しません。パーティション分割されたテーブルはパーティション分割されたまま戻ります：スクリプトは、なければ先にそのパーティション関数とパーティション構成を作成します。

SQLエディタからBACKUP DATABASEを実行することもできますが（ほかのSQL文と変わりません）、ファイルはサーバのディスクに残ります：Calíopeはそれを持ってきません。

推奨事項
モデルはデータベースごとに決めます：今日の作業を失っても構わないところはSIMPLE、そうでないところはスケジュールされたBACKUP LOG付きのFULLです。週1回の完全、毎日の差分、数分ごとのログが通常のルーチンで、常にWITH CHECKSUMを付けます。log_reuse_wait_descを見張り、一度だけのコピーはすべてCOPY_ONLYにし、ときどき実際に別の名前で復元してください：一度も復元したことのないバックアップは、ただの意図です。Calíopeのバックアップは、データベースやその一部を別のマシンに持っていくためのもので、サーバのバックアップの代わりにはなりません。

キーワード： バックアップ、復元、復旧、復旧モデル、FULL、SIMPLE、bulk_logged、トランザクションログ、log_reuse_wait_desc、BACKUP LOG、ログチェーン、NORECOVERY、STOPAT、copy_only、差分、CHECKSUM、VERIFYONLY、ポイントインタイム、3159、4214、4341

サーバのログインとデータベースのユーザ、別のサーバで復元するとユーザが孤立する理由とつなぎ直す方法、スキーマ単位の付与、DENYとそれを回避する者、所有権の連鎖、包含ユーザ、行レベルセキュリティ、そしてsaをどうするか。

対象： SQL Server 2022+

MySQLから来た人にとって、ここではアカウントがホストを中に持たず、しかも2つのものです：サーバに属し、接続に使う*ログイン*と、各データベースに属し、権限を受け取る*ユーザ*です。PostgreSQLから来た人にとっては、LOGINを持つすべてのロールが、使えるようになるには各データベースの中にもう一度存在しなければならないようなものです。ここで説明することはすべてSQL Server 2025に対して測定したものです。

ログインとユーザ

CREATE LOGIN ana WITH PASSWORD = 'Xq7#lunes_pw9';   -- サーバ：入る
USE tienda;
CREATE USER ana FOR LOGIN ana;                    -- データベース：中にいる

ログインがあってユーザがないと、サーバには入れてもデータベースには入れません：データベースを指定して接続するとCannot open database … The login failed（4060）になり、masterからのUSEはMsg 916になりました。ユーザは名前ではなく「sid」でログインに結び付いています：孤立はそこから生まれます。

パスワードはポリシー（CHECK_POLICY、デフォルトでオン）を通ります：3種類の文字から8文字、そしてログイン名を含まないこと。ログインanaに対する'Xq7#ana_pw9'は、ほかの条件を満たしていてもMsg 33064になりました。

孤立したユーザ：別のサーバで復元する
再現しました：ユーザanaを持つデータベースをバックアップし、ログインを削除して同じ名前で作り直し（別のマシンならそうなるように）、データベースを復元しました。anaはもうコピーに入れませんでした：そのユーザは古いsidを保持し、新しいログインは別のsidを持っていたからです。作り直すこともできませんでした：Msg 15023、ユーザはすでに存在します。見つけるには：

SELECT dp.name, dp.type_desc
FROM sys.database_principals dp
LEFT JOIN sys.server_principals sp ON sp.sid = dp.sid
WHERE dp.type IN ('S', 'U', 'G')
  AND dp.authentication_type_desc = 'INSTANCE'
  AND sp.sid IS NULL;

そして、権限を失わずにつなぎ直すには：

ALTER USER ana WITH LOGIN = ana;

あと2つ。DROP LOGINは、ログインにユーザがあるかどうかを確認しません：警告なしに削除し、同じサーバの元のデータベースでユーザを孤立させました。そしてデータベースを別のマシンに持っていくときにそうならないよう、そこでは同じsidでログインを作成します（CREATE LOGIN ana WITH PASSWORD = …, SID = 0x1C2F…）：そうすると、復元したデータベースのユーザは、手を加えなくても再び動きました。

ロール
固定サーバロールは18個あります：いつもの8つ（sysadmin、serveradmin、securityadmin、processadmin、setupadmin、bulkadmin、diskadmin、dbcreator）と、2022以降の、より細かい10個の##MS_…##（何にも触れずに状態を見るための##MS_ServerStateReader##など）です。各データベースには固定ロールが9個あります：db_owner、db_datareader、db_datawriter、db_ddladmin、db_securityadmin、db_accessadmin、db_backupoperatorと、拒否する2つ、db_denydatareaderとdb_denydatawriterです。独自のロールはCREATE ROLEで作成し、ALTER ROLE … ADD MEMBERでメンバーを追加します。

そして、全員が属するpublic。サーバではこれがVIEW ANY DATABASEを持っています：anaは、入れるのは4つだけなのに、サーバの10個のデータベースの名前が見えました。名前が情報になるなら、publicから取り上げてください。

スキーマ単位の付与は明日のテーブルにも及ぶ

GRANT SELECT ON SCHEMA::rrhh TO ana;

これでanaはrrhhのテーブルを読めるようになり、後から作成したテーブルも読めました。ON ALL TABLESが今日のテーブルにしか及ばないPostgreSQLとは逆です。そしてスキーマの外にあるものは閉じたままです：dbo.pedidosはMsg 229になりました。

GRANT、DENY、REVOKE：2つではなく3つの状態
- GRANTは付与します。
- DENYは禁止し、どんなGRANTにも優先します：rrhh.nominasにDENY SELECTがあると、anaは、スキーマを付与されていても、db_datareaderのメンバーであってもMsg 229になりました。
- REVOKEは、GRANTであれDENYであれ、そこにあるものを取り除きます。REVOKEの後、anaはロール経由で再び読めるようになりました。

誰がDENYを回避するかを、1つずつ測定しました：
- 「db_owner」のメンバー：回避しません。Msg 229になりました。
- 「CONTROL SERVER」を持つログイン：これも回避せず、Msg 229。
- 「sysadmin」のメンバー：回避します。すべてのデータベースにdboとして入り（USER_NAME()がそう伝えます）、権限が一切確認されないので、拒否されたテーブルを読みました。

何ができるかをサーバに尋ねる

EXECUTE AS USER = 'ana';
SELECT permission_name, subentity_name
FROM fn_my_permissions('rrhh.nominas', 'OBJECT');
SELECT HAS_PERMS_BY_NAME('rrhh.nominas', 'OBJECT', 'UPDATE');
REVERT;

fn_my_permissionsはSELECTを4回返しました：テーブルに1回、その3つの列にそれぞれ1回です。ロール、スキーマ、DENYをすでに解決したうえでの実効的な権限を、誰にもパスワードを尋ねずに確かめる方法です。

所有権の連鎖
ビューやプロシージャと、それが読むテーブルの所有者が同じなら、ビューを使える人はテーブルに対する権限を必要としません。dbo.pedidosに何の権限もないanaが、ビューdbo.v_totalesとプロシージャdbo.p_totalを通して読めました。オブジェクトが見せるものだけにアクセスを与える、よい方法です。しかし動的SQLは連鎖を断ち切ります：中にEXEC('SELECT …')がある同じプロシージャはMsg 229になりました。

包含ユーザ
包含データベースでは、ユーザは自分のパスワードを持ち、ログインを必要としないので、データベースと一緒に移動し、孤立することがありません：

EXEC sp_configure 'contained database authentication', 1;
RECONFIGURE;
CREATE DATABASE tienda CONTAINMENT = PARTIAL;
-- tiendaの中で：
CREATE USER carla WITH PASSWORD = 'Rt5%jueves_z2';

このオプションはデフォルトでオフです。オンにすると、carlaは接続するときにデータベースを指定して入れました。指定しないとLogin failedです。Calíopeでは、接続の「データベース」欄にデータベースを入れるということです。

行レベルセキュリティ
フィルタ述語を持つポリシー：

CREATE FUNCTION seg.fn_lo_mio(@dueno sysname)
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS ok WHERE @dueno = USER_NAME();

CREATE SECURITY POLICY seg.solo_lo_mio
ADD FILTER PREDICATE seg.fn_lo_mio(dueno) ON dbo.pedidos
WITH (STATE = ON);

anaには自分の行が見えました。そしてPostgreSQLと違い、ここでは誰も回避しません：saとsysadminには0行が見えました。彼らにとってUSER_NAME()はdboだからです。決めるのは述語で、管理者がすべてを見る必要があるなら、述語がそう言わなければなりません。また、フィルタは読まれるものを絞り込むだけです：anaは別の所有者の行をエラーなしで挿入しました。それを防ぐにはBLOCK PREDICATEが必要です。

sa
saはsidが0x01のログインで、sysadminのメンバーであり、その名前は入ろうとする誰もが知っています。パスワードが間違っていると、クライアントでは常に状態1で18456になります。理由はサーバのログにしかなく、そこでは同じ試行が状態8、パスワードの誤りとして表示されます。よくあるやり方は、独自の名前で管理用のログインを作成してからALTER LOGIN sa DISABLEすることです。

Calíopeがしないこと
Calíopeが話すのはSQL認証だけです：Windows認証もMicrosoft Entra IDも扱いません。

Calíopeがすること
「ユーザ」はサーバのログインを一覧にし、publicをアカウントの1つとして含め、saは別にして「システムユーザ」として示します。権限はレベル（サーバ、データベース、スキーマ、テーブル、ルーチン）ごとに表示され、DENYは3つ目の状態として描かれます：色を変えるだけでなく、専用の記号、取り消し線、DENYという語で示します。チェックを外すことはできません。取り除くことはチェックを外すことではなく、REVOKEだからです。「アカウントをロック」はALTER LOGIN … DISABLEです。ログインのないデータベースユーザ（孤立したものや包含のもの）は表示されません：それらには、SQLエディタで上のクエリーを使ってください。

推奨事項
人やアプリケーションごとに1つのログインを用意し、権限は人ではなくロールにスキーマ単位で付与します。sysadminは管理のためだけにします。どんなDENYも届かないからです。ビューやプロシージャを通して与えられるものは、中に動的SQLを入れずに、その方法で与えます。データベースを別のマシンに移すときは、ログインをsid付きで作るか、復元した直後に孤立ユーザのクエリーを実行します。そしてsaは無効にします。

キーワード： セキュリティ、ログイン、ユーザ、ロール、SYSADMIN、db_owner、db_datareader、PUBLIC、GRANT、DENY、REVOKE、スキーマ、fn_my_permissions、has_perms_by_name、孤立したユーザ、ALTER USER WITH LOGIN、SID、包含ユーザ、包含データベース、所有権の連鎖、行レベルセキュリティ、セキュリティポリシー、SA、check_policy、229、916、4060、15023、18456、33064

sp_configureとRECONFIGURE、valueとvalue_in_useが違う理由、再起動が必要なオプション、設定されていないメモリーの上限、それぞれのMAXDOPが優先される場所、データベース単位の設定、tempdb、そしてmssql-conf。

対象： SQL Server 2022+

MySQLから来た人へ：ここにはmy.cnfもSET GLOBALもありません：サーバの設定は「sp_configure」で書き込んで「RECONFIGURE」で有効にし、データベースの設定はALTER DATABASE SCOPED CONFIGURATIONで行います。PostgreSQLから来た人にとっては、sys.configurationsがpg_settingsにあたり、重要な列はsourceではありません：「value」と「value_in_use」の違いです。ここで説明することはすべてSQL Server 2025に対して測定したものです。

107のオプション、そのうち74は隠れている
このサーバのsys.configurationsには107のオプションがあり、ただのsp_configureが表示するのは33です。残りの74は*詳細オプション*です：show advanced optionsをオンにするまで、一覧にも出ず、変更もできません。sp_configure 'max degree of parallelism', 4はMsg 15123、does not exist, or it may be an advanced optionになりました。

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

書いただけでは適用されない：valueとvalue_in_use
sp_configureは値を書き込むだけで、サーバはRECONFIGUREまで古い値を保持します。sp_configure 'cost threshold for parallelism', 50の後、sys.configurationsはvalueが50、value_in_useが5で、サーバ自身がRun the RECONFIGURE statement to installと警告しました。

SELECT name, value, value_in_use, is_dynamic, is_advanced
FROM sys.configurations
WHERE value <> value_in_use;

RECONFIGUREの前には毎回そのクエリーを実行してください。測定した2つのことのためです：
- RECONFIGUREは、自分のものだけでなく保留中のものをすべて適用します：誰かが値を書いたままにしていれば、それも自分のものと一緒に入ります。
- 失敗したRECONFIGUREは、書き込まれたものを保留中のまま残します。min server memory (MB)を1,024、max server memory (MB)を128にするとMsg 5831になり、1,024はvalueに残って次の機会を待っていました。

例外が通るケースが1つあります：recovery interval (min)を120にするとMsg 5807（not recommended）になり、RECONFIGURE WITH OVERRIDEはそれでも適用しました。WITH OVERRIDEは、まさに今警告したチェックを飛ばすものなので、習慣で使うものではありません。

再起動が必要なもの
is_dynamic = 0のオプションはRECONFIGUREでは有効になりません：ここでは107のうち23で、その中にはuser connections、fill factor (%)、locks、priority boostがあります。sp_configure 'user connections', 500とRECONFIGUREの後、valueは500になり、value_in_useはサービスを再起動するまで0のままでした。

変更はすべて、時刻とセッションとともにサーバのログに記録されます：EXEC xp_readerrorlog 0, 1, N'Configuration option'で、そのchanged from 0 to 4とともに一覧にできます。

メモリー：max server memoryは上限なしで来る
max server memory (MB)は最初から2,147,483,647、つまり上限なしです：SQL Serverは、システムから手放すよう求められるまで、キャッシュのためにメモリーを取ります。専用サーバでは、オペレーティングシステムの分を残す上限を設定します。受け付ける最小値は128で、100にするとMsg 15129になりました。

EXEC sp_configure 'max server memory (MB)', 12288;   -- 16 GBのうち12 GB
RECONFIGURE;

Linuxではその下にもう1つの上限、mssql-confのmemory.memorylimitmbがあり、ドキュメントによれば物理メモリーの80%がデフォルトです。このコンテナには6,347 MBが見え、max server memoryに手を付けない状態で、その目標値（sys.dm_os_sys_infoのcommitted_target_kb）は5,139 MBでした。

並列処理：3つのレベルがあり、いちばん近いものが優先される
最初の状態では、max degree of parallelismは0（すべてのプロセッサ）、cost threshold for parallelismは5です。300,000行に対して同じクエリーを実行し、実際のプランからDegreeOfParallelismを読みました：
- サーバが0のとき：15スレッド。見えるすべてのプロセッサです。
- サーバが4のとき：4。
- データベースでALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 2のとき：サーバが4でも2。
- クエリーにOPTION (MAXDOP 8)を付けたとき：データベースとサーバの両方を超えて8。
- cost threshold for parallelismが50のとき：直列。しきい値は並列プランではなく、直列プランのコスト（ここでは7.7）と比べられます。

並列処理が待機にどう表れるかは「パフォーマンスと診断（SQL Server）」で説明しています。

データベース単位の設定
demoのsys.database_scoped_configurationsには41のオプションがあります。MAXDOPのほかに、LEGACY_CARDINALITY_ESTIMATION（0）、PARAMETER_SNIFFING（1）、QUERY_OPTIMIZER_HOTFIXES（0）などがあります。サーバのほかの部分に触れずに、1つのアプリケーションの振る舞いを変えるための方法です。

SELECT name, value
FROM sys.database_scoped_configurations
WHERE is_value_default = 0;

tempdb
このサーバには15のプロセッサが見え、tempdbには8 MBのデータファイルが8個と、ログファイルがあり、64 MBずつ増えます：セットアップの時点で、プロセッサごとに1つ、8つまで作成されます。これは#temporaryテーブル、メモリーに収まらないソート、READ_COMMITTED_SNAPSHOTの行バージョンを支えるデータベースです。

sp_configureではないもの：Linuxのmssql-conf
データ、ログ、バックアップのデフォルトのパス、TLS証明書、メモリーの上限、言語は/var/opt/mssql/mssql.confにあり、/opt/mssql/bin/mssql-conf set …と再起動で変更します。このコンテナのファイルには2行しかありません：TLSの証明書と鍵で、SQL Server 2022以降が厳格なTLS（TDS 8.0）に必要とするものです。Windowsでは、同じことをSQL Server構成マネージャーで行います。

Calíopeが表示するもの
「サーバ情報」の「グローバル変数」は、sys.configurationsをそのvalue_in_use（書き込まれて保留中のものではなく、動いているもの）とともに一覧にし、SERVERPROPERTY.*のプロパティ（バージョン、エディション、照合順序）も表示します。「セッション変数」は、自分の接続のSETオプションです。Calíopeはそれらを読むだけで変更はしません：sp_configureは「SQLエディタ」で書き、RECONFIGUREの後、更新するとサーバ情報に表示されます。「スロークエリー」は、その設定にoptimize for ad hoc workloadsとmax server memory (MB)を表示します。そして、自分のパスワードを持つユーザを許可するオプションcontained database authenticationは「ログイン、ユーザ、権限（SQL Server）」で説明しています。

推奨事項
少しだけ、そして測定しながら。max server memoryは必ず、システムの分を残して。cost threshold for parallelismは5より上に。そしてMAXDOPは、サーバ全体ではなく、アプリケーションが求めるときにデータベース単位で。RECONFIGUREの前には毎回value <> value_in_useのクエリーを：そうすれば、ほかの誰かが中途半端に残したものではなく、自分が望むものを適用できます。

キーワード： 設定、sp_configure、RECONFIGURE、WITH OVERRIDE、sys.configurations、value_in_use、SHOW ADVANCED OPTIONS、is_dynamic、MAX SERVER MEMORY、MIN SERVER MEMORY、MEMORYLIMITMB、MSSQL-CONF、MAXDOP、MAX DEGREE OF PARALLELISM、COST THRESHOLD FOR PARALLELISM、DATABASE SCOPED CONFIGURATION、TEMPDB、USER CONNECTIONS、xp_readerrorlog、15123、15129、5807、5831

別のトランザクションの中のBEGIN TRANが入れ子にならない理由、SAVE TRANSACTIONで一部をロールバックする方法、各レベルが何をロックするか、SNAPSHOTの3960、そして忘れられたトランザクションがログに何をするか。

対象： SQL Server 2022+

トランザクションは、複数のSQL文をまとめて、全体が適用されるかまったく適用されないかの単位にします。MySQLやPostgreSQLと同じく、明示的なトランザクションがなければ、SQL Serverは各SQL文をそれぞれ単独でコミットします（自動コミット）。違うのは細部で、ここで説明することはすべてSQL Server 2025に対して測定したものです。

BEGINではなくBEGIN TRAN
単独のBEGINはトランザクションではなくT-SQLのブロックを開きます：サーバはMsg 102、Incorrect syntax near 'BEGIN'と応答しました。書くのはBEGIN TRAN（またはBEGIN TRANSACTION）です。開いているトランザクションがないときのCOMMITはMsg 3902になり、ROLLBACKはMsg 3903になります。

暗黙モード
SET IMPLICIT_TRANSACTIONS ONにすると、データに触れる最初のSQL文がトランザクションを開き、それはCOMMITまで開いたままになります。測定しました：@@TRANCOUNTは0で、ただのSELECTで1に上がり、COMMITでようやく0に戻りました。このモードでコミットを忘れたセッションは、ロックを持ち続け、ログを抱え込みます。これは後で説明します。

入れ子は入れ子にならない
別のトランザクションの中のBEGIN TRANは、@@TRANCOUNTのカウンタを上げるだけです。決めるのは外側です：
- 内側のCOMMITは何もコミットしません：カウンタを2から1に下げただけで、外側のROLLBACKは内側のものも含めて両方のUPDATEを元に戻しました。
- 内側のROLLBACKはすべてを元に戻します：@@TRANCOUNTを0にし、外側のCOMMITは、トランザクションが残っていなかったのでMsg 3902になりました。
- 内側に名前を付けても役に立ちません：ROLLBACK TRAN interiorはMsg 6401になり、カウンタは2のままでした。ロールバックできるのはセーブポイントまでだけです。

BEGIN TRAN;                                  -- @@TRANCOUNT = 1
  UPDATE cuentas SET saldo = saldo - 10 WHERE id = 1;
  BEGIN TRAN;                                -- @@TRANCOUNT = 2
    UPDATE cuentas SET saldo = saldo + 10 WHERE id = 2;
  COMMIT;                                    -- @@TRANCOUNT = 1、何もコミットされていない
ROLLBACK;                                    -- 両方のUPDATEを元に戻す

始めたときと違う@@TRANCOUNTで終わるプロシージャはMsg 266になります：これは「エラー（SQL Server）」で説明しています。

セーブポイント：SAVE TRANSACTION
トランザクションを失わずに作業の一部を元に戻すには、地点に印を付けてそこへ戻ります。ここでは重複したINSERTが2627で失敗し、私はその地点に戻り、COMMITがその前の行と後の行をコミットしました：

BEGIN TRAN;
  INSERT INTO cuentas (id, saldo) VALUES (3, 0);
  SAVE TRANSACTION antes;
  BEGIN TRY
    INSERT INTO cuentas (id, saldo) VALUES (1, 0);   -- 失敗：2627
  END TRY
  BEGIN CATCH
    ROLLBACK TRANSACTION antes;                      -- @@TRANCOUNTは1のまま
  END CATCH
  INSERT INTO cuentas (id, saldo) VALUES (5, 5);
COMMIT;

測定した制限が2つあります：開いているトランザクションがないときのSAVE TRANSACTIONはMsg 628になり、XACT_ABORT ONでは、同じエラーでトランザクションが破綻した状態になり（XACT_STATE()が-1）、その地点に戻るとMsg 3931になりました：抜け出す方法は、全体をロールバックすることだけでした。

エラーでトランザクションが中断されることはほとんどない
PostgreSQLと違い、SQL文のエラー（重複キー、制約）はそのSQL文だけを中断し、トランザクションはそれまでにしたことを抱えたまま生き続けます。XACT_ABORTなしでは、最後のCOMMITがエラーの前と後のものをコミットします。SET XACT_ABORT ONでは、同じエラーがすべてを元に戻し、バッチを終了します。どのエラーが単独でトランザクションをロールバックするかは「エラー（SQL Server）」で説明しています。

分離レベル
デフォルトはREAD COMMITTEDです。2つのセッションで測定しました：1つ目はある範囲の4行を読み、4秒待ってからもう一度読みます。2つ目はその間に、その範囲に1行を挿入し、読まれた行の1つを更新します。
- 「READ UNCOMMITTED」は、ほかのセッションがコミットしていないものを読みます：「ロックとデッドロック（SQL Server）」のNOLOCKです。
- 「READ COMMITTED」は、読んだものにロックを保持しません。オフの状態で来るREAD_COMMITTED_SNAPSHOTがなければ、読み取りは書き込む側を待ちます。これは「ロックとデッドロック（SQL Server）」で説明しています。
- REPEATABLE READは、5つの共有ロック（KEY S）を最後まで保持しました：読んだ行のUPDATEは3秒待ちました。しかしINSERTはすぐに入り、2回目の読み取りは4行ではなく5行を数えました：ファントム行です。
- SERIALIZABLEは範囲をロックしました（KEY RangeS-S）：INSERTは3秒待ち、2回目の読み取りも4行のままでした。
- 「SNAPSHOT」はトランザクション開始時点のスナップショットを読み、誰もブロックしませんが、データベースごとに許可する必要があり、オフの状態で来ます：snapshot_isolation_state_descは、demoでも、modelでも、新しいデータベースでもOFFでした。許可しないままだと、SET TRANSACTION ISOLATION LEVEL SNAPSHOTとBEGIN TRANは通り、最初のSELECTがMsg 3952になりました。

ALTER DATABASE mi_base SET ALLOW_SNAPSHOT_ISOLATION ON;
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;

SNAPSHOTは待たない：3960で中断する
許可した状態では、2つ目のセッションは、行を読んだだけの1つ目を待たずにその行を更新しました。1つ目はもう一度読み、相手の101がすでにコミットされているのに、自分のスナップショットの値100が見えたままでした。それを更新しようとすると、サーバはMsg 3960（update conflict）でそれを中断し、XACT_STATE()は-1のままになりました。SNAPSHOTのもとでは、3960は正常な動作です：アプリケーションがトランザクション全体を再試行する必要があります。READ_COMMITTED_SNAPSHOTは別物です：レベルを変えるのではなく、READ COMMITTEDの読み方を変えます。それが「ロックとデッドロック（SQL Server）」で説明していることです。

忘れられたトランザクションがログを抱え込む
トランザクションの中で眠っているセッション（status = sleeping、open_transaction_count = 1）は、ログの再利用を妨げます。CHECKPOINTでログが空になるデータベースで、5,000行を挿入して削除し、CHECKPOINTを実行しました。そのセッションがなければ使用中は6.5 MBでしたが、あると73.8 MBで、log_reuse_wait_descはACTIVE_TRANSACTIONでした。それを閉じた後は5.1 MBです。ログのサイクルの残りは「バックアップと復旧（SQL Server）」で説明しています。見つけるには：

DBCC OPENTRAN;   -- 最も古いもの：SPIDと開始時刻

SELECT session_id, status, open_transaction_count, last_request_end_time
FROM sys.dm_exec_sessions
WHERE open_transaction_count > 0;

DDLもロールバックされる
ALTER TABLE、CREATE INDEX、CREATE TABLEは、例外（CREATE DATABASEはMsg 226になります）を除いてトランザクションの中に入ります：これは「オンラインでのスキーマ変更（SQL Server）」で説明しています。

Calíopeがすること
「SQLエディタ」は、渡されたものを1つの接続でSQL文ごとに実行し、最初に失敗したところで止まります。メニューからのトランザクションがなければ、終わると接続をプールに返し、トランザクションが開いたままならそれをロールバックします（IF @@TRANCOUNT > 0 ROLLBACK）：手で書いたBEGIN TRANとそのCOMMITは同じ実行に入れてください。エラーの前のものは、接続が返されるときにロールバックされます。sqlcmdやアプリケーションなら、コミットされていたはずです。
複数の実行にまたがるトランザクションには、ツールバーの「トランザクション」メニューがあります：「BEGIN」はBEGIN TRANSACTIONを送ってタブ用に接続を確保し、そこで実行したものは「COMMIT」か「ROLLBACK」まで中に残ります。タブを閉じるとロールバックされます。サーバが単独でロールバックした場合（245、1205、またはXACT_ABORTのもとでの任意のエラー）や、SQL内のCOMMITがそれを終わらせた場合は、「進行中のトランザクション」のラベルが消え、ステータスバーがそう伝えます：それ以降、各SQL文はすぐに確定されます。

推奨事項
書き込みをするすべてのバッチやプロシージャでSET XACT_ABORT ONを使い、IF @@TRANCOUNT > 0 ROLLBACK;とTHROW;で終わるTRY…CATCHを書きます。内側が独立することを期待してBEGIN TRANを入れ子にしないでください：そのためにあるのがセーブポイントです。SNAPSHOTに上げるなら、上げる前に3960の再試行を書いてください。そしてときどきDBCC OPENTRANを：忘れられたセッションは、ディスクがいっぱいになるまで何も警告しません。

キーワード： トランザクション、コミット、ロールバック、BEGIN TRAN、@@TRANCOUNT、SAVE TRANSACTION、セーブポイント、xact_abort、xact_state、implicit_transactions、分離レベル、REPEATABLE READ、SERIALIZABLE、SNAPSHOT、allow_snapshot_isolation、3960、3952、3902、6401、3931、active_transaction、DBCC OPENTRAN

名前にサイズが入った整数とJSONに収まらないUInt64、正確なDecimal、バイト列としてのString、日付の範囲、そしてコストを伴うラッパーとしてのNullableとLowCardinality。

対象： ClickHouse 25.3+

ClickHouseでは、型によって各値がディスク上で占める容量と圧縮のされ方が決まります。そのため、トランザクション処理向けのデータベースよりも慎重に選びます。型の名前にはサイズが含まれ、大文字と小文字が区別されます。uint64ではなくUInt64です。

整数：サイズは名前に入っている
Int8からInt256まで、UInt8からUInt256まであります。範囲を超えてもエラーにはならず、値が一周します。toInt8(300)は44を、toUInt8(-1)は255を返します。

UInt64の最大値は18446744073709551615ですが、JSONで数値が正確なのは9007199254740991（2^53 − 1）までです。そのため、サーバはJSON形式では64ビット整数を引用符で囲んで送り（output_format_json_quote_64bit_integers）、Calíopeはそれを浮動小数点数ではなく正確なテキストとして読みます。

Decimal：正確で、スケールは固定
Decimal(P, S)は、P桁のうちS桁を小数部として、浮動小数点の丸めなしで格納します。除算ではスケールに収まらない部分が切り捨てられます。toDecimal32(1, 2) / 3は0.33になります。乗算ではスケールが足し合わされます。Decimal(9, 2)同士を掛けるとDecimal(9, 4)になります。

Stringは文字ではなくバイト列
Stringは、UTF-8でないものを含め、どんなバイト列でも受け付けます。length('ñandú')は7（バイト数）、lengthUTF8('ñandú')は5になります。FixedString(N)はゼロで埋めます。toFixedString('ab', 4)は61 62 00 00を格納します。テキストが有効なUTF-8でない場合、Calíopeはそれを無害化して表示し、そのセルに印を付けます。

日付：範囲はそれぞれ異なり、超えてもエラーにならない

範囲外になると、Dateは警告なしで端の値にとどまります。toDate('2149-06-07')は2149-06-06を、toDate('1969-12-31')は1970-01-01を返します。生年月日や歴史的な日付にはDate32を使ってください。

タイムゾーンは各行ではなく列に属します（DateTime64(3, 'Asia/Tokyo')）。タイムゾーンがなければサーバのものが適用され、Calíopeは列見出しにそれを表示します。

NullableとLowCardinality：コストの異なるラッパー
Nullable(T)はNULLのマスクを別に保持します。100万行で、Int64は非圧縮で7.63 MiB、Nullable(Int64)は8.58 MiBでした。さらに、Nullableの列は、allow_nullable_keyをオンにしない限りソートキーに含められません。値がないことをデフォルト値（0や空文字列）で表せるなら、Nullableは使わないほうが得策です。

LowCardinality(T)は辞書でエンコードします。100万行に異なる値が100個の場合、Stringの列は圧縮後に254 KiB、LowCardinality(String)の列は7.6 KiBでした。サーバ自身のドキュメントは、異なる値がおよそ1万個未満ならこれを勧め、10万個を超えるなら勧めていません。

コレクションと構造化型
- Array(T)は1から始まり、範囲外はエラーではなくデフォルト値を返します。[10,20,30][5]は0になります。
- Map(K, V)は重複したキーを受け付けます。map('a',1,'a',2)は両方を保持し、['a']は最初の値を返します。
- Enum8は、一覧にない名前を挿入時に拒否します。UUIDは16バイト、IPv4は4バイトを使います。

CalíopeはコレクションをコンパクトなJSONで、数値は届いたとおり正確に表示します。集計の状態（AggregateFunction）は、テキストとして表示できないことを示します。

キーワード： 型、UINT64、INT64、Decimal、String、FixedString、DATE、Date32、DateTime、DateTime64、タイムゾーン、Nullable、LowCardinality、Array、MAP、TUPLE、ENUM、UUID、IPv4、JSON、ClickHouse

MergeTreeファミリーとそれぞれのバリアントがマージ時に行うこと、Replicated系、データを格納しないエンジンやメモリーに保持するエンジン、そしてエンジンを変更できない理由。

対象： ClickHouse 25.3+

ClickHouseでは、すべてのテーブルがエンジンを宣言し、エンジンによって、データの格納方法、受け付けるインデックス、レプリケーションするかどうか、マージ時に何が起きるかが決まります。これはパフォーマンスの細部ではなく、テーブルの性質そのものです。サーバは自分が知っている84個のエンジンを、それぞれの対応機能とともにsystem.table_enginesで公開しています。

MergeTreeファミリー：ほとんどの場合に選ぶもの
データはソートキーで並べられたパートとして書き込まれ、サーバがバックグラウンドで次々にマージします。バリアントはマージ時に、そしてそのときだけ、追加の処理を行います。

落とし穴は「そのときだけ」という点です。ReplacingMergeTreeで測定すると、同じキーを2回挿入した場合、普通のSELECTでは2行になります。FINALを付けると1行、OPTIMIZE TABLE … FINALの後はFINALなしでも1行です。SummingMergeTreeも同じで、2つの行('x', 1)と('x', 2)はマージまで2行のままで、マージ後に3を持つ1行になります。マージには予定がないため、これらのエンジンへのクエリーは集計するかFINALを使う必要があります。

Replicated：同じファミリーにコピーを加えたもの
ReplicatedMergeTreeとそのバリアント（ReplicatedReplacingMergeTree…）は、ClickHouse Keeperが調整するレプリカを追加します。一覧の中でレプリケーションと挿入の重複排除に対応するのは、これらだけです（supports_replication、supports_deduplication）。

MergeTree以外のエンジン
- Memory：RAM上に非圧縮で保持します。サーバ上の説明によると、再起動するとテーブルは空になります。
- Logとそのファミリー：一度だけ書き込む小さなテーブル用で、インデックスはありません。
- Buffer：データをメモリーに保持し、別のテーブルに書き出します。現在は代わりに非同期挿入が推奨されています。
- Distributed：何も格納しません。クエリーをクラスタのシャードに分散します。
- Merge：複数のテーブルを一度に読み、書き込みは受け付けません。
- Dictionary：辞書をテーブルとして見せます。
- Null：書き込まれたものは破棄されます。マテリアライズドビューの入力として使います。

これらはどれも、スキップインデックス、プロジェクション、ソートキー、TTLを受け付けません。system.table_enginesによると、それらはすべてMergeTreeファミリーだけのものです。

エンジンは変更できない
ALTER TABLE … MODIFY ENGINEはなく、サーバは構文エラーを返します。変更するには、新しいエンジンで別のテーブルを作成してINSERT INTO … SELECTでデータをコピーするか、列とパーティショニングが一致していればATTACH PARTITION … FROMでパーティションをコピーします。ReplacingMergeTreeからMergeTreeへの移行で測定済みです。

Calíopeでは
ビルダーは、サーバが引数なしで作成できるエンジンを提供し、テーブルを変更するときにはエンジンを変更できないことを示します。カタログには各テーブルのエンジンが表示されます。

キーワード： テーブルエンジン、エンジン、MergeTree、ReplacingMergeTree、SummingMergeTree、AggregatingMergeTree、CollapsingMergeTree、レプリケーション、MEMORY、LOG、BUFFER、DISTRIBUTED、辞書、MERGE、NULL、FINAL、ClickHouse

グラニュールの疎なインデックスとしてのソートキー、異なる場合の主キー、SAMPLE BY、スキップインデックスとプロジェクション、そしてキーを変更できない理由。

対象： ClickHouse 25.3+

ClickHouseには、行を指すインデックスはありません。どれだけ読むかを決めるのはソートキーです。データはソートキーで並べて格納され、主インデックスは疎です。行ごとではなく、行のブロックごとに1つの印を保持します。

グラニュール：読み込みの単位
それぞれのブロックはグラニュールと呼ばれ、デフォルトで8,192行を含みます（index_granularity）。サーバはグラニュール単位で読み飛ばし、残りを読みます。ORDER BY (fecha, cliente, id)の100万行のテーブルには123個のグラニュールがあり、EXPLAINがそれを示します。

EXPLAIN indexes = 1
SELECT count() FROM eventos WHERE fecha = '2026-02-01';

キーの最初の列で絞り込むと、実行計画にはGranules: 3/123と二分探索が表示されます。キーの2番目の列であるclienteだけで絞り込むと、Granules: 101/123と表示され、ほぼテーブル全体になります。キーの列の順序が重要です。よく絞り込みに使い、異なる値が少ない列を先に置きます。

主キーはソートキーより短くできる
PRIMARY KEYはORDER BYの先頭部分でなければなりません。書かなければ、両者は同じです。ORDER BY (fecha, cliente, id) PRIMARY KEY (fecha, cliente)とすると、行は3つの列で並べられ、メモリー上のインデックスは2つだけを保持します。メモリーは少なく、ディスク上の順序は同じです。主キーは一意ではありません。同じキーを持つ2つの行が並んで存在します。

SAMPLE BY
データの一部をクエリーできます（SELECT … SAMPLE 0.1）。サンプリングの式は主キーに含まれていなければならず、そうでなければサーバはCREATEを拒否します。通常はハッシュを使います（ORDER BY intHash32(id) SAMPLE BY intHash32(id)）。測定結果：10万行に対するSAMPLE 0.1は10,039行を数えました。

スキップインデックス：探すのではなく、飛ばす
グラニュールのグループごとに要約を保持し、探しているものが確実に含まれていないグラニュールを飛ばすために使います。
- minmax：最小値と最大値。
- set(N)：最大N個の異なる値。
- bloom_filter：おおよその所属判定。キーに含まれない列での等値比較に使います。
- ngrambf_v1とtokenbf_v1：テキスト内の断片や単語の検索に使います。

同じテーブルでの測定結果：bloom_filterで1つのURLを探すと、123個すべてではなく123個中20個のグラニュールを読みました。そして、テーブル全体に散らばった金額に対するminmaxは、1つも飛ばしませんでした。スキップインデックスが役立つのは、値がキーに沿ってまとまっている場合だけです。

プロジェクション：別の順序でもう一度持つテーブル
プロジェクションはデータを別の順序でもう一度格納し、役立つ場合はサーバが自分で選びます。

ALTER TABLE eventos ADD PROJECTION por_cliente (SELECT * ORDER BY cliente);
ALTER TABLE eventos MATERIALIZE PROJECTION por_cliente;

clienteでの同じクエリーは、101個から123個中1個のグラニュールに減りました。その代わり、プロジェクションは5.3 MiB多く使い、挿入のたびにデータを2回書き込みます。

ソートキーは変更できない
ALTER TABLE … MODIFY ORDER BYでは、その同じALTERで作成した列を末尾に追加することしかできません。並べ替えたり、既存の列を追加したりするとエラーになります（Existing column … is used in the expression that was added to the sorting key）。キーを本当に変えるには、別のテーブルを作成してデータをコピーします。

Calíopeでは
ClickHouseでは、カタログの「インデックス」タブは「キー」という名前になり、ソートキー、パーティションキー、異なる場合は主キー、サンプリングキー、スキップインデックス、プロジェクションを表示します。ビジュアルな実行計画ビューアは読み込みごとのグラニュール数を数え、インデックスアドバイザはCREATE INDEXではなくスキップインデックスを提案します。

キーワード： ソートキー、ORDER BY、主キー、主インデックス、グラニュール、index_granularity、SAMPLE BY、スキップインデックス、データスキップインデックス、MINMAX、SET、bloom_filter、ngrambf_v1、tokenbf_v1、プロジェクション、EXPLAIN、ClickHouse

PARTITION BYとパート、日単位のパーティショニングがよくある間違いである理由、OPTIMIZEとDROP PARTITION、そしてマージ時に適用される行と列のTTL。

対象： ClickHouse 25.3+

ClickHouseでのパーティションは、PARTITION BYの値を共有するパートのグループで、主な役割はデータの管理です。たとえば1か月分をまとめて削除したり移動したりします。クエリーを速くするのはソートキーの役目で、パーティショニングはその代わりにはなりません。

パートとパーティション
挿入のたびに、触れるパーティションごとに少なくとも1つのパートが書き込まれ、サーバが後でそれらをマージします。マージは常に同じパーティションの中で行われます。system.partsがそれらを一覧表示し、数に入るのはactive = 1のものだけです。マージ済みのパートは、削除されるまでしばらく非アクティブのまま残ります。

CREATE TABLE ventas (fecha Date, id UInt64, importe Decimal(10, 2))
ENGINE = MergeTree
PARTITION BY toYYYYMM(fecha)
ORDER BY (fecha, id);

測定結果：9か月にわたる30万行を2回挿入すると、9個のパーティションに18個のアクティブなパートが残りました。

日単位のパーティショニングがよくある間違いである理由
パーティションが多いと小さなパートが多くなり、パートにはコストがあります。1つのパーティションでアクティブなパートが1,000個を超えると、サーバは挿入を遅らせ始め（parts_to_delay_insert）、3,000個になると拒否します（parts_to_throw_insert）。さらに、1回のINSERTで触れられるパーティションは100個までです（max_partitions_per_insert_block）。PARTITION BY fechaでの測定結果：200日分の異なる日付を含むINSERTはCode: 252 … Too many partitions for single INSERT block (more than 100)で失敗しました。よく使われるのは月単位（toYYYYMM）で、テーブルが小さければパーティショニングしません。

パーティション単位のマージと削除

OPTIMIZE TABLE ventas PARTITION 202603 FINAL;
ALTER TABLE ventas DROP PARTITION 202601;

OPTIMIZE … PARTITION … FINALは、そのパーティションのパートを1つにマージします。DROP PARTITIONは、ファイルを削除してパーティション全体を消します。測定結果は5ミリ秒でした。翌月をALTER TABLE … DELETE WHEREで削除すると54ミリ秒かかりました。ミューテーションはパートを手放すのではなく書き直すためで、この差はサイズとともに大きくなります。

TTL：マージ時に適用される有効期限

CREATE TABLE ventas (
    fecha Date, id UInt64,
    nota String TTL fecha + INTERVAL 30 DAY
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(fecha)
ORDER BY (fecha, id)
TTL fecha + INTERVAL 1 YEAR;

テーブルのTTLは期限切れの行を削除し、列のTTLはその値をデフォルトに戻します。どちらもマージ時に行われ、挿入時でも正確な時刻でもありません。測定結果：そのテーブルに2年前の行を挿入すると、クエリーしてもまだ残っており、OPTIMIZE … FINALの後に消えました。強制しなければ、サーバは4時間ごとに期限を確認します（merge_with_ttl_timeout）。そのため、TTLは一度きりの削除ではありません。期限切れのデータがしばらく見え続けることがあります。

Calíopeでは
カタログの「キー」タブには、各テーブルのパーティションキーが表示されます。サーバ情報の「ディスク使用量」は、system.partsのアクティブなパートを合計し、圧縮率を表示します。テーブルメンテナンスでは、1つのパーティションに限定したOPTIMIZEを実行できます。FINALは、パーティション全体を書き直すため、デフォルトでオフになっています。

キーワード： パーティション、PARTITION BY、パート、system.parts、アクティブ、parts_to_throw_insert、max_partitions_per_insert_block、OPTIMIZE、DROP PARTITION、TTL、有効期限、toYYYYMM、マージ、ClickHouse

キャッシュされたテーブルではなく挿入のトリガー：TOと内部テーブルの違い、POPULATE、system.view_refreshesで見る更新可能なビュー、そしてUPDATEもDELETEも見えない理由。

対象： ClickHouse 25.3+

ClickHouseのマテリアライズドビューは、結果をキャッシュした保存済みのクエリーではありません。挿入のトリガーです。ソーステーブルに行のブロックが届くたびに、ビューはそのブロックに対してSELECTを実行し、結果を書き込み先のテーブルに書き込みます。それ以前にあったものも、後で変わったものも、ビューには見えません。

TOを使うか、内部テーブルを使うか

CREATE TABLE totales (k String, total UInt64)
ENGINE = SummingMergeTree ORDER BY k;

CREATE MATERIALIZED VIEW mv_totales TO totales AS
SELECT k, sum(v) AS total FROM origen GROUP BY k;

TOを使うと、書き込み先は事前に作成された、独自の名前を持つ普通のテーブルになります。TOを使わないと、ビュー自身がENGINEを持ち、サーバはビューのUUIDを使った.inner_id.<uuid>という隠しテーブルを作成します。測定結果：TOなしのビューは.inner_id.ed264ea3-…を作成し、system.tablesでのそのUUIDは同じものでした。TOを使えばデータがどこにあるかがわかり、データを失わずにビューを削除できるので、推奨される方法です。

それ以前のデータは入らない（POPULATEを除く）
測定結果：ソースにすでに2行ある状態で、TO付きのビューと内部テーブルのビューは空で作成されました。POPULATE付きで作成したビューは、両方の行を持って作成されました。その後の新しい挿入は、3つすべてに届きました。ClickHouseのドキュメントは、POPULATEがビューを埋めている間にソースに挿入されたものは失われる可能性があると警告しています。トラフィックがある場合は、ビューを作成してから書き込み先をINSERT INTO … SELECTで手作業で埋めるほうが安全です。

ミューテーション：ビューは決して気づかない
ビューが反応するのは挿入だけです。測定結果：ALTER TABLE origen UPDATE v = 1000 WHERE k = 'a'の後、ソースではaの合計が2,000になりましたが、書き込み先は10のままでした。cの行をDELETEした後、ソースからはそれらが消えましたが、書き込み先は合計5を保ったままでした。ソースを修正したら、書き込み先は手作業で再計算します。

書き込み先もマージされる
書き込み先がSummingMergeTreeやAggregatingMergeTreeの場合、挿入のたびに部分的な行が残り、マージ時にまとめられます。書き込み先へのクエリーは、個々の行を読むのではなく集計します（sum(total)、-Merge）。

更新可能なビュー：もう1つの種類

CREATE MATERIALIZED VIEW resumen
REFRESH EVERY 1 MINUTE
ENGINE = MergeTree ORDER BY k AS
SELECT k, count() AS c FROM origen GROUP BY k;

REFRESH付きのビューは、キャッシュされたテーブルのように動作します。一定の間隔ごとにクエリー全体を再実行して結果を置き換えるので、ミューテーションによる変更も含めてソース全体が見えます。system.view_refreshesは、その状態（Scheduled、Running…）、最後に成功した更新、次回の更新を示します。ClickHouse 26.8での測定結果：実験的な設定なしで動作します。

Calíopeでは
ClickHouseでは、カタログに「マテリアライズドビュー」タブがあり、それぞれがどのテーブルから読み、どのテーブルに書き込むか（内部テーブルの場合は、クエリーに使う名前）、書き込み先のサイズと行数、最後に書き込まれた行、更新可能なビューであればそのスケジュールと更新履歴を表示します。エディタのツリーでは、普通のビューとは別にまとめられています。

キーワード： マテリアライズドビュー、TO、inner_id、POPULATE、REFRESH EVERY、更新可能、view_refreshes、トリガー、SummingMergeTree、ミューテーション、ClickHouse

非同期のパートの書き直しとしてのUPDATEとDELETE、system.mutationsと失敗の理由、KILL MUTATION、mutations_sync、軽量DELETE、そしてミューテーションが行数を数えない理由。

対象： ClickHouse 25.3+

ClickHouseは行をその場で変更しません。ALTER TABLE … UPDATEとALTER TABLE … DELETEはミューテーションです。サーバはそれを記録してすぐに応答し、その後、影響を受けるパートをバックグラウンドで書き直します。1行しか変わらなくても、パート全体を書き直します。

実行すると何が起きるか

ALTER TABLE eventos UPDATE estado = 'cerrado' WHERE id < 10;
SELECT mutation_id, parts_to_do, is_done FROM system.mutations WHERE table = 'eventos';

5万行のパートが2つあるテーブルでの測定結果：文は10ミリ秒で、parts_to_do = 2とis_done = 0を返しました。完了すると、パートall_1_1_0とall_2_2_0はall_1_1_0_3とall_2_2_0_3に置き換えられていました。10行を変えるために、それぞれ5万行が書き直されたことになります。古いパートは、old_parts_lifetimeが経過するまで（デフォルトは480秒）非アクティブのままディスクに残ります。

待つか、待たないか
mutations_syncはデフォルトで0で、文は待ちません。1では現在のレプリカを、2ではすべてのレプリカを待ちます。測定結果：mutations_sync = 2では、次のSELECTはすでに新しい値を見ていました。

ミューテーションが失敗したとき
失敗したミューテーションは、取り消されることも破棄されることもありません。再試行を続け、そのテーブルで後ろに並んだミューテーションをブロックします。測定結果：ゼロ除算を含むミューテーションの後、次のミューテーションは、最初のものが削除されるまで適用されませんでした。理由はsystem.mutations.latest_fail_reasonにあり（Code: 153 … Division by zero）、次のようにして削除します。

KILL MUTATION WHERE database = 'demo' AND table = 'eventos' AND NOT is_done SYNC;

ミューテーションがすでに書き直した部分は、元に戻りません。

ミューテーションは行数を数えない
サーバは、ミューテーションをキューに入れるときに影響を受ける行を数えません。system.query_logではwritten_rows = 0と表示されます。ミューテーションについて表示される行数は、どれも作り話になってしまいます。

軽量DELETE
DELETE FROM テーブル WHERE …はパートを書き直しません。行に削除済みの印を付けてクエリーから隠し、次のマージで実際に削除されます。測定結果：10万行のうち、DELETE FROM … WHERE id < 3の後には99,997行が見え、apply_deleted_mask = 0では10万行すべてがまだ残っていました。lightweight_deletes_syncはデフォルトで2で、印がすべてのレプリカに届くまで待ちます。

Calíopeでは
ClickHouseでセルを編集したり行を削除したりすると、ALTER TABLE … UPDATEまたはALTER TABLE … DELETEが書き込まれ、エディタは行数ではなく、ミューテーションがキューに入ったことをその識別子とともに示します。プロセスには、完了していないミューテーションが失敗の理由をテキストで添えて表示され、キャンセルすることもできます。

キーワード： ミューテーション、ALTER TABLE UPDATE、ALTER TABLE DELETE、system.mutations、latest_fail_reason、KILL MUTATION、mutations_sync、DELETE FROM、軽量DELETE、lightweight_deletes_sync、parts_to_do

トランザクションはありません：INSERTが保証すること、ブロックをまたいで原子的でない理由、ブロックの重複排除、そしてBEGINなしで読み込みを冪等にする方法。

対象： ClickHouse 25.3+

ClickHouseにはトランザクションがありません。BEGIN TRANSACTIONはCode: 48 … Transactions are not supported (NOT_IMPLEMENTED)を返し、implicit_transaction = 1も同じです。COMMITもROLLBACKもなく、それぞれの文が独立しています。

INSERTが保証すること
INSERTはブロック単位で書き込まれ（max_insert_block_size、デフォルトは1,048,449行）、各ブロックは原子的です。全体が入るか、まったく入らないかのどちらかです。ブロックをまたいだ保証はありません。測定結果：10万行ずつのブロックで40万行をINSERT … SELECTし、25万行目で失敗させると、10万行が書き込まれたまま残りました。失敗したINSERTはテーブルを読み込み途中の状態にすることがあり、それを元に戻すものはありません。

ブロックの重複排除
Replicated*テーブルは、最近挿入したブロックのハッシュを覚えておき（replicated_deduplication_window、1万個）、同じブロックが再び届くと破棄します。測定結果：ReplicatedMergeTreeで同じINSERTを2回実行すると、4行ではなく2行が残りました。普通のMergeTreeではこのウインドウは0で（non_replicated_deduplication_window）、同じINSERTを2回実行すると4行が残りました。

読み込みを冪等にする方法
- 同じブロックでバッチを繰り返します。Replicated*では、重複排除が繰り返し分を破棄します。
- insert_deduplication_tokenでバッチに名前を付けます。ウインドウを100にしたMergeTreeでの測定結果：同じトークンで異なるデータを持つ2回目のINSERTは入りませんでした。
- ステージング用のテーブルに読み込み、ALTER TABLE … REPLACE PARTITION … FROMでパーティション全体を一度に入れ替えます（サーバのドキュメントによる）。
- 次のマージまで重複した行があっても構わない場合は、ReplacingMergeTreeを使い、FINAL付きで読みます。

Calíopeでは
ClickHouseでは、エディタに「トランザクション」メニューは表示されません。開くものも元に戻すものもなく、それぞれの文は実行した時点で完了しています。

キーワード： トランザクション、BEGIN、COMMIT、ROLLBACK、原子性、INSERT、ブロック、max_insert_block_size、重複排除、insert_deduplicate、insert_deduplication_token、replicated_deduplication_window、冪等、NOT_IMPLEMENTED

PREWHERE、FINALのコスト、EXPLAINで読まれるグラニュール、max_threadsとmax_memory_usage、log_comment付きのsystem.query_log、そしてキーを使わない3つのクエリー。

対象： ClickHouse 25.3+

ClickHouseでのパフォーマンスは、ほとんどがどれだけ読むかで決まります。キーがいくつのグラニュールを飛ばし、いくつの列を取り出す必要があるかです。

EXPLAINでのグラニュール

EXPLAIN indexes = 1
SELECT count() FROM eventos WHERE fecha BETWEEN '2026-02-01' AND '2026-02-03';

ORDER BY (fecha, cliente, id)の100万行で、実行計画にはGranules: 5/123と表示されました。123個のグラニュールのうち5個を読んだということです。この比率が、最初に見るべきものです。

キーを使わない3つのクエリー
同じテーブルでの測定結果：
- キーに含まれない列で絞り込む（url LIKE '%/p/12%'）：123/123。
- キーの列とそうでない列を混ぜたOR（fecha = … OR url = …）：123/123。
- キーの2番目の列だけで絞り込む（cliente = 42）：101/123。

PREWHERE
PREWHEREを使うと、サーバはまず絞り込みの列を読み、条件を満たした行についてだけ残りの列を取り出します。optimize_move_to_prewhereは1で、これを自動で行います。20行を返すurlでの絞り込みと、SELECTに200バイトの列を含めた場合の測定結果：最適化ありで30 MiBを読み、なしでは204 MiBでした。

FINALにはコストがある
FINALは、ReplacingMergeTreeの重複した行をその場でマージします。100万個のキーを持つ200万行での測定結果：FINALなしのsum(v)は42ミリ秒で、重複も数えました。FINAL付きでは323ミリ秒かかり、メモリーは5.5 MiBではなく42 MiBを使いました。

スレッドとメモリー
max_threadsはauto(N)で、コアごとに1つです（測定したサーバでは8）。max_memory_usageは0で、クエリーごとの上限はありません。上限を設けると、それを超えたクエリーはCode: 241 … Query memory limit exceededで失敗します。

system.query_log
すべてのクエリーがここに実行時間、read_rows、read_bytes、memory_usageを残し、log_commentでタグを付けると見つけやすくなります。

SELECT … SETTINGS log_comment = 'informe-diario';
SYSTEM FLUSH LOGS;
SELECT query_duration_ms, read_rows, formatReadableSize(read_bytes), formatReadableSize(memory_usage)
FROM system.query_log WHERE type = 'QueryFinish' AND log_comment = 'informe-diario';

Calíopeでは
ビジュアルな実行計画ビューアは、読み込みの各ステップで読んだグラニュールを表示し、1つも飛ばしていない場合は赤で示します。スロークエリーはsystem.query_logから取得され、時間の横に読んだバイト数とメモリーが表示されます。Calíope自身が実行するものにはlog_commentでタグが付けられ、非表示にできます。

キーワード： パフォーマンス、PREWHERE、FINAL、グラニュール、EXPLAIN、インデックス、max_threads、max_memory_usage、query_log、read_bytes、memory_usage、log_comment、ソートキー

バックグラウンドのマージ、system.mergesとsystem.parts、OPTIMIZEとOPTIMIZE FINALの違い、パートのしきい値、そして「パートが多すぎる」が最もよくある運用上のエラーである理由。

対象： ClickHouse 25.3+

INSERTのたびに、ディスク上に新しいパートが作成されます。サーバはバックグラウンドで、小さなパートを大きなパートにマージします。それによってテーブルのパートが少なく保たれ、ReplacingMergeTree、TTL、軽量削除が適用されます。

パートとマージを見る

SELECT partition, name, rows, active FROM system.parts WHERE table = 'eventos';
SELECT table, elapsed, progress, num_parts, result_part_name FROM system.merges;

非アクティブなパートは、すでにマージに含まれたパートです。old_parts_lifetime（480秒）が経過するまでディスクに残り、その後削除されます。

OPTIMIZEとOPTIMIZE FINAL
OPTIMIZE TABLEはマージを今すぐ要求します。OPTIMIZE TABLE … FINALは、すでに1つしかなくても、パーティションごとにパートが1つになるまでマージを強制します。測定結果：マージを止めてINSERTを5回実行すると、パートは5つになりました。小さかったためOPTIMIZEで1つにまとまり、その1つのパートにOPTIMIZE … FINALを実行すると、パート全体が書き直されました。FINALはテーブルを書き直すので、大きなテーブルでは大きな作業になります。

パートが多すぎる
INSERTがパートを作る速さがマージの速さを上回ると、サーバはまず速度を落とし、その後で拒否します。
- parts_to_delay_insert（デフォルトは1,000）：これを超えると、INSERTのたびに遅延を入れます。
- parts_to_throw_insert（3,000）：これを超えると、拒否します。

しきい値を4に下げての測定結果：5回目のINSERTはCode: 252 … Too many parts … Merges are processing significantly slower than inserts (TOO_MANY_PARTS)で失敗しました。これは最もよくある運用上のエラーで、ほとんどの場合、1行ずつ、またはごく小さなバッチで挿入していること、あるいはパーティショニングが細かすぎることが原因です。解決策は、数千行単位のバッチで挿入することです。測定したサーバ（26.8）ではasync_insertがデフォルトでオンになっており、ドキュメントによると、同時に届いた小さなINSERTを1つのパートにまとめます。ただし、1つずつ順に実行した3回のINSERTは、やはり3つのパートになりました。

Calíopeでは
テーブルメンテナンスでは、FINALオプション付きのOPTIMIZEを実行できます。FINALはテーブルを書き直すため、最初はオフになっていて、実行前に警告します。1つのパーティションに限定することもできます。サーバ情報には、アクティブなパートを合計した各テーブルのサイズと圧縮率が表示されます。

キーワード： マージ、OPTIMIZE、OPTIMIZE FINAL、system.merges、system.parts、パート、非アクティブなパート、old_parts_lifetime、parts_to_delay_insert、parts_to_throw_insert、パートが多すぎる、TOO_MANY_PARTS、async_insert

ReplicatedMergeTreeとKeeper、{shard}と{replica}のマクロ、system.replicas、SYNC REPLICAとRESTART REPLICA、Keeperがないときに起きること、DROP TABLE … SYNC、そしてsystem.clusters。

対象： ClickHouse 25.3+

ClickHouseのレプリケーションはテーブル単位です。それぞれのReplicated*テーブルは、Keeper（またはZooKeeper）を通じてコピーと調整します。Keeperは、どのパートが存在し、何をコピーする必要があるかを記録します。プライマリはなく、どのレプリカも書き込みを受け付けます。

レプリケートされたテーブルを作成する

CREATE TABLE ventas (id UInt32, v String)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/ventas', '{replica}')
ORDER BY id;

パスはKeeperの中でテーブルを識別し、すべてのレプリカで同じです。{shard}と{replica}は、各サーバが自分の設定から埋めるマクロです（system.macros）。測定したペアでは、両方のレプリカがshard = 01で、replicaは一方がr1、もう一方がr2です。テーブルは各レプリカで作成し、行は自動的に届きます。

system.replicas

SELECT table, is_readonly, is_session_expired, absolute_delay, queue_size, active_replicas, total_replicas FROM system.replicas;

- absolute_delay：最も新しいレプリカから何秒遅れているか。
- queue_size：保留中のタスク（パートの取得、マージ、ミューテーション）。
- is_readonlyとis_session_expired：レプリカがKeeperを失ったこと。

測定結果：r2で取得を止め（SYSTEM STOP FETCHES）、r1に1行挿入すると、r2はqueue_size = 1で2行のままでした。再開すると3行になりました。

SYNC REPLICAとRESTART REPLICA
SYSTEM SYNC REPLICA テーブルは、レプリカがキューを空にするまで待ちます。測定では、3行すべてが最新の状態で戻りました。SYSTEM RESTART REPLICA テーブルは、状態をKeeperから読み直します。その後はis_readonly = 0、active_replicas = 2になりました。

Keeperがなければ、読み出し専用
Keeperを止めての測定結果：テーブルはis_readonly = 1とis_session_expired = 1になり、読み込みは引き続き動作しましたが、INSERTは120秒待ってTIMEOUT_EXCEEDEDで失敗しました。Keeperが戻ると、レプリカは自動的に回復しました。

DROP TABLE … SYNC
レプリケートされたテーブルをSYNCなしで削除すると、Keeperに残った痕跡は後で片付けられるため、すぐに作り直すとCode: 253 … Replica … already exists (REPLICA_ALREADY_EXISTS)で失敗します（測定済み）。DROP TABLE … SYNCでは、文がその片付けを待ちます。

system.clusters
クラスタはSQLで作成するのではなく、サーバの設定で宣言します。system.clustersは、シャードとレプリカとともにそれらを一覧表示します。テストベッドでは、caliope_parに2つのレプリカ（clickhouse-r1とclickhouse-r2）を持つ1つのシャードがあります。

Calíopeでは
ClickHouseでは、レプリケーションモニタはテーブルごとに、アクティブなレプリカ数と合計数、欠けているレプリカの名前、遅延とキュー、そして別の状態としてKeeperの喪失を表示します。トポロジは、system.clustersが宣言する構成を描きます。

キーワード： レプリケーション、ReplicatedMergeTree、Keeper、ZooKeeper、マクロ、シャード、レプリカ、system.replicas、absolute_delay、queue_size、is_readonly、SYNC REPLICA、RESTART REPLICA、system.clusters、REPLICA_ALREADY_EXISTS

サーバのファイルにあるユーザとSQLで作成したユーザの違い、ロール、GRANTと部分的な取り消し、クォータ、設定プロファイル、行ポリシー、そしてパスワードをURLに入れない理由。

対象： ClickHouse 25.3+

ClickHouseはユーザを2つの場所に保持し、ユーザがどちらから来たかによって、そのユーザに対してできることが決まります。

2つのユーザストレージ

SELECT name, storage, auth_type FROM system.users;

- users_xml：サーバのファイル（users.xmlとusers.d/）で宣言されたユーザ。変更するにはそれらのファイルを編集するしかなく、それらに対するALTER USERはCode: 495 … ACCESS_STORAGE_READONLYで失敗します（測定済み）。
- local_directory：CREATE USERで作成したユーザ。SQLで管理し、サーバがディスクに保存します。

SQLでユーザを作成するには、アクセス管理の権限を持つアカウント（設定のaccess_management、またはACCESS MANAGEMENT権限）が必要です。

ロール、GRANT、部分的な取り消し

CREATE ROLE lectura;
GRANT SELECT ON demo.* TO lectura;
REVOKE SELECT ON demo.eventos FROM lectura;
GRANT lectura TO ana;
SET DEFAULT ROLE lectura TO ana;

データベース全体に付与した権限のうち1つのテーブルにREVOKEを実行しても、データベースへの付与は削除されず、部分的な取り消しが残ります。SHOW GRANTS FOR lecturaは両方の行を表示し、system.grantsは2行目にis_partial_revoke = 1の印を付けます（測定済み）。そのロールでは、demo.productosは読めますが、demo.eventosを読むとCode: 497 … ACCESS_DENIEDで失敗します。

クォータ、プロファイル、行ポリシー
- クォータ（CREATE QUOTA、system.quotas、system.quota_usage）：一定の間隔ごとのクエリー数、行数、時間の上限。サーバのドキュメントによると、超えるとクエリーはQUOTA_EXCEEDEDで拒否されます。
- 設定プロファイル（CREATE SETTINGS PROFILE … SETTINGS max_result_rows = 5 TO ana）：ユーザは接続のたびにこれを受け取り、system.settingsはchanged = 1で表示します（測定済み）。
- 行ポリシー（CREATE ROW POLICY … ON demo.eventos USING id <= 3 TO ana）：サーバは、ユーザが読むものすべてにその絞り込みを加えます。測定結果：count()は、そのユーザでは3、管理者では90でした。

パスワードはURLに入れない
HTTPインターフェイスはアドレスに?user=…&password=…を受け付けますが、URLはターミナルの履歴、プロキシのログ、ネットワークツールに残ります。測定したサーバは自身のログではそれを隠しますが（password=[HIDDEN]）、ほかのものは隠しません。Calíopeは資格情報をX-ClickHouse-UserとX-ClickHouse-Keyのヘッダで、クエリーをリクエストの本文で送ります。

Calíopeでは
ユーザには、アカウントとロールがストレージとともに一覧表示されます。users_xmlのものには南京錠のアイコンが付き、編集できません。部分的な取り消しは取り消し線付きでREVOKEのラベルとともに表示されます。書き込むには、接続しているアカウントにアクセス管理の権限が必要です。権限がなければ、ボタンは使えない状態になり、バナーに理由が表示されます。

キーワード： セキュリティ、ユーザ、ロール、GRANT、REVOKE、部分的な取り消し、is_partial_revoke、SHOW GRANTS、system.users、users_xml、local_directory、アクセス管理、クォータ、設定プロファイル、行ポリシー、パスワード、アクセス拒否

クエリーの設定とサーバの設定の違い、config.dとusers.d、HTTPで通信するときに設定を永続化する方法、そしてCalíopeがすべてのリクエストで送る設定。

対象： ClickHouse 25.3+

ClickHouseには2種類の設定があり、それらを混同するのが設定時に最もよくある間違いです。

クエリーの設定とサーバの設定

SELECT name, value, changed FROM system.settings WHERE changed;
SELECT name, value, changeable_without_restart FROM system.server_settings WHERE name = 'max_concurrent_queries';

- system.settings（測定したサーバでは1,817個）：クエリーに適用されます。クエリー（末尾のSETTINGS …）、セッション、プロファイル、またはユーザで設定します。
- system.server_settings（447個）：max_concurrent_queries（デフォルトは1,000）やmax_server_memory_usageのように、プロセス全体に適用されます。サーバの設定で変更し、changeable_without_restart列が再起動なしで適用されるかどうかを示します。測定したサーバでは、447個のうち339個が再起動を必要とします。

config.dとusers.d
設定は/etc/clickhouse-server/にあります。サーバ用のconfig.xmlと、ユーザ、プロファイル、クォータ用のusers.xmlです。自分の変更はconfig.d/とusers.d/の中の別ファイルに入れます。サーバはそれらをメインの設定と結合するので、アップグレードで上書きされません。公式のDockerイメージには、それぞれのフォルダにすでに1つずつ入っています。

HTTPではSETは続かない
HTTPのリクエストはそれぞれ独立しています。SET max_threads = 7はそのリクエストにだけ適用され、次のリクエストにはもうありません（測定済み）。設定はリクエスト自体で送るか（?max_threads=5）、ユーザに永続化します。

ALTER USER ana MODIFY SETTINGS max_threads = 3;

測定結果：それ以降、anaの新しい接続にはすべて、changed = 1でこの設定が付きます。MODIFYという語を付けないと、ALTER USER … SETTINGSはアカウントの設定をすべて置き換えます。また、これはSQLで作成したユーザでしか動作せず、users_xmlのユーザではACCESS_STORAGE_READONLYで失敗します。

Calíopeがすべてのリクエストで送るもの
数値を精度を失わずに読み、自分のクエリーを識別するための、5つの固定の設定です。
- output_format_json_quote_64bit_integers、output_format_json_quote_decimals、output_format_json_quote_64bit_floats、output_format_json_quote_denormals：64ビット整数、小数、infやnanのような値が引用符付きで届きます。JSONでは64ビット整数を正確に表せず、これらの設定がないとinfとnanはnullとして届きます。
- log_comment：system.query_logでCalíopeのクエリーにタグを付けます。

エディタはsession_idを使いません（複数の文を持つレポートだけが自分のセッションを開きます）。その理由は「制限（ClickHouse）」で説明しています。

Calíopeでは
スロークエリーは、そのしきい値をALTER USER … MODIFY SETTINGSで保存します。アカウントを変更できない場合は、コントロールの代わりに注記でそのことを示します。

キーワード： 設定、サーバの設定、system.settings、system.server_settings、config.xml、users.xml、config.d、users.d、ALTER USER、MODIFY SETTINGS、SET、max_threads、再起動、log_comment、output_format_json_quote

max_query_size、クエリーごとのメモリー、結果の上限、同時実行クエリー、パートが多すぎる場合、挿入ブロック、そしてエディタがsession_idを使わない理由。

対象： ClickHouse 25.3+

クエリーのテキスト
max_query_sizeはデフォルトで262,144バイトです。それより長いクエリーは、262,145番目の位置でCode: 62 … Max query size exceededで失敗します（測定済み）。クエリーごとにSETTINGS max_query_size = …で引き上げられます。Calíopeのダンプは、INSERT文をこの上限以下にまとめます。

メモリー
測定したサーバではmax_memory_usageは0（クエリーごとの上限なし）で、実際の上限はプロセスのmax_server_memory_usageです。上限を低くすると、クエリーはCode: 241 … MEMORY_LIMIT_EXCEEDEDで失敗し、メッセージにはどれだけ使おうとしたかが示されます。

結果のサイズ
max_result_rowsとmax_result_bytesはデフォルトで0です。上限を設定すると、result_overflow_mode = 'throw'（デフォルト）ではクエリーがCode: 396 … TOO_MANY_ROWS_OR_BYTESで失敗し、'break'ではその時点までに読んだものを返します。

同時に実行するクエリー
max_concurrent_queriesはサーバ全体（デフォルトは1,000）、max_concurrent_queries_for_userはユーザごと（0、上限なし）の設定です。超えると、新しいクエリーがCode: 202 … TOO_MANY_SIMULTANEOUS_QUERIESで失敗します（上限を1にして測定済み）。

パートが多すぎる
INSERTのたびにパートが作成されます。1つのパーティションでアクティブなパートが1,000個（parts_to_delay_insert）になるとサーバは挿入を遅らせ、3,000個（parts_to_throw_insert）になるとTOO_MANY_PARTSで拒否します。詳しくは「マージとOPTIMIZE（ClickHouse）」で説明しています。

挿入ブロック
サーバは、INSERTの行を最大max_insert_block_size行（1,048,449行）のブロックにまとめます。大きなINSERTが途中で失敗すると、それまでのブロックは書き込まれたまま残ります。原子的ではありません。詳しくは「トランザクションと原子性（ClickHouse）」で説明しています。

1つのリクエストに1つの文、そしてセッションなし
HTTPでは、各リクエストは1つの文しか受け付けません。;で区切った2つの文はMulti-statements are not allowedで失敗します（測定済み）。インターフェイスにはセッション用のsession_idがあり、それを使えばSETはリクエストをまたいで続きます。しかし、セッションは一度に1つのクエリーしか受け付けません。最初のクエリーの実行中に同じsession_idで2つ目を送ると、Code: 373 … SESSION_IS_LOCKEDで失敗します（測定済み）。そのため、エディタはこれを使いません。同じ接続の2つのタブがこのエラーになってしまうからです。複数の文を持つレポートだけが、実行のたびに新しく、ほかの誰とも共有しない自分のセッションを開きます。どのリクエストにも、そのデータベースと設定が付いています。

キーワード： 制限、max_query_size、max_memory_usage、メモリー、max_result_rows、max_result_bytes、result_overflow_mode、max_concurrent_queries、同時実行クエリー、parts_to_throw_insert、パートが多すぎる、max_insert_block_size、session_id、セッション、複数の文

日常的に目にするエラーコードを、その番号と名前とともに：原因と対処法。

対象： ClickHouse 25.3+

ClickHouseのエラーには、どれも番号と名前が付いています（Code: 60 … (UNKNOWN_TABLE)）。番号はバージョンが変わっても同じで、ドキュメントで調べるときは名前を使います。HTTPでは、番号はX-ClickHouse-Exception-Codeヘッダでも届きます。この一覧のエラーは、どれも測定したサーバで実際に発生させたものです。

60 · UNKNOWN_TABLE
そのデータベースにテーブルがありません。HTTPにはUSEがなく、データベースはリクエストのたびに送られます。選んでいるデータベースを確認するか、database.tableと書いてください。

62 · SYNTAX_ERROR
構文エラーです。メッセージには位置と、何が期待されていたかが示されます。1つのリクエストに2つの文がある場合（Multi-statements are not allowed）や、262,144バイトより長いクエリー（Max query size exceeded）でも表示されます。

53 · TYPE_MISMATCH
CAST(1 AS Array(UInt8))のような、型の間で不可能な変換です。正しい変換関数（toString、toUInt8OrNull…）を使えば解決します。

241 · MEMORY_LIMIT_EXCEEDED
クエリーがメモリーの上限を超えました。メッセージには、どれだけ使おうとしたかが示されます。早い段階で絞り込む、集計する列を減らす、サーバに余裕があればmax_memory_usageを引き上げる、といった方法が有効です。

202 · TOO_MANY_SIMULTANEOUS_QUERIES
サーバ全体またはそのユーザで、同時に実行しているクエリーが多すぎます。待てば解決します。プロセスに実行中のものが表示されます。

497 · ACCESS_DENIED
権限が不足しています。メッセージには、どの権限かが示されます（it's necessary to have the grant SELECT ON demo.eventos）。データベース全体に権限が付与されていても、部分的な取り消しがあるとこのエラーになります。

164 · READONLY
クエリーが読み出し専用モードで実行されています（ユーザ、そのプロファイル、またはクエリー自体にreadonly = 1）。書き込めるアカウントが必要です。

373 · SESSION_IS_LOCKED
同じsession_idで2つのリクエストが同時に送られました。Calíopeがセッションを開くのは複数の文を持つレポートのときだけで、実行のたびに新しいセッションを使います。このエラーが出た場合は、ほかのクライアントが原因です。

395 · FUNCTION_THROW_IF_VALUE_IS_NON_ZERO
クエリーのthrowIfが発動し、メッセージはクエリーが指定したものです。クエリーがすでに行を返し始めていた場合、エラーは応答の最後に届きます。Calíopeはそれを途中で切れた結果ではなく、エラーとして表示します。

420 · CANNOT_UPDATE_COLUMN
ソートキーの列に対するALTER TABLE … UPDATEです。キーは変更できません。新しいキーで別のテーブルを作成し、データをコピーします。

495 · ACCESS_STORAGE_READONLY
サーバのファイルで宣言されたユーザ（users_xml）を変更しようとしました。users.d/で変更するか、SQLで別のユーザを作成します。

516 · AUTHENTICATION_FAILED
ユーザまたはパスワードが間違っています。サーバはどちらかを示しません。HTTPではステータス403で届きます。

Calíopeでは
これらのエラーがエディタに表示されると、「解決方法を表示」のバナーからこのトピックに移動できます。

キーワード： エラー、コード、UNKNOWN_TABLE、SYNTAX_ERROR、TYPE_MISMATCH、MEMORY_LIMIT_EXCEEDED、TOO_MANY_SIMULTANEOUS_QUERIES、ACCESS_DENIED、READONLY、SESSION_IS_LOCKED、THROWIF、CANNOT_UPDATE_COLUMN、ACCESS_STORAGE_READONLY、AUTHENTICATION_FAILED、60、62、53、241、202、497、164、373、395、420、495、516

NUMBERは何も言わずにスケールに丸め、精度を超えるものは拒否します。BINARY_DOUBLEは2進数です。

対象： Oracle 26ai+

Oracleでは、ほとんどすべての数値がNUMBERです：10進数で、正確で、最大38桁です。INTEGERとSMALLINTは名前としてしか存在せず（測定では、どちらの列もスケール0のNUMBERとして作成されました）、UNSIGNEDも、サイズ別の整数型もありません。

NUMBER(p,s)：スケールは丸め、精度は拒否する

CREATE TABLE n (a NUMBER(5,2), c NUMBER(3), e NUMBER(5,-2));
INSERT INTO n (a) VALUES (1.005);   -- 1.01
INSERT INTO n (a) VALUES (123.456); -- 123.46
INSERT INTO n (a) VALUES (1000);    -- ORA-01438
INSERT INTO n (c) VALUES (12.6);    -- 13
INSERT INTO n (e) VALUES (12345);   -- 12300

右側でスケールを超えた分は警告なしに丸められ、左側に収まらない分はORA-01438になります。負のスケールは10の位や100の位に丸め、NUMBERだけなら値をそのまま格納します。

正確で、サイズは可変
NUMBERは10進数を格納します：0.1 + 0.2 = 0.3は真です。サイズは宣言ではなく値で決まります：VSIZEで測定すると、1は2バイト、123.45は4バイト、1234567890123は8バイトでした。

BINARY_DOUBLEとBINARY_FLOATは2進数
IEEE 754のdoubleとfloatです：計算は速く、いつもの誤差もあります。0.1d + 0.2dは3.0000000000000004E-001になり、0.3dと比べると偽でした。一方、FLOATだけなら、精度をビットで指定するNUMBERです（FLOAT(126)）。金額にはNUMBER(p,s)を使います。

BOOLEANは23aiから

CREATE TABLE bo (v BOOLEAN);
INSERT INTO bo VALUES (TRUE), (FALSE), (NULL), ('yes'), (0);
SELECT COUNT(*) FROM bo WHERE v;  -- 2

'yes'や0も受け付け、比較なしで使えます（WHERE v）。23aiより前には存在せず、CHECK付きのNUMBER(1)を使うのが慣例です。

Calíopeでは
グリッドはNUMBERを浮動小数点を通さずに正確に表示し、BOOLEANをTRUEまたはFALSEとして表示します。

キーワード： 数値、NUMBER、10進数、精度、スケール、BINARY_DOUBLE、BINARY_FLOAT、FLOAT、BOOLEAN、ORA-01438、Oracle

VARCHAR2はCHARと指定しないかぎりバイトで数え、上限は4000で、空文字列はNULLです。

対象： Oracle 26ai+

空文字列はNULL
ほかのエンジンから来たときにいちばん驚くのがこれです：Oracleでは''はまさにNULLです。測定では、'' IS NULLは真、LENGTH('')は0ではなくNULLで、''を挿入すると列はNULLになるため、COUNT(column)はそれを数えません。NOT NULLの列は''をORA-01400で拒否します。