動くコード図鑑
$ ls -1 /library | wc -l → 619
触って動く、検証済みの正解集。
公開記事から抽出した全コードブロックを 1 つずつページ化。 ▶ ボタンで 実行ログを再生し、 さも今動いてるかのように出力を流す。

この図鑑の使い方
言語で絞る
C# / SQL / TypeScript / PowerShell / Bash でフィルタ。
▶ で実行
事前収録の出力を 1 行ずつ再生。 ぱっと結果が見える。
記事と接続
各 snippet は出典記事へのリンク付き。 文脈ごと読める。
絞り込み
snippet 一覧
619 件SET STATISTICS PROFILE ON; SELECT * FROM dbo.tmp_orders WHERE customer_id = 1; SET STATISTICS PROFILE OFF;
▶ 実行可
② Estimated rowsとActual rowsの乖離
SQL Server 実行計画の読み方 — Estimated vs Actual で業務SE が最初に見る5箇所#2094ae3368eb
-- ✗ Index効かない WHERE CONVERT(VARCHAR, created_at, 23)= '2026-05-15' -- ✓ Index効く WHERE created_at >= '2026-05-15' AND created_at < '2026-05-16'
④ WHERE列を関数で潰してる
SQL Server 実行計画の読み方 — Estimated vs Actual で業務SE が最初に見る5箇所未収録#ba63e096cd59
-- 全 INDEX の断片化を一発で返す (SAMPLED モード) SELECT OBJECT_NAME(ps.object_id) AS table_name, si.name AS index_name, si.type_desc AS index_type,
▶ 実行可
罠①: 断片化率と page_count の見方
業務 SE が SQL Server INDEX 断片化に手を出す前に見る 3 箇所 — REBUILD / REORGANIZE / 放置の判断軸#a957935a3f52
-- 現在のロック保持状況 (Sch-M / Sch-S を含む) SELECT request_session_id AS session_id, resource_type, resource_associated_entity_id,
▶ 実行可
罠 2-c: Sch-M ロックは ONLINE でも瞬間発生する
業務 SE が SQL Server INDEX 断片化に手を出す前に見る 3 箇所 — REBUILD / REORGANIZE / 放置の判断軸#20036fe3c264
-- 全 INDEX の fill factor 現状 SELECT OBJECT_NAME(i.object_id) AS table_name, i.name AS index_name, i.type_desc AS index_type,
▶ 実行可
fill factor の現状確認 SQL
業務 SE が SQL Server INDEX 断片化に手を出す前に見る 3 箇所 — REBUILD / REORGANIZE / 放置の判断軸#ace9ba4117bf
-- 更新多い INDEX を REBUILD + fill factor 85% で再構築 ALTER INDEX [IX_Orders_OrderDate] ON [dbo].[Orders] REBUILD WITH ( FILLFACTOR = 85,
REBUILD と一緒に fill factor を変える書き方
業務 SE が SQL Server INDEX 断片化に手を出す前に見る 3 箇所 — REBUILD / REORGANIZE / 放置の判断軸未収録#9b242fc587e9
-- これは罠 SELECT * FROM Sessions WHERE SessionId = @sid OPTION (RECOMPILE); -- ↑ 1秒に100回叩かれる SELECT に付けると、コンパイル時間が積み重なって CPU が爆上がり
▶ 実行可
なぜ「とりあえずRECOMPILE」が逆効果になるのか
SQL Server で OPTION(RECOMPILE) を脳死で付けて遅くなった話#6c4d462b81b8
SELECT OrderId, CustomerId, TotalAmount FROM Orders WHERE OrderId = @orderId;
▶ 実行可
パターン1: RECOMPILE不要(主キー一発引き・プランキャッシュで十分)
SQL Server で OPTION(RECOMPILE) を脳死で付けて遅くなった話#2dfc6b7f28b4
SELECT OrderId, CustomerId, OrderDate FROM Orders WHERE Status = @status OPTION (RECOMPILE);
▶ 実行可
パターン2: RECOMPILEが効く(パラメータ依存性高)
SQL Server で OPTION(RECOMPILE) を脳死で付けて遅くなった話#2118b549aaa7
SELECT SessionId, UserId, LastAccess FROM Sessions WHERE SessionId = @sid OPTION (RECOMPILE);
▶ 実行可
パターン3: RECOMPILE逆効果(高頻度+パラメータ依存なし)
SQL Server で OPTION(RECOMPILE) を脳死で付けて遅くなった話#e99b05b9a5e5
-- 0.5/1.5/2.5 を四捨五入。リテラル 0.5 は桁が足りず overflow するので CAST で桁を確保 SELECT ROUND(CAST(0.5 AS decimal(2,1)), 0) -- 1.0 , ROUND(CAST(1.5 AS decimal(2,1)), 0) -- 2.0 , ROUND(CAST(2.5 AS decimal(2,1)), 0); -- 3.0
▶ 実行可
2. ROUND は四捨五入。銀行丸めじゃない(float はもっと危ない)
SQL Server の ROUND で金額計算がズレる3つの罠 — 丸め方向・負の桁・暗黙の切り捨て#69061412ae1f
-- float は 2.675 を正確に表現できないことがある SELECT ROUND(CAST(2.675 AS float), 2); -- 2.67(誤差で 2.675 が 2.6749… 扱い) -- decimal なら正確 SELECT ROUND(CAST(2.675 AS decimal(10,3)), 2); -- 2.680(正しく切り上げ)
▶ 実行可
2. ROUND は四捨五入。銀行丸めじゃない(float はもっと危ない)
SQL Server の ROUND で金額計算がズレる3つの罠 — 丸め方向・負の桁・暗黙の切り捨て#4e032d9da2e5
-- 金額は decimal で。消費税8%を計算 SELECT CAST(1000 AS decimal(12,2)) * 0.08; -- 80.0000 -- 表示桁を金額の2桁に揃えるなら、結果も明示的に丸める SELECT CAST(CAST(1000 AS decimal(12,2)) * 0.08 AS decimal(12,2)); -- 80.00
▶ 実行可
3. INT同士の除算は、ROUNDより先に切り捨てられる
SQL Server の ROUND で金額計算がズレる3つの罠 — 丸め方向・負の桁・暗黙の切り捨て#a1a355ce9afe
-- NG: 同点の時に順位がブレる SELECT customer_id, ROW_NUMBER() OVER (ORDER BY total_sales DESC) AS rn FROM monthly_sales; -- OK: customer_id を tiebreaker に
▶ 実行可
① ORDER BY なしで PARTITION BY だけ書く罠
SQL Server ROW_NUMBER の落とし穴 — Window Function の内部実装と Sort Operator の判断軸#898007531d46
-- 統計情報を見るためのセッション設定 SET STATISTICS IO ON; SET STATISTICS TIME ON; -- ROW_NUMBER + 大量データで Sort Operator を確認
▶ 実行可
Sort Operator がスピルしてる証拠の読み方 (実行計画 + sys.dm_exec_query_stats)
SQL Server ROW_NUMBER の落とし穴 — Window Function の内部実装と Sort Operator の判断軸#ba5a76787842
SELECT TOP 20 qs.execution_count, qs.total_logical_reads / qs.execution_count AS avg_logical_reads, qs.total_elapsed_time / qs.execution_count / 1000 AS avg_elapsed_ms, SUBSTRING(qt.text, (qs.statement_start_offset / 2) + 1,
▶ 実行可
Sort Operator がスピルしてる証拠の読み方 (実行計画 + sys.dm_exec_query_stats)
SQL Server ROW_NUMBER の落とし穴 — Window Function の内部実装と Sort Operator の判断軸#791a21890408
SELECT OBJECT_NAME(s.object_id) AS table_name, s.name AS stats_name, STATS_DATE(s.object_id, s.stats_id) AS last_updated, s.auto_created,
▶ 実行可
① STATS_DATE() — 統計の最終更新日時
業務 SE が踏む統計情報乖離 — 本番とステで実行計画が割れる時に最初に見る 3 箇所#554096ea8bfc
SELECT OBJECT_NAME(si.id) AS table_name, si.name AS index_name, si.rowcnt, si.rowmodctr,
▶ 実行可
② rowmodctr — 前回更新からの変更行数
業務 SE が踏む統計情報乖離 — 本番とステで実行計画が割れる時に最初に見る 3 箇所#c1fc85b69aff
SET STATISTICS PROFILE ON; SELECT * FROM Orders WHERE Status = 'エラー' AND OrderDate > '2026-05-01'; SET STATISTICS PROFILE OFF;
▶ 実行可
③ 本番ステの実行計画 diff (EstimatedRows と ActualRows)
業務 SE が踏む統計情報乖離 — 本番とステで実行計画が割れる時に最初に見る 3 箇所#aa1f92dc4eec
-- 今この瞬間メモリ grant を持ってる / 待ってるクエリ SELECT mg.session_id, mg.request_time, mg.grant_time,
▶ 実行可
罠①: メモリ grant 不足の検知 (DMV クエリ)
SQL Server tempdb スピルを業務 SE が本番で踏む 3 箇所 — 検知と回避の判断軸#f191b89fd23c
-- Resource Semaphore のキュー俯瞰 SELECT resource_semaphore_id, target_memory_kb / 1024 AS target_mb, max_target_memory_kb / 1024 AS max_target_mb,
▶ 実行可
罠①: メモリ grant 不足の検知 (DMV クエリ)
SQL Server tempdb スピルを業務 SE が本番で踏む 3 箇所 — 検知と回避の判断軸#825167296635
-- 過去 grant が大きかった TOP 10 クエリ (2012 SP3 / 2014 SP2 / 2016+) SELECT TOP 10 qs.execution_count, qs.max_grant_kb / 1024 AS max_grant_mb, qs.min_grant_kb / 1024 AS min_grant_mb,
▶ 実行可
SQL Server 2012 SP3 以降なら dm_exec_query_stats も使える
SQL Server tempdb スピルを業務 SE が本番で踏む 3 箇所 — 検知と回避の判断軸#094982b96d49
-- tempdb のファイル構成と autogrowth 設定 SELECT name, physical_name, type_desc,
▶ 実行可
罠③: tempdb ファイル分割と autogrowth 設定の現状確認
SQL Server tempdb スピルを業務 SE が本番で踏む 3 箇所 — 検知と回避の判断軸#5e1f9e18ce2b
-- products テーブルの category_name を categories マスタの最新名で更新 UPDATE p SET p.category_name = c.name FROM products p INNER JOIN categories c ON p.category_id = c.id
パターン① JOIN 型 UPDATE — 単純 1:1 コピーの最短記述
SQL Server UPDATE … FROM SELECT 3パターン — 業務SE が JOIN / CTE / MERGE を本番で使い分ける判断軸未収録#3c346e6ce0cf
-- 必須プレチェック: 結合元 (categories) に id 重複がないか確認 SELECT id, COUNT(*) AS cnt FROM categories GROUP BY id HAVING COUNT(*) > 1;
▶ 実行可
パターン① JOIN 型 UPDATE — 単純 1:1 コピーの最短記述
SQL Server UPDATE … FROM SELECT 3パターン — 業務SE が JOIN / CTE / MERGE を本番で使い分ける判断軸#83da9e81c3d9
-- 各 category_id に複数 categories 行がある場合、name の最新 (MAX(updated_at)) を採用 WITH src AS ( SELECT c.id AS category_id, c.name,
パターン② CTE 型 UPDATE — 集約反映と可読性の本命
SQL Server UPDATE … FROM SELECT 3パターン — 業務SE が JOIN / CTE / MERGE を本番で使い分ける判断軸未収録#72cdfe89da29
-- products に対して、categories マスタの全 id を Upsert -- (既存 category_id があれば name を更新、なければ INSERT) MERGE INTO products AS tgt USING ( SELECT id, name FROM categories WHERE active = 1
パターン③ MERGE 型 UPDATE — Upsert の決定打 (地雷つき)
SQL Server UPDATE … FROM SELECT 3パターン — 業務SE が JOIN / CTE / MERGE を本番で使い分ける判断軸未収録#3edff919d8a5
-- (a) 範囲ロックを早めに取る (UPDATE 1 文で完結する場合) UPDATE T1 WITH (UPDLOCK, HOLDLOCK) SET status = 'fixed' FROM T1 INNER JOIN ... ON ... WHERE ...;
並列実行時のロストアップデート — 3 パターン共通の落とし穴
SQL Server UPDATE … FROM SELECT 3パターン — 業務SE が JOIN / CTE / MERGE を本番で使い分ける判断軸未収録#785286e63e10
import {Action} from 'redux' export enum ActionNames{ Increment = 'inc', Decrement = 'dec'
Action
Typescript×Reduxでカウンタアプリ作ってみる!未収録#471a1378c67a
import {ActionNames, ActionType} from "../Actions/CounterAction"; export interface IState { num : number
Reducer
Typescript×Reduxでカウンタアプリ作ってみる!未収録#4d8b83057790