A representative image showing the setting that converts tab input to 4 spaces in MySQL Workbench

Overview

When multiple people manage SQL scripts together, it’s important to keep indentation rules consistent. If tabs and spaces are mixed, code alignment breaks and unnecessary changes can pile up in Git diffs.

In development environments, it’s common to use a policy of 4 spaces instead of tabs. MySQL Workbench, from version 6.2.4 onward, also provides a setting that converts tab input into spaces.

Configuration

To make MySQL Workbench convert tabs to spaces, go to the Preferences menu.

1Edit -> Preferences

Screen showing navigation to the Edit → Preferences menu in MySQL Workbench

In the Preferences window, select General Editors, then change the Indentation setting.

1General Editors -> Indentation
2
3Tab key inserts spaces instead of tabs: check
4Indent width: 4
5Tab width: 4

Screen showing the setting under Indentation in General Editors to use spaces instead of tabs

After saving the setting, pressing the tab key in the SQL editor window will insert 4 spaces instead of a tab character. If the change doesn’t apply immediately, close and reopen any open editor windows, or restart MySQL Workbench.

In the procedure editor, the setting may not apply the same way. In that case, write the code in the SQL editor window and apply it to the procedure, or format it in a separate editor and paste it in.

Reference: MySQL Workbench General Editors Preferences

Cleaning Up Files That Already Contain Tabs

This setting only applies to tabs entered going forward. Tab characters that already exist inside saved SQL files remain unchanged.

To convert them all at once from the command line, use expand.

1# Convert a single file
2expand -t 4 old.sql > new.sql
3
4# Convert an entire directory (a backup is recommended before running)
5find . -name "*.sql" -exec bash -c 'expand -t 4 "$1" > "$1.tmp" && mv "$1.tmp" "$1"' _ {} \;

If you’re working on Windows, you can also open the file in VS Code and run Convert Indentation to Spaces from the command palette.

Pinning the Team’s Rule with .editorconfig

Workbench’s Preferences apply only to that particular machine. If your team members use different editors, it’s more reliable to place a .editorconfig file at the root of the repository.

1# .editorconfig
2root = true
3
4[*.sql]
5indent_style = space
6indent_size = 4
7end_of_line = lf
8insert_final_newline = true
9trim_trailing_whitespace = true

Most editors, such as VS Code, IntelliJ, and Vim, recognize this file. However, MySQL Workbench does not read .editorconfig. For Workbench, you need to configure it separately using the Preferences setting described above.

How Indentation Affects Diffs

When tabs and spaces are mixed, lines where only the indentation changed—while the logic stays the same—end up cluttering the diff. During review, the actual changes get buried, and git blame ends up pointing to the wrong commit.

If you’re cleaning up a file that’s already mixed, it’s better to separate the commit that only fixes indentation from other changes. Mixing it with functional changes makes review difficult.

1git commit -m "chore: SQL 들여쓰기를 공백 4칸으로 통일"

When you want to view a diff while ignoring whitespace changes, use the options below.

1# Diff that ignores whitespace changes
2git diff -w
3
4# Blame that ignores whitespace changes
5git blame -w