CREATE VIEW builds a stored SELECT query, letting you query a virtual table as if it were a real table.
CREATE VIEW stores a SELECT statement as a virtual table. You can query it like any table, but data lives in the underlying tables, keeping storage low and logic reusable.
Syntax supports optional OR REPLACE, algorithm hints, definer context, SQL SECURITY level, column list, and the SELECT body. See the syntax block below for every option.
Use OR REPLACE to re-deploy safely and include ONLY necessary columns to speed joins:CREATE OR REPLACE VIEW recent_orders ASSELECT o.id, o.customer_id, o.order_date, o.total_amountFROM Orders oWHERE o.order_date > NOW() - INTERVAL 30 DAY;
Aggregate business logic once, then have BI tools or micro-services hit that view instead of every team rewriting JOINs. This cuts duplication and prevents errors.
Yes, if the view is updatable: single base table, no aggregation, no DISTINCT, and all NOT NULL columns present. Otherwise, use INSTEAD OF triggers.
Create the view with SQL SECURITY DEFINER and GRANT SELECT on the view only. Users query safely while table privileges stay locked down.
• Prefix view names with vw_
.
• Add comments in the view body for future maintainers.
• Keep each view focused; chain simple views instead of one monster definition.
Missing ALGORITHM: always declare ALGORITHM=MERGE or TEMPTABLE to avoid surprises.
Over-selecting columns: expose only what clients need to cut network payload.
Views have no physical storage, so you cannot add indexes directly. Instead, index the underlying tables or create a materialized table.
Use CREATE OR REPLACE VIEW to overwrite the old definition atomically. Clients experience zero downtime.
The view becomes invalid and queries fail until you recreate the view without that column.