SQL
MySQL
Data Manipulation
Database Management
SQL Tips

MySQL combine two columns into one column

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

Introduction

Combining two columns in MySQL is common when building display names, composite labels, or export-friendly values. The important design question is whether you only need the combined value in query output or whether you want to store it as part of the table schema. In many cases, query-time composition is enough and avoids duplicate data.

Use CONCAT for Simple Query-Time Combination

If you only need the merged value in a query result, use CONCAT or CONCAT_WS.

sql
1SELECT
2  id,
3  first_name,
4  last_name,
5  CONCAT(first_name, ' ', last_name) AS full_name
6FROM users;

This works, but CONCAT has an important behavior: if any argument is NULL, the whole result becomes NULL.

That is why many real queries are better written with CONCAT_WS.

CONCAT_WS Handles Nulls Better

CONCAT_WS means “concatenate with separator”. It skips NULL arguments and inserts the separator only between non-null values.

sql
1SELECT
2  id,
3  CONCAT_WS(' ', first_name, last_name) AS full_name
4FROM users;

For names, addresses, or labels where some parts may be missing, this is usually the safer choice.

Normalize the Source Values First

Real data often contains extra spaces or empty strings. If you combine raw values directly, the result may have doubled separators or awkward blanks.

sql
1SELECT
2  id,
3  CONCAT_WS(
4    ' ',
5    NULLIF(TRIM(first_name), ''),
6    NULLIF(TRIM(last_name), '')
7  ) AS clean_full_name
8FROM users;

This trims whitespace and converts empty strings to NULL, which makes CONCAT_WS behave more cleanly.

The same pattern helps when combining city and state, code prefixes and suffixes, or other human-facing display fields.

Store the Combined Value Only When There Is a Real Need

If the value is needed only for display, calculating it in the query is usually enough. Storing a combined column introduces synchronization work because the derived value must stay consistent with the source columns.

If you truly need a stored field, one option is a regular column plus update logic.

sql
1ALTER TABLE users ADD COLUMN full_name VARCHAR(255);
2
3UPDATE users
4SET full_name = CONCAT_WS(' ', NULLIF(TRIM(first_name), ''), NULLIF(TRIM(last_name), ''));

That is straightforward, but it also means inserts and updates must keep the column consistent.

Generated Columns Reduce Drift

If your MySQL version and schema design allow it, a generated column is often a better stored solution because it derives the value automatically.

sql
1ALTER TABLE users
2ADD COLUMN full_name VARCHAR(255)
3GENERATED ALWAYS AS (
4  CONCAT_WS(' ', NULLIF(TRIM(first_name), ''), NULLIF(TRIM(last_name), ''))
5) STORED;

This avoids a lot of manual synchronization logic and keeps the data model more trustworthy.

Think About Search and Indexing Separately

Sometimes people want a combined column not for display, but for searching. In that case, you should decide whether indexing the combined field is actually better than indexing the original columns and composing only for output.

sql
CREATE INDEX idx_users_full_name ON users(full_name);

That index can be useful, but it has storage and maintenance cost. Add it only if the query pattern justifies it.

SQL Layer Versus Application Layer Formatting

The final formatting choice depends on where the value is consumed.

  • SQL is a good place when many reports or services need the same combined field.
  • the application layer is a good place when formatting depends on locale, user preference, or presentation rules.

The key is to pick one owner for formatting rules. If the SQL layer and application layer both invent their own combination logic, outputs drift over time.

Common Pitfalls

  • Using CONCAT and unexpectedly getting NULL because one source column is NULL.
  • Forgetting to trim and normalize source values before combining them.
  • Storing a combined column without a plan to keep it synchronized.
  • Indexing a combined field without evidence that the query pattern needs it.
  • Splitting formatting logic inconsistently between SQL and application code.

Summary

  • Use query-time combination when you only need the merged value for output.
  • Prefer CONCAT_WS when null handling matters.
  • Normalize whitespace and empty strings before combining fields.
  • Store the combined value only when there is an operational reason.
  • Generated columns are often the cleanest stored option when schema support allows it.

Related reading
Course
Beginner
27 lessons
10 hours
System Design Fundamentals

Build a strong foundation in designing scalable, reliable distributed systems.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

System Design practice on Codemia

Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.

Practice system design

All Rights Reserved.