A CLI tool and .NET library that optimizes SQL Server views by inlining nested views into a single flattened query. It can strip unused columns and joins to produce a leaner, faster view.
While SQL Server can handle nested views, stacking views on top of each other leads to significant performance problems. As nesting grows, developers lose sight of the extra joins and columns being pulled in. These inefficiencies accumulate: larger intermediate datasets, wasted memory, and longer execution times.
sql-inliner solves this by:
- Flattening nested view references into a single query (recursively, no matter how deep)
- Stripping unused columns so only the data the outer view actually needs is selected
- Stripping unused joins so tables that contribute nothing to the result are removed entirely
- Preserving the original SQL inside the output so you can always restore or re-inline later
Given two nested views where the outer view only uses a subset of columns:
-- Inner view: selects many columns and joins several tables
CREATE VIEW dbo.VPerson AS
SELECT p.Id, p.Name, p.Email, a.City, a.Street, a.Zip
FROM dbo.Person p
LEFT JOIN dbo.Address a ON a.PersonId = p.Id
-- Outer view: only uses Id and Name
CREATE VIEW dbo.VPersonNames AS
SELECT v.Id, v.Name
FROM dbo.VPerson vAfter inlining with --strip-unused-columns --strip-unused-joins:
CREATE OR ALTER VIEW [dbo].[VPersonNames] AS
SELECT [v].[Id], [v].[Name]
FROM (
SELECT [p].[Id], [p].[Name]
FROM [dbo].[Person] [p]
-- Address join removed: contributed no columns to the result
) [v]The nested view reference is replaced with a subquery, the unused Email/City/Street/Zip columns are stripped, and the Address join is removed entirely because none of its columns are needed.
Always verify the generated code manually before deploying to a production database.
The CLI tool is distributed as a .NET global tool and requires the .NET 8.0 SDK (or later) to be installed. You can verify your installation by running dotnet --version.
dotnet tool install --global sqlinlinerThis registers the sqlinliner command globally so it can be used from any directory. Run sqlinliner --help to see all available options, or sqlinliner --version to check the installed version.
If you want to integrate view inlining into your own application or build pipeline, install the library package instead:
dotnet add package SqlInliner.LibraryThe library targets net472, netstandard2.0, net8.0, net9.0, and net10.0. See Library usage below for API examples.
sqlinliner [options]
| Option | Alias | Type | Default | Description |
|---|---|---|---|---|
--config |
-c |
path | — | Path to a sqlinliner.json configuration file (auto-discovers sqlinliner.json in current directory) |
--connection-string |
-cs |
string | — | Connection string to the SQL Server database |
--view-name |
-vn |
string | — | Fully qualified name of the view to inline (e.g. dbo.MyView) |
--view-path |
-vp |
path | — | Path to a .sql file containing a CREATE VIEW statement |
--strip-unused-columns |
-suc |
bool | true |
Remove columns from nested views that the outer view does not reference |
--strip-unused-joins |
-suj |
bool | false |
Remove joins from nested views whose tables contribute no columns to the result |
--aggressive-join-stripping |
— | bool | false |
Exclude join-condition column references from the usage count (can change results for INNER JOINs — see below) |
--flatten-derived-tables |
-fdt |
bool | false |
Flatten derived tables (subqueries) produced by inlining into the outer query (experimental — see below) |
--generate-create-or-alter |
— | bool | true |
Wrap the output in a CREATE OR ALTER VIEW statement |
--output-path |
-op |
path | — | Write the resulting SQL to a file instead of the console |
--log-path |
-lp |
path | — | Write warnings, errors, and timing info to a file |
At least one of --view-name or --view-path is required. When both are supplied, --view-path provides the main view definition while --view-name (with --connection-string) is used to fetch any nested views referenced inside it from the database.
A connection string is not required when all referenced views are available locally — either via --view-path or the views mapping in a config file.
The tool writes the inlined SQL to stdout (or to --output-path) and always exits with code 0. Check the -- Errors section in the output metadata comment or the --log-path file to detect problems.
Instead of passing all options on the command line, you can create a sqlinliner.json file:
{
"connectionString": "Server=.;Database=MyDB;User Id=sa;Password=secret",
"stripUnusedColumns": true,
"stripUnusedJoins": true,
"aggressiveJoinStripping": false,
"flattenDerivedTables": false,
"generateCreateOrAlter": true,
"views": {
"dbo.VPeople": "VPeople.sql",
"dbo.VNestedPeople": "./nested/VNestedPeople.sql"
}
}All fields are optional. CLI arguments always override config values.
- Auto-discovery: If
--configis not specified, the tool looks forsqlinliner.jsonin the current directory. - View mappings: The
viewsobject maps fully qualified view names to.sqlfile paths. Paths are resolved relative to the config file's directory. These views are registered before inlining, so nested views can be resolved from files instead of a database connection. - No connection required: When all referenced views are provided via the
viewsmapping, no--connection-stringis needed.
# Explicit config path
sqlinliner -c ./config/sqlinliner.json -vn dbo.VHeavy
# Auto-discover sqlinliner.json in current directory
sqlinliner -vn dbo.VHeavy
# Config + local file (nested views resolved from config)
sqlinliner -c sqlinliner.json -vp ./views/VHeavy.sql --strip-unused-joinssqlinliner \
-cs "Server=.;Database=Test;Integrated Security=true" \
-vn "dbo.VHeavy" \
--strip-unused-joinsFetches the definition of dbo.VHeavy, recursively inlines every nested non-indexed view, strips unused columns (on by default) and unused joins.
sqlinliner \
-cs "Server=hostname.domain.net;Database=mydb;User=myuser;Password='secret'" \
-vn "dbo.SlowView" \
--strip-unused-joinssqlinliner -vp "./views/MyView.sql" --strip-unused-joinsUses the exact contents of MyView.sql. If a connection string is also supplied, any views referenced within MyView.sql are fetched from the database.
sqlinliner -vp "./views/MyView.sql" --generate-create-or-alter falseOutputs only the inlined SELECT statement — useful when embedding the result inside a larger script or when comparing different versions.
sqlinliner \
-vp "./views/VHeavy.sql" \
-cs "Server=.;Database=Test;Integrated Security=true" \
--strip-unused-joinsThe main view definition comes from VHeavy.sql, but any nested views it references (e.g. dbo.VInner) are fetched from the database via the connection string. This is useful when iterating on the outer view locally while the inner views live in the database.
sqlinliner \
-cs "Server=.;Database=Test;Integrated Security=true" \
-vn "dbo.VHeavy" \
--strip-unused-joins \
-op "./output/VHeavy_inlined.sql" \
-lp "./output/VHeavy.log"The optimize subcommand provides a guided, interactive workflow for optimizing a view against a backup or development database. It walks you through inlining, deploying, validating correctness, and benchmarking performance — all in one session.
Warning: Only run
optimizeagainst a backup or development database. It will executeCREATE OR ALTER VIEWstatements directly.
sqlinliner optimize \
-cs "Server=.;Database=TestBackup;Integrated Security=true" \
-vn "dbo.VHeavy"- Connect & Warn — Prompts you to confirm the database is a backup/development copy.
- Select View — Validates the view exists and shows metadata (SQL length, nested view count).
- Inline — Runs the inliner with the current options and saves the result to a session directory.
- Review — Optionally opens the generated SQL in your default editor. Detects manual edits and offers to regenerate.
- Deploy — Executes
CREATE OR ALTER VIEW [schema].[ViewName_Inlined]on the database. - Validate — Compares the original and inlined views with
COUNTandEXCEPT(both directions) to verify identical results. - Iterate — Toggle options (strip-joins, aggressive mode) and re-inline, or continue to benchmarking.
- Benchmark — Uses
SET STATISTICS TIME/IO/XML ONto compare CPU time, elapsed time, and logical reads between the original and inlined views. Shows a per-table IO breakdown (sorted by heaviest reads), saves actual execution plans as.sqlplanfiles (openable in SSMS), and generates a self-containedbenchmark.htmlreport. - Summary & Cleanup — Shows results, saves a
recommended.sql, and prints aDROP VIEWstatement (never executed automatically).
| Option | Alias | Type | Description |
|---|---|---|---|
--connection-string |
-cs |
string | Connection string (required, can come from config file) |
--view-name |
-vn |
string | Fully qualified view name. If omitted, you will be prompted. |
The --config / -c option is shared with the root command and also applies here.
Each optimization session creates a directory in the current working directory (e.g. optimize-VHeavy-20260225T143022/) containing:
iteration-1.sql,iteration-2.sql, ... — SQL from each iterationrecommended.sql— the final recommended versionplan-original.sqlplan,plan-inlined.sqlplan— actual execution plans (open in SSMS for visual comparison)benchmark.html— self-contained HTML report with performance summary and per-table IO breakdownsession.log— timestamped log of all actions
Enabled by default (--strip-unused-columns true). When a nested view selects columns that the outer view never references, those columns are removed from the inlined subquery. This reduces the amount of data SQL Server has to process.
For views that use UNION, EXCEPT, or INTERSECT, columns are removed by position across all branches to keep the query valid.
Disabled by default; enable with --strip-unused-joins. After column stripping, some tables in the nested view may no longer contribute any columns to the result. Join stripping removes those tables entirely, eliminating unnecessary I/O.
A join is considered safe to remove when:
- The table contributes zero columns to the outer query (or at most one column that is only used in its own join condition).
- For
LEFT JOIN: the join is marked@join:unique(see Join hints below), guaranteeing at most one match per row and no row duplication. - For
INNER JOIN: the join is marked both@join:uniqueand@join:required, guaranteeing exactly one match per row (no filtering, no duplication).
Without these hints, the tool cannot be certain that removing a join won't change the result set, so it leaves the join in place.
When --aggressive-join-stripping is enabled, column references that appear only in a table's own ON clause are excluded from the usage count. This allows the tool to strip joins where the table is referenced solely in its join condition (e.g. INNER JOIN b ON a.Id = b.Id AND b.Type = 'X').
Use with care: for INNER JOINs, the ON clause can act as a filter. Removing such a join may change the result set if rows exist that don't match the condition.
Disabled by default; enable with --flatten-derived-tables. After inlining, each nested view reference becomes a derived table (subquery in the FROM clause). When derived table flattening is enabled, the tool removes these subquery wrappers and promotes the inner tables directly into the outer query, producing a single flat SELECT with no nesting.
Example:
-- After inlining (default): derived table wrapper remains
SELECT [v].[Id], [v].[Name]
FROM (
SELECT [p].[Id], [p].[Name]
FROM [dbo].[People] [p]
WHERE [p].[Active] = 1
) [v]
WHERE [v].[Id] > 10
-- With --flatten-derived-tables: fully flat query
SELECT [p].[Id], [p].[Name]
FROM [dbo].[People] [p]
WHERE ([p].[Id] > 10) AND ([p].[Active] = 1)Inner JOINs within the subquery are also promoted:
-- After inlining: nested JOIN inside derived table
SELECT [v].[Id], [v].[Name]
FROM (
SELECT [a].[Id], [b].[Name]
FROM [dbo].[A] [a] INNER JOIN [dbo].[B] [b] ON [a].[Id] = [b].[AId]
) [v]
-- With --flatten-derived-tables: JOINs promoted to outer query
SELECT [a].[Id], [b].[Name]
FROM [dbo].[A] [a] INNER JOIN [dbo].[B] [b] ON [a].[Id] = [b].[AId]A derived table is eligible for flattening when:
- The inner query is a simple
SELECT(notUNION/EXCEPT/INTERSECT) - No
GROUP BY,HAVING,TOP, orDISTINCT - No
SELECT * - All columns referenced by the outer query are simple column references (not expressions like
CASEor function calls) - All tables in the inner
FROMclause are named tables (no nested derived tables)
The tool automatically detects and resolves alias collisions when the inner table aliases conflict with tables already in the outer query.
Join hints are SQL comments placed on or near a JOIN clause that tell sql-inliner about the join's cardinality. They enable safe join removal that would otherwise be skipped.
Available hints:
| Hint | Meaning |
|---|---|
@join:unique |
The join produces at most one matching row per source row (join references a unique/primary key) |
@join:required |
Every source row has a matching row in the joined table (FK is NOT NULL and referential integrity is enforced) |
Syntax — place hints as comments between the JOIN keyword and the ON clause:
-- A LEFT JOIN that is safe to remove when unused (at most 1 match, all left rows preserved):
LEFT JOIN /* @join:unique */ dbo.Address a ON a.PersonId = p.Id
-- An INNER JOIN that is safe to remove (exactly 1 match per row, no filtering):
INNER JOIN /* @join:unique @join:required */ dbo.Status s ON s.Id = p.StatusId
-- Multiple separate comments work too:
LEFT JOIN /* @join:unique */ /* @join:required */ dbo.Lookup l ON l.Id = p.LookupId
-- Single-line comment syntax is also supported:
LEFT JOIN -- @join:unique
dbo.Address a ON a.PersonId = p.IdSafety matrix:
| Join type | Hints | Safe to remove? | Reason |
|---|---|---|---|
LEFT JOIN |
@join:unique |
Yes | At most 1 match; all left-side rows preserved |
LEFT JOIN |
@join:unique @join:required |
Yes | Exactly 1 match; no row loss |
INNER JOIN |
@join:unique @join:required |
Yes | Exactly 1 match per row; no filtering |
INNER JOIN |
@join:unique (no @required) |
No | May filter out rows without a match |
| Any | @join:required (no @unique) |
No | Could fan out (multiple matches per row) |
RIGHT JOIN |
Any | No | Not currently handled |
FULL OUTER JOIN |
Any | No | Not currently handled |
The generated output embeds the original SQL between -- BEGIN ORIGINAL SQL VIEW -- and -- END ORIGINAL SQL VIEW -- markers inside a comment block. When a previously-inlined view is referenced by another view, sql-inliner automatically extracts and uses the original source — so re-inlining always starts from the un-inlined definition rather than compounding transformations.
The generated SQL includes a metadata comment followed by the inlined view:
/*
-- Generated on 1/15/2025 3:42 PM by SQL inliner in 00:00:00.1234567
-- BEGIN ORIGINAL SQL VIEW --
<original CREATE VIEW statement>
-- END ORIGINAL SQL VIEW --
-- Referenced views (3):
[dbo].[VInner1]
[dbo].[VInner2]
[dbo].[VInner3]
-- Removed: 12 select columns and 4 joins and flattened 3 derived tables
-- Warnings (0):
-- Errors (0):
*/
CREATE OR ALTER VIEW [dbo].[VHeavy] AS
SELECT ...Always compare the inlined view against the original to confirm they return identical results:
SELECT * FROM dbo.VHeavy EXCEPT SELECT * FROM dbo.VHeavy_v2;
SELECT * FROM dbo.VHeavy_v2 EXCEPT SELECT * FROM dbo.VHeavy;Both queries should return zero rows.
The SqlInliner.Library NuGet package exposes the same inlining engine without the CLI. Use it to integrate view inlining into your own tooling, build pipelines, or automated workflows.
using SqlInliner;
// Option 1: Use a live database connection
using var sqlConnection = new SqlConnection("Server=.;Database=Test;Integrated Security=true");
sqlConnection.Open();
var connection = new DatabaseConnection(sqlConnection);
var viewSql = connection.GetViewDefinition("dbo.VHeavy");
var inliner = new DatabaseViewInliner(connection, viewSql, InlinerOptions.Recommended());
if (inliner.Errors.Count == 0)
{
Console.WriteLine(inliner.Result.Sql);
}
// Option 2: Use mock view definitions (no database required)
var mockConnection = new DatabaseConnection();
mockConnection.AddViewDefinition(
DatabaseConnection.ToObjectName("dbo", "VInner"),
"CREATE VIEW dbo.VInner AS SELECT Id, Name FROM dbo.People"
);
var outerSql = @"CREATE VIEW dbo.VOuter AS
SELECT v.Id FROM dbo.VInner v";
var inliner2 = new DatabaseViewInliner(mockConnection, outerSql, new InlinerOptions
{
StripUnusedColumns = true,
StripUnusedJoins = true,
});
Console.WriteLine(inliner2.Result.Sql);The DatabaseViewInliner exposes two ways to get the SQL:
| Property | Returns |
|---|---|
inliner.Sql |
The inlined SQL only (shorthand, same as Result.Sql on success or the original SQL on error) |
inliner.Result.Sql |
The full output including the metadata comment block with original SQL, referenced views, and strip statistics |
inliner.Result.ConvertedSql |
Just the inlined CREATE VIEW / SELECT statement without the metadata comment |
| Property | Type | Default | Description |
|---|---|---|---|
StripUnusedColumns |
bool |
true |
Remove unused columns from nested views |
StripUnusedJoins |
bool |
false |
Remove unused joins from nested views |
AggressiveJoinStripping |
bool |
false |
Exclude join-condition references from usage count |
FlattenDerivedTables |
bool |
false |
Flatten derived tables (subqueries) into the outer query |
Use InlinerOptions.Recommended() for the suggested defaults (StripUnusedJoins = true, everything else at default).
sql-inliner retrieves view definitions by interpolating the provided view name directly into a SQL statement. If untrusted input is used for the view name, this query could be exploited for SQL injection. The tool is normally executed by a trusted user who also specifies the connection string, so the risk is low, but only supply view names from trusted sources or sanitize them before running the tool.