MariaDBのデータベース関連のSQLの記事です。

項目を選択してください。

データベースの作成を開いて、CREATE DATABASEの構文・確認・既存DBがある場合の扱いを選んでください。ここはMySQL/MariaDB配下のSQLにある親ページで、実際の子ページはこの1記事です。

製品と対象を読取り確認する

新しい確認例はローカルの新規MySQL8.4.13/MariaDB11.8.9検体だけで実行しています。DB作成権限を与える命令ではなく、接続中の製品/ユーザー/選択DBと既定値を読みます。出力をそのまま公開せず、実環境では承認された管理経路で対象を確認します。

-- Read only. Confirm the product, account and intended local fixture first.
SELECT VERSION() AS server_version, CURRENT_USER() AS authenticated_account,
       DATABASE() AS selected_database, @@character_set_server AS server_charset,
       @@collation_server AS server_collation, @@lower_case_table_names AS name_mode;

USEは接続中の既定DBを選ぶ操作で、アカウント権限の付与や全プロセスの接続先変更ではありません。SHOW DATABASESやinformation_schemaの見え方は権限等にも依存し、一覧に見えないことだけでDBが存在しないと断定しません。確認だけならCREATE/DROP/GRANTへ進みません。

DDLとデータのトランザクションを分ける

この2製品の検体ではCREATE DATABASEもDROP DATABASEも、後からROLLBACKして元の状態へ戻せませんでした。atomic DDLと、利用者のトランザクションから取り消せることは別です。作成/既定変更/削除は対象・権限・復旧と承認を別に確認します。

次はあらかじめ作ったInnoDBの検体表だけを使う取消例です。残高不足/入力検証/競合制御を実装した送金システムの例ではありません。

-- Pre-created InnoDB toy table only. Not a banking/business validation example.
START TRANSACTION;
UPDATE cwiki_w22_tx.accounts SET balance = balance - 10 WHERE id = 1;
UPDATE cwiki_w22_tx.accounts SET balance = balance + 10 WHERE id = 2;
ROLLBACK;
SELECT id, balance FROM cwiki_w22_tx.accounts ORDER BY id;

こちらは別の確定例です。COMMITとROLLBACKを一連の「確定後の取消手順」として実行しません。この検体では確定後にROLLBACKしても、90/110へ変わった値は戻りませんでした。

-- Separate alternative to rollback-dml.sql, not its cancellation step.
START TRANSACTION;
UPDATE cwiki_w22_tx.accounts SET balance = balance - 10 WHERE id = 1;
UPDATE cwiki_w22_tx.accounts SET balance = balance + 10 WHERE id = 2;
COMMIT;
SELECT id, balance FROM cwiki_w22_tx.accounts ORDER BY id;

旧SQL案内と一般DB比較の読み方

続く旧SQL案内は元の目的/導線を保つ参考資料です。日本語/角括弧/省略記号は説明用で、そのまま実行しません。既存の一般DB比較・コードも補足として残しますが、分類だけで性能や製品選定を決めず、個別の要件・設定・対象版を確認します。

本稿は MariaDB / MySQL のデータベース関連 SQL に関する記事です。データベース自体の作成・確認・削除・選択・文字コード設定といった、データベースレベルの操作をまとめます。

子ページから項目を選択してください。

本ページの子ページ

• データベースの作成 — CREATE DATABASE

データベース関連 SQL の早見表

元例の注意：操作の対応表です。日本語/角括弧/省略は置換箇所で、全命令を順次実行しません。ALTERは既存列の変換ではなく、DROPは破壊的な別操作です。

操作	SQL
一覧表示	SHOW DATABASES;
作成	CREATE DATABASE 名 [DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci];
選択	USE 名;
現在のDB確認	SELECT DATABASE();
定義の確認	SHOW CREATE DATABASE 名;
文字コードを変更	ALTER DATABASE 名 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
削除	DROP DATABASE 名;
存在確認付き作成	CREATE DATABASE IF NOT EXISTS 名 ...;
存在確認付き削除	DROP DATABASE IF EXISTS 名;

典型的なデータベース作成

元例の注意：元myappは架空名です。既存の同名DBへ実行せず、照合順序も一律推奨ではありません。USEはこの接続だけの選択です。

-- 推奨: utf8mb4 (絵文字対応) CREATE DATABASE myapp   DEFAULT CHARACTER SET utf8mb4   COLLATE utf8mb4_unicode_ci; -- 利用宣言 USE myapp; -- 定義確認 SHOW CREATE DATABASE myapp;

information_schema での確認

元例の注意：見えるschemaは権限等にも依存します。全DB/アカウントの情報をそのまま公開せず、見えないことだけで不存在と判定しません。

SELECT schema_name, default_character_set_name, default_collation_name   FROM information_schema.schemata  ORDER BY schema_name;

文字コードと照合順序 (Collation) の選定

元例の注意：文字コード/照合順序の概要です。製品/版で名前と比較規則が異なり、最速/完全互換や全用途の推奨表ではありません。

選定	理由
utf8mb4 を使う	絵文字や一部の漢字を扱えない utf8 (3バイト) ではなく、4バイトの utf8mb4
utf8mb4_0900_ai_ci (MySQL 8.0+)	対象版/設定の既定を確認。名前だけで性能/互換性の改善を保証しない
utf8mb4_unicode_ci	従来から広く使われている。互換性目的
utf8mb4_bin	比較要件/末尾空白/版を個別に検査し、ID全般の万能指定にしない

権限とユーザ管理

新規 DB を作ったら、アプリ用ユーザに必要最小限の権限を付与します。

元例の注意：%と公開秘密値を既存環境へ追加せず、CRUD全部を必須にしません。通常のCREATE USER/GRANT後に念のためのFLUSHは不要です。

-- ユーザ作成 CREATE USER 'app'@'%' IDENTIFIED BY '********'; -- DB 単位で権限付与 (SELECT/INSERT/UPDATE/DELETE のみ) GRANT SELECT, INSERT, UPDATE, DELETE ON myapp.* TO 'app'@'%'; -- 反映 FLUSH PRIVILEGES;

注意点

• DROP DATABASE はROLLBACKで取り消せない。本番は保護範囲と復元手順/承認を別に確認
• 文字コードを後から変更するとテーブル・カラム単位の Collation が混在しやすい。新規作成時に決める
• 本番アプリ用ユーザに ALL PRIVILEGES や GRANT 権限を渡さない
• レプリケーションの書込先/フィルタ/伝搬・権限を確認する。全構成で自動伝搬/安全を保証しない
• クラウド (RDS / Aurora) では root 相当のスーパー権限が制限されており、一部の DDL は不可

関連

• 親カテゴリ: SQL (MariaDB)
• 子ページ: データベースの作成
• 関連: MySQL / MariaDB / SQL / ユーザー関連 / テーブル関連

補足：既存の一般DB比較と基礎説明

旧例の注意：既存の一般DB比較を補足として残します。MySQL/MariaDBのSQL案内や実子は序盤へ戻してあり、全製品を同じ実行対象にしません。

この記事の要点

RDBMS: MySQL / PostgreSQL / Oracle / SQL Server / SQLite / MariaDB NoSQL: MongoDB（ドキュメント） / Redis（KVS） / Cassandra / DynamoDB NewSQL: CockroachDB / TiDB（分散だが SQL と ACID を両立） ACID（Atomicity / Consistency / Isolation / Durability）とトランザクション 正規化（第1〜第3 正規形）、インデックス、Foreign Key、ER 図、ORM

データベースの大分類

旧例の注意：分類名だけで得意/不得意を断定していた箇所を訂正しました。wide-columnと列指向、schema設計の柔軟性とtransactionの有無は別です。

分類	代表製品	用途/モデルの例	個別に確認すること
RDBMS	MySQL / PostgreSQL / Oracle / SQL Server	整合性・複雑クエリ・JOIN	分散/拡張の可否は製品・構成別。RDBMS全般で不可能とは扱わない
KVS	Redis / Memcached / DynamoDB	高速・キャッシュ	複雑クエリ
ドキュメント	MongoDB / Couchbase	ドキュメントモデル。設計/検証が不要という意味ではない	対応方式/制約を製品別に確認。MongoDBにも複数文書のトランザクションがある
wide-columnと列指向を区別	Cassandra / HBase / ClickHouse	Cassandra等とClickHouseの分析向け列指向は同一モデルではない	モデル/クエリ/更新特性を製品別に確認
グラフ	Neo4j / Amazon Neptune	関係探索・推薦	大量バルク処理
時系列	InfluxDB / TimescaleDB	計測データ・IoT	汎用 OLTP
NewSQL	CockroachDB / TiDB / Spanner	水平スケール + ACID	分散構成/障害/運用条件を個別に確認
全文検索	Elasticsearch / OpenSearch / Solr	あいまい検索・スコアリング	検索への反映遅延/更新条件を個別に確認

主要 RDBMS の特徴

旧例の注意：略記であり、全edition/契約/配布物の利用条件を網羅しません。最高性能という順位付けや全版の互換性を保証する表でもありません。

製品	ライセンス	特徴	主な用途
MySQL	GPL + Oracle 商用	軽量・採用実績豊富	Web アプリ全般
MariaDB	GPL	MySQL由来だが、版/構文/機能/データ形式を一律互換としない	OSS 志向の Web
PostgreSQL	PostgreSQL ライセンス	SQL 標準準拠・拡張機能豊富 (PostGIS, pg_trgm)	分析系・GIS・複雑要件
Oracle Database	商用	機能/構成を要件別に評価。製品名だけで最高性能と順位付けしない	金融・基幹システム
SQL Server	edition/配布条件・契約を確認	T-SQL等。全構成がWindows専用という意味ではない	Windows 系業務
SQLite	パブリックドメイン	ファイル DB・組み込み	モバイル・テスト・小規模

ACID とトランザクション

ACIDはトランザクションの性質を考える枠組みです。全RDBMS/全storage engine/全設定が同じ保証を持つという意味ではなく、NoSQLでは不可能という分類でもありません。

旧例の注意：ACIDの保証は製品/engine/設定/分離レベルを確認します。業務上の正しさ、全DDLの取消や全障害の復旧はCOMMITだけでは保証されません。

性質	意味	例
Atomicity（原子性）	全実行か全取消か	振込で片方だけ反映されない
Consistency（整合性）	宣言した制約とアプリの不変条件を区別	有効なFK等の違反を拒否。検査時機や対象は製品/設定で異なる
Isolation（隔離性）	可視性/競合の扱いは分離レベルごとに異なる	全レベルがSERIALIZABLEと同じ保証を持つわけではない
Durability（耐久性）	確定後の耐久性は製品の保証/ログ・同期等の設定と障害条件で確認	COMMITだけで全障害時の無損失やbackup不要を保証しない

旧例の注意：旧コードのCOMMIT/ROLLBACKは別の終了方法です。確定後の取消として連続実行せず、分離レベルも製品/版と設定時機を分けます。実業務のaccounts表へ試しません。

-- トランザクションの基本
BEGIN;  -- または START TRANSACTION

UPDATE accounts SET balance = balance - 1000 WHERE id = 1;
UPDATE accounts SET balance = balance + 1000 WHERE id = 2;

-- すべて成功したら確定
COMMIT;

-- 途中でエラーなら取り消し
ROLLBACK;

-- 分離レベル
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;     -- PG/Oracle 既定
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;    -- MySQL InnoDB 既定
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;       -- 最高、ロック競合増

正規化（Normal Form）

旧例の注意：短い入門表で、定義域/候補キー/従属関係の検討を省略する意味ではありません。comma入り文字列というだけで1NF違反と即断しません。

正規形	条件	違反例
第 1 正規形 (1NF)	1 セル 1 値（繰り返しグループ無し）	tags = "PHP,Laravel,MySQL"
第 2 正規形 (2NF)	1NF + 部分関数従属を排除	複合キーの一部にだけ依存する列
第 3 正規形 (3NF)	2NF + 推移的関数従属を排除	user_id → dept_id → dept_name の dept_name 持ち込み
BCNF / 4NF / 5NF	より厳格な分解	関数/多値/結合従属と要件に応じて検討し、一律に不要としない

正規化は依存関係/更新整合性を検討するためのものです。遅いと感じただけで非正規化せず、SQL/索引/実測と整合性維持の方法を確認します。1セル1値という短い表現だけで全正規形を判定しません。

インデックスと外部キー

旧例の注意：MySQL系とPostgreSQLの構文が混ざり、orders作成前の索引等もあるため、一括実行できる教材ではありません。CASCADEで関連データが消える影響も別に確認します。

-- 主キー（自動的にユニークインデックスが作られる）
CREATE TABLE users (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    email VARCHAR(255) NOT NULL UNIQUE,    -- UNIQUE インデックス
    name VARCHAR(100) NOT NULL,
    created_at DATETIME NOT NULL
);

-- 通常インデックス
CREATE INDEX idx_users_created_at ON users (created_at);

-- 複合インデックス（先頭列から左寄せで使われる）
CREATE INDEX idx_orders_user_status ON orders (user_id, status);

-- 部分インデックス（PostgreSQL）
CREATE INDEX idx_orders_active ON orders (created_at) WHERE status = 'active';

-- 外部キー制約
CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    amount INT,
    FOREIGN KEY (user_id) REFERENCES users(id)
        ON DELETE CASCADE
        ON UPDATE CASCADE
);

レプリケーションとシャーディング

旧例の注意：方式の概略で、遅延/障害時切替/整合性/全replicaへの伝搬や無停止を保証しません。新規分散構成を今回導入していません。

手法	目的	仕組み
主従レプリケーション	読み取り負荷分散・冗長化	書きは Primary、読みは Replica
マルチマスター	書き込みも分散	競合解決が必要 (Galera, BDR)
シャーディング	巨大データの水平分割	ユーザー ID 等でハッシュ分散
パーティショニング	巨大テーブル内分割	日付や ID で分割 (RANGE/HASH/LIST)
Read Replica	クラウドの非同期 Replica	RDS / Cloud SQL の機能

NoSQL の概要

旧例の注意：MongoDBのJavaScript shellとRedis CLIの別命令が混在する記録です。MariaDB/MySQLや同じshellへ順次貼り付けず、実行検証済みとも扱いません。

// MongoDB（ドキュメント型）
db.users.insertOne({
  name: "taro",
  age: 30,
  tags: ["php", "laravel"],
  address: { city: "Tokyo", zip: "100-0001" }
});
db.users.find({ age: { $gte: 18 }, "address.city": "Tokyo" });

// Redis（KVS）
SET user:1:name "taro"
EXPIRE user:1:name 3600
LPUSH queue:emails "user@example.com"
HSET user:1 name "taro" age 30
ZADD leaderboard 1500 "alice" 1800 "bob"

ORM（Object-Relational Mapping）

旧例の注意：ORM/仕様/SQLマッパー/コード生成を一律に同じ仕組みとしません。言語別の例で、追加依存の導入推奨ではありません。

言語	ORM/DBアクセス技術の例（方式は異なる）
PHP	Eloquent (Laravel) / Doctrine (Symfony)
Java	Hibernate / JPA。MyBatisはSQLマッピング等の永続化frameworkで同一方式とは限らない
Python	SQLAlchemy / Django ORM
Node.js	Prisma / TypeORM / Sequelize
Ruby	ActiveRecord (Rails)
Go	GORM / ent / sqlc。ORMとSQLからのコード生成を同じ抽象化と扱わない
C#	Entity Framework Core

ER 図（Entity Relationship Diagram）

テーブル間の関係を可視化する図。1:1 / 1:N / N:M を矢印で表現します。

• 1:1 — ユーザー ↔ プロフィール
• 1:N — ユーザー → 注文（一人が複数注文）
• N:M — 学生 ↔ 科目（中間テーブルが必要）

用途別 DB 選定の目安

旧例の注意：過去に並べられた候補名で、金融/分析等の用途だけで製品選定や費用/ライセンス/性能を決定する表ではありません。

用途	過去の候補例（推奨の確定ではない）
Web アプリ全般	MySQL / PostgreSQL
キャッシュ・セッション	Redis
大量ログ・イベント	Elasticsearch / ClickHouse
IoT 計測データ	InfluxDB / TimescaleDB
金融基幹	Oracle / SQL Server
サーバーレス・低運用	DynamoDB / Firestore
分析・BI	BigQuery / Snowflake / Redshift

FAQ

Q: MySQL と PostgreSQL、どちらを選べばいい？
A: クエリ/整合性/運用/拡張/移行条件を整理し、対象版と実測で判断します。未計測の採用増加や単純な性能順位を選定根拠にしません。

Q: NoSQL を採用すべきタイミングは？
A: どれか1条件だけで採用を確定しません。アクセス/更新/整合性/運用を整理し、RDBMS+Redisが全用途に十分という保証もしません。

Q: ORM と生 SQL、どう使い分ける？
A: 基本は ORM、大量データ集計など性能クリティカルな箇所だけ生 SQL。混在は普通の構成です。

確認範囲と関連ページ

2026年10月26日確認。掲載した新7SQLは独立したMySQL8.4.13/MariaDB11.8.9の新規tmpfs検体で実行しました。既存DBのIF NOT EXISTSと警告、既定変更と既存列、CREATE/DROPのROLLBACK不可、InnoDB検体のCOMMIT/ROLLBACK、読取権限とCREATE拒否を確認しています。既存本番DBのDDL/データ/設定/アカウントは変更していません。一般DB比較の全製品、旧全コード、実backup/restore/import/replication、全照合順序の重み/Unicode比較、OS間差や障害耐久性、LaravelのDDLを実行検証したものではありません。

データベース関連の親ページから子ページを選択できます。データベースの作成、MySQL/MariaDB配下のSQL、テーブル関連、同じ製品配下のユーザー関連、MySQL/MariaDBの親ページも参照します。

一次資料：MariaDB CREATE DATABASEとOR REPLACE、MySQL CREATE DATABASE、MySQLのDB既定変更、MariaDBのDB既定変更、InnoDBの分離レベル、MongoDBのトランザクション、ClickHouseの列指向モデル、Cassandraのwide-columnモデル、MyBatisのSQLマッピング。