Introduction

In MySQL, the semicolon normally marks the end of a SQL statement. But when writing stored procedures, triggers, or functions, you often need semicolons inside the routine body itself. That is why MySQL client tools provide the DELIMITER command: not because the server changed SQL syntax, but because the client needs a different way to know where one full statement ends.

The Default Delimiter

Normally, the MySQL client sends a statement to the server when it reaches ;.

SELECT NOW();
SELECT DATABASE();

Each semicolon ends one statement.

That works fine until you define a stored routine containing internal statements that also end with semicolons.

Why DELIMITER Is Needed

Consider a procedure:

1CREATE PROCEDURE demo_proc()
2BEGIN
3    SELECT 1;
4    SELECT 2;
5END;

If you run that directly in the MySQL client with the default delimiter, the client sees the first internal semicolon after SELECT 1; and thinks the statement is finished too early.

The DELIMITER command solves that client-side parsing problem.

Typical Procedure Example

1DELIMITER $$
2
3CREATE PROCEDURE demo_proc()
4BEGIN
5    SELECT 1;
6    SELECT 2;
7END $$
8
9DELIMITER ;

Here is what happens:

• 'DELIMITER $$ tells the client to wait for $$ instead of ;'
• semicolons inside the procedure body are now treated as part of the routine definition
• 'DELIMITER ; restores the normal statement terminator afterward'

That is the most common MySQL delimiter pattern.

Important Clarification: DELIMITER Is a Client Command

This is the key concept many beginners miss. DELIMITER is usually handled by the MySQL client or compatible tools, not by the MySQL server as part of SQL itself.

That means:

• it is mainly for interactive clients and SQL script execution tools
• it changes how the client splits statements before sending them
• it is not a general SQL keyword in the same sense as SELECT or CREATE

This explains why some APIs or database libraries do not understand DELIMITER at all. They may expect you to send one full routine definition as a single string instead.

Functions and Triggers Use the Same Idea

Function example:

1DELIMITER //
2
3CREATE FUNCTION double_value(x INT)
4RETURNS INT
5DETERMINISTIC
6BEGIN
7    RETURN x * 2;
8END //
9
10DELIMITER ;

Trigger example:

1DELIMITER //
2
3CREATE TRIGGER before_insert_demo
4BEFORE INSERT ON my_table
5FOR EACH ROW
6BEGIN
7    SET NEW.created_at = NOW();
8END //
9
10DELIMITER ;

The pattern is the same because the routine body contains internal semicolons.

Choosing a Delimiter

The alternate delimiter can be almost any token that does not conflict with your statement text. Common choices are:

• '$$'
• '//'
• ';;'

The exact token is less important than consistency and readability.

When You May Not Need DELIMITER

If your application sends the entire routine definition as one statement string through a driver, the driver may not require the DELIMITER command at all. In that environment, DELIMITER can even fail because the driver is not a MySQL shell parser.

So if a migration tool or ORM rejects DELIMITER, check whether it expects raw SQL statements directly rather than MySQL console syntax.

Common Pitfalls

• Thinking DELIMITER changes server-side SQL grammar instead of client-side statement splitting.
• Forgetting to reset the delimiter back to ; after defining a routine.
• Sending DELIMITER through an API or migration framework that does not support client-side shell commands.
• Choosing a custom delimiter that accidentally appears inside the routine body.
• Debugging stored procedure syntax while the real problem is only incorrect statement termination.

Summary

• The default MySQL delimiter is ;.
• 'DELIMITER is mainly a client-side command used when defining routines that contain internal semicolons.'
• Procedures, functions, and triggers often require a temporary alternate delimiter in shell-based workflows.
• Reset the delimiter afterward so normal statements behave as expected.
• Many problems around MySQL delimiters come from confusing client parsing rules with server SQL syntax.